Java Hair

 If you are looking to migrate your Oracle Forms applications to Oracle ADF applications, you have probably wondered about how they would map. You probably did a google search and ended up at the Oracle ADF Equivalents of Common Oracle Forms Triggers page. This isn’t a bad reference, but it only talks about triggers and there is a lot more to a form than just the triggers.

The basic outline of the mappings we use is shown in the diagram here. We essentially use Task Flows to encapsulate the entire functionality of what used to be a Form. The Task Flow allows all functionality including complex business logic, navigation, included popups and dialogs, and even other Task Flows to be shown visually in the Task Flow Designer page in JDeveloper.

Since transactions can be nested, when one form calls another, that can be shown in the Task Flow diagram also. Task Flows are also nice to use in that they can be used to encapsulate transactions.

Another mapping we typically use is to map what were Windows in Forms to JSPX pages in the ADF application. We typically use the JSPX extension to denote that the page is an XML-compliant JSP page. The Items within the Window or Canvases are mapped to ADF Controls.

Blocks map relatively well to Views if they are Query-based blocks. The attributes in the block become attributes on the view that is associated with the Entity that relates to the table the original Block was based on.

The link above that I included talks about transaction related triggers but what about other triggers, like WHEN-VALIDATE-ITEM? Where do those triggers get mapped? In our experience, those types of triggers require some more thinking to map and cannot just be mapped blindly. While it is true that you could map all of those types of triggers to a Java method if you wanted to, since ADF includes the Groovy expression language you probably wouldn’t really want to. Simple validations (and even some complex ones) can be performed in Groovy and thus would probably be best as Groovy expressions. If you could move the validation that was done at the UI level in the Form to the Entity level in ADF you would be even better off. That way you wouldn’t need to repeat the same expressions in every page that modifies that entity.

As June and ODTUG approaches I will be posting more and more excerpts from my presentation (of which this is one).  They will include more detail on some of the ADF features and how those features may apply to migrating Oracle Forms apps to ADF as well as some more step by step how-to guides that go into some of the development details on creating different types of screens in ADF.

Another great feature of ADF is the addition of Groovy scripting to the ADF framework. The Tech Preview for ADF 11.0.0.0 includes version 1.0 of Groovy. Groovy scripts can be used in all the different tiers of the application, from performing validation on the presentation layer to doing foreign key checks on the Entity layer.

Steve Muench’s blog has a post with tips and tricks for ADF 11g and one section is devoted to the use of Groovy script in ADF. In it he makes mention of some of the more useful keywords and names available to you via Groovy expressions in ADF.

Some useful expressions:

#{securityContext.userName} : Get the user’s name from the Security Context

#{bindings.permissionInfo['PageAPageDef'].allowsView} : Determine if a user has permission to view a page

#{controllerContext.currentViewPort.exceptionData.message} : Display the message from the current exception.

There is also a handy expression builder that can be brought up wherever you can input an expression as an argument to a property.

Additional information on the Groovy scripting language can be found on the Groovy homepage.