exclusively programmatic use of PageDef iterators

Revision: if you have an iterator that you have included for usage programatically only, be very careful! I kept getting JBO-35007 errors when I did a post back!! So finally I removed the iterator and just got the app module programmatically, and did a findViewObject("viewObjectInstanceName") from it.

Where and how does ADF expand on or deviate from JSF?

ADF is different from JSF, that is for sure.

JSF is an open standard, whereas ADF open for its Trinidad components, but not its newest ones. For example ADF Faces UI components are custom JSF UI components. Generalizing about ADF Faces components, they usually have many more properties than the JSF components. For example, compare the af:table with the h:dataTable. There function is to be the same, but the af:table has many additional features that the h:dataTable does not have. For example the af:table has a selectionListener and sortListener built right into the component’s properties. The h:dataTable has no such property. It is still possible to have a radio button select a particular row in the table, but the way that is to be done is totally different. Selecting a row in a table can involve many things: selectionListener of the table, an tableBinding, the CollectionModel interface (for the value of the af:table), and the af:table’s selection facet. The h:dataTable does not have nearly so many hooks into this row selection functionality.
On the other hand there is a certain simplicity to the way JSF without ADF Faces works. For example, you may not need a SortListener, when you can write a backing bean method that does the sorting, and have your table column header link simply call the sucker.

Another difference between af:table and h:dataTable is that af:table can use the built-in Partial Page Rendering to simply refresh the table without refreshing the entire page. This refreshing can get a bit involved, but usually it is not if you remember one thing: the command item that instigates the partial page rendering of the table cannot be from within the table itself. So for example if there is a button within the action facet of a table that needs PPR-ing, then either the button needs to be moved out of the table, or it needs to use its onclick event property to press another (perhaps hidden) button which is outside of the table. But even with this odd caveat af:tables can do PPR relatively easily.

(PPR outside of tables seems to be pretty straight forward and helpful; some rudimentary AJAX at its best.)

Another add-on for af:table’s are how they work with the page def table binding and iterator definitions in order to easily page groups of rows forwards and backwards. The component that supports the h:table has hooks for this, but it must all be implemented relatively manually. This binding layer is part and parcel of JSR227 (Data binding). Part of this data binding layer also implements DataControl’s. I think this is very important for allowing the layers to be interchangeable, and hiding the implementation of the business service layer.

Another big addition that ADF brings to the table is the Page Definition file; this is also part of the data binding layer they implement. JSF components typically connect to backing beans for their values, whereas Oracle ADF likes to route value properties (and others) through the bindings in the page definition file for that page. Most times I think the addition of binding layer functionality is a boon.

At another level, Oracle ADF Faces Lifecycle augments the JSF Request Processing lifecycle; ADF lifecycle adds a prepareModel and a prepareRender and an extra validation phase to the various JSF phases.

Here is Oracle’s point of view of some of these differences:
The Java Server Faces components differ from the ADF Faces components in ways completely spelled out at the following URL: http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/spec-diff.html

The following list gives Oracle’s list of advantages of ADF Faces component set over straight JSF HTML and Core components (Oracle Corporation, 2006)
1) Provide more efficient implementations of client-side state saving (reduced per-component size)
2) Rich set of components, validators, and converters
3) ADF Faces tags often offer more features than the standard tags; for example, all input components offer built-in label and message display support ( For more information on the differences between the ADF Faces tags and the standard Faces tags, please see the following document ).
4) Client-side converters/validators - JavaScript enabled converters and validators that attempt to catch and display errors on the client
5) ADF Faces tags can be used inside of the <> tag (it is, unfortunately, not possible to support standard tags inside <> ).
6) Accessibility - support similar to ADF UIX Accessibility
7) Bidirectional language support - ADF Faces components automatically render themselves appropriately for bidirectional languages. Users can also use the "start" and "end" constants described in ADF UIX Bidirectional Language Support
8) Partial Page Rendering (PPR) - support similar to ADF UIX PPR overview
9) Skinning - support similar to ADF UIX Look and Feel
10) ADF integration - including support for JSR227 (Data binding)
11) Rich Client - upcoming rich DHTML client-side renderers

Open World Abstract...

I have submitted an abstract for Oracle Open World. I want to do an instructive paper on how to do custom component development. I think I still have a lot to learn; I had read a chapter or two and done some exercises and examples and thought I knew what I was doing. At the time I learned these basics I felt very proud of them. Now I feel sheepish for feeling proud, since I now know definitively some things which then I only kind of knew.

At the height of my smugness I decided I would try and extend a rich faces component…that did not work out quite as well as I had hoped. I was able to put markup before and after the af:table (rich table, that is), but I cannot seem (yet) to figure out how to get into the middle of it – inside the box where the columns are or in-between the columns. I thought I knew where to look for this, but I am not finding what I expected when I look where I thought I should.

So far my efforts to augment these components have met with very limited success. There is a section in the Fusion Developers ADF Guide 11g about extending components (I hope they mean UI components and not business components) that I should read for sure and probably reference. Maybe that will give me some insight. Maybe for my understanding level, it would be more helpful to attendees if I stick with more basic concepts, like how the pieces I know about interact.

I know the declarative components are custom component combinations, which is quite handy. I have a 10g project where I could really use something like that. Maybe that is something I can explore for my paper: implementing declarative component conceptually, in order to help understand custom component development.

For my edification however I would like to know more details on how Oracle implemented their rich components. When I try to alter them or get inside of them, everything I do seems to not allow me to get at the inner parts of the component. I do not know how Oracle is hiding this.
For starters I see that there are property elements in the components when they are defined in faces-config.xml. I did not know that component properties could be define or elaborated on there. I do not know what that adds, but I would like to know.

I should study JSF details from the Java EE 5.0 tutorial. Hopefully they would have some further explanation of this. Or maybe the standards for Java EE 5.0: maybe they specify some details of JSF that would help me understand what Oracle and everybody else is doing with their components…and help me with this paper.

ADF 10g interfacing with Pentaho

Pentaho is an open-source reporting tool that has a Discoverer-like metadata store for ad-hoc querying; I am alternately battling with that getting my ADF interface to it implemented.

Yesterday I went down a path I had probably been down before but forgotten.

I used a tree binding on a table to have a table in the details facet of an af:table. This worked reasonably well until I tried to update the child table data. At that point all kinds of strange things started to happen. The rows would get mixed up as to who their parent was, I think there might have been some errors....at any rate I backed out of that and went another route because that one was proving somewhat unstable.

Things are starting to get green here in Virginia!