Forms迁移到web发布后，修改键盘设置比以前方便了很多。在Client/Server发布模式下，必须用Oracle Terminal修改二进制的res文件才能改变默认的键盘设置，比较麻烦。转到web后，键盘设置仍然在res文件里，不过res文件是文本格式的了，改起来比较容易。

默认的键盘设置文件是fmrweb.res，这个设置和client/server下的键盘设置有些不同（不知道Oracle是出于何种考虑）。另外有一个fmrpcweb.res文件，具有与原来client/server下相同的键盘设置。如果你希望使用client/server的键盘设置，可以重命名为fmrweb.res把默认的覆盖。

前两天遇到有人问如何将F1-F10绑定到某些特定功能，其实比较简单。通常是将fmrweb.res中原来Fn键的绑定的行删除，将Fn键绑定到“Function n”上。再在Form中用KEY-Fn实现Function n功能。也可以不用修改fmrweb.res，直接用KEY触发器覆盖Fn键默认绑定的功能即可。例如F4键默认绑定为“Exit”，如果Form中添加KEY-EXIT触发器，按下F4键就只执行KEY-EXIT触发器中的代码，不执行默认的Exit_Form built-in了。

值得注意的是，F2键默认功能为“List Tab Pages”，绑定到任何其它功能后似乎都没有作用。还有F1键，如果是嵌入到IE中运行，F1不仅会触发绑定的KEY触发器，还会打开IE帮助。如果设置separateFrame=true，使Forms Applet不在IE中运行，IE帮助窗口就不会打开。其它Fn键都可以随意绑定。

Uncle Bob在java.net上写了一篇The Strategy, Template Method, and Bridge Patterns。个人觉得这是对上述三种设计模式最清晰的解释了。

简单的讲，Strategy将通用算法抽象为一个接口，算法用户和提供算法实现的类构成组合关系；Template Method将算法定义为一个抽象方法，让具体子类实现该抽象方法，它体现的是一种继承关系。Strategy比Template Method更灵活，适用于需要动态改变算法的情况。某些情况下，基类有多个抽象算法，不得不使用多个Strategy模式或者混合使用Template Method与Strategy，就成为Bridge。

对于这三个设计模式，我的优先选择顺序是：Template Mehod > Strategy > Bridge。因为继承最简单。继承不能满足需要的时候，才用组合。

"Keep it sample, stupid." 大家都知道，可惜也常常忘记。

我们在使用bc4j开发中的过程中遇到一个问题，发现数据库连接总是没有及时释放。应用运行一段时间之后，占用的数据库连接越来越多，而从不释放，最后将数据库所有可用连接占用完了。
使用的例子如下：
....
//创建ApplicationModule
ApplicationModule am = Configuration.createRootApplicationModule("com.xx.xxModule", "xxModuleLocal");
ViewObject vo = am.findViewObject("xxView");
Row row = vo.first();
....
//释放ApplicationModule
Configuration.releaseRootApplicationModule(am, true);
调用上面这句之后，ApplicationModule和数据库连接都应该被释放，可是没有。这是问题所在。

仔细搜索OTN JDeveloper和Metalink，这个问题与Bug 3853944有关。
Workaround：
调用Configuration.releaseRootApplicationModule(am, false)，并设置jbo.maxpoolsize=0关闭连接池（只能在jvm参数中设置，在bc4j配制文件中设置不起作用——Bug 3572918）。

原因：
createRootApplicationModule创建了一个ApplicationModule池和一个连接池（如果jbo.maxpoolsize不为0），然后从池中取出一个ApplicationModule实例。取出Application实例时从连接池中取出一个数据库连接。releaseRootApplicationModule(am, false)将am放回ApplicationModule池，这时am的数据库连接被放回连接池，所以可以保证数据库连接不会一直增长下去。
如果进一步要求连接必须立即释放的话，我们必须设置jbo.maxpoolsize=0，关掉连接池。这样createRootApplicationModule只创建ApplicationModule池，而不创建连接池。ApplicationModule从池中取出时建立数据库连接，放回池中时立即释放数据库连接。

相关文章或讨论：
有关Bug 3853944；有关Bug 3572918；BC4J状态管理机制；查看module池与连接池统计信息。

Steve Muench在Dive Into BC4J and ADF的一篇blog中说到上次提到的文章：Eating your own dogfood - use of Oracle Development tools within the Oracle Applications development group。他补充说，那篇文章没有提到BC4J(ADF Business Component的前身)。实际上BC4J已经是Oracle Apps的J2EE tech stack的核心部分，大约2000名Oracle Apps的开发人员也已经成为BC4J的最大用户。ADF做为Bc4J的延续，他的新feature一定会在以后的Oracle Apps开发中被利用到。
想起来John Wookey在上篇访谈中提到的"their own framework"应该就是BC4J吧。

Amis上一篇深刻的文章：Eating your own dogfood - use of Oracle Development tools within the Oracle Applications development group。它来源于对Oracle Applications Developement部门资深副总裁John Wookey的访谈。文章描述了Oracle如何使用自己的开发工具来实现Oracle Applications(E-business Suite)，以及Oracle Applications可能的技术架构变迁。我们可以从中看到一些有趣的东西，还有Forms/Reports的将来：

Oracle Apps不使用Designer来generate forms，但用它做数据库设计;

Oracle Apps对JSF/ADF/UIX充满信心，不仅相信使用JSF控件构建的DHTML用户界面可以达到与Forms一样的丰富功能，而且利用他们自己的framework和其他可重用组件，HTML/J2EE已经可以达到与Forms一样的开发效率。

Oracle Apps将会把ADF作为根本的开发框架，仅管现在还没有开始。开始可能会有一两个模块作为试验使用ADF，如果成功证明ADF已经成熟到一定程度，Oracle Apps会开始迁移工作：从Forms到HTML/J2EE。

Oracle Apps不会走自动迁移Forms到J2EE的路，因为两者技术架构截然不同；迁移过程将是手工的，尽管可能发布一些迁移的guidelines，hints或是一些小型工具；Apps也将利用迁移过程来重新设计一些应用模块，使其转为Self Service风格。（作者认为迁移工作不会太短，Forms至少还有5-7年的时间）

XML Publisher将会完全替换Reports。现存的RDF文件将作为内容的定义，通过报表引擎产生XML数据，再通过XML Publisher转换为用户需要的输出格式。这样达到内容与格式分离。

Oracle Apps没有计划使用HTML DB。

JDBC对数据库类型的支持已经非常完善，但是与PL/SQL交互能力一直是比较弱的。例如不能支持PL/SQL Boolean类型，Record类型，集合类型等等。
值得庆幸的是Oracle在它最新的JDBC Driver里加入了对PL/SQL Index-by Table支持，详情请看OTN上的这个例子。
希望以后Oracle能够增加对更多PL/SQL类型的支持，尤其是Record。

ps:
JDBC访问PL/SQL Ref Cursor的例子（这是以前的JDBC driver就支持的）