Java Hair

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.

There are many niceties that JDeveloper/ADF provides, but as all things in programming and in life, the 80/20 rule typically applies. Putting master and detail tables on a page and syncing the two is a relatively easy process. You create the form, make sure that the selection listener on the table is set to use the data control to execute “makeCurrent” on the view, and set the detail table to do a partial page refresh based on the id of the master table. It’s great that it is such an easy thing to accomplish.

What isn’t great is what you need to do to actually determine which table is selected on the page all because of a quirk in the selection event on the table itself. It seems the selection listener only gets called when the selection in the table changes. So, if you select row 1 from table A, then select row 2 from table B, if you go back and select row 1 from table A again, the selection listener doesn’t get called because it was the same row that was originally selected. This makes it more challeging than simply adding code to the selection listener.

To keep track of the table that is selected, I elected to create a hidden input variable on the page, and then a javascript function that updated that variable with a parameter that is passed in. That function is then called by the selection listener.

The javascript funtion looks like this:

function tableClicked(var value) {
var selected = document.getElementById(”selectionMade”);
selected.value = value;
}

The hidden input value on the page is then tied to a backing bean. The method that needs to make a decision based on which table is selected simply checks the selectionMade value of the backing bean.

In order to get the table to call the javascript function, go to the source of the JSP file and add the following:

<af:clientListener method=”tableClicked(’tab1′)” type=”click”/>

One thing to look out for is that this particular way of doing things will not work if you want to check the value of the backing bean from an action that is performed with imediate=”true”.

We’ve been doing a lot of work here lately with Oracle’s ADF framework. It is a framework based on JSF, though to anyone who asks, I usually tell them that Oracle’s ADF Faces is to JSF just as Oracle Forms is to C. It may be based on JSF, but knowing JSF isn’t going to help you too much.

Before I go on, I should specify. Oracle’s ADF Framework actually consists of a front-end called ADF Faces and a back-end, ADF Business Components. Despite that it is theoretically possible to create ADF based applications in any IDE, if you are using ADF Faces and ADF Business Components, it really doesn’t make sense to not use JDeveloper. The current production release of JDeveloper (and ADF) is 10.1.3, but 10.1.3 doesn’t quite provide everything that we need for the project we are working on, and so we are working with JDeveloper 11g (TP3).

ADF Faces in itself is actually just a set of JSF tags, previous versions of which have been donated to the Apache MyFaces project. The new set of tags which are referred to by the name, ADF Rich Faces provide some great functionality with all sorts of AJAX tricks built-in.

The ADF BC Layer itself is no slouch either. It is another persistence layer and it attempts to tackle some of the more interesting problems that come up when you are in the business of translating client-server applications to web-based applications.  It consists of an Entity layer for objects that need to update the database and a View layer which consists of Views based on Entities or Read-Only views based on SQL queries.

Since the Entity Layer is cached on the server-side, it performs nicely and it allows you implement some long-running transactions that would otherwise be more difficult to implement in a multi-tiered environment.

Of course, all of these benefits don’t come without a cost, but we can talk more about that later.  For now, if you are interested in taking a look at what’s out there that can help you with that next enterprise application you are building, take a look at the latest release of Oracle’s ADF.  Be sure to check out some of the ADF blogs for some  good tips and tutorials.