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
