Part 2: Demystifying ADF Faces black magic - component behavioural interfaces

In part 1 of this post we looked at how to categorise components, in particular looking at their base JSF classes. In part 2, we'll look at the concept of component behavioural interfaces.

The JSF specification states that JSF components (or more specifically their classes) can implement one or more behavioural (Java) interfaces, or in other words standard behaviour functionality. There are effectively only 5 types within the JSF spec. Knowing this you can surmise the functionality of each component; if something works for 1 component with a specific behavioural interface, it should work for the rest:

• StateHolder – describes a component that has state and must be saved between requests, or in other words, multiple request-responses of a single user session. UIComponent implements StateHolder, thus by default all JSF components implement this behaviour.
• ValueHolder – a component that can access data from a data model tier and also maintain a local value. Both UIInput and UIOutput implement this interface.
• ActionSource – allows the component to fire an action event via a registered ActionListener calling a backing bean method, upon a submit to the mid tier. This is used by submit UICommand buttons and similar controls (such as the ADF Faces menu components).
• EditableValueHolder – an extension of ValueHolder allowing validation and raising value-change events via a ValueChangeListener.
• NamingContainer – requires each component and child component to have a unique ID.

Notably it's the ActionSource and EditableValueHolder behavioural interfaces along with the JSF lifecycle that give JSF its events based model similar to Swing, not too dissimilar to Oracle Forms trigger-event model, and totally abstracted from the traditional (and complex?) HTTP request-response programmatic approach. The user clicks on a button.... an ActionListener captures the event and fires off a backing bean method to do some work specified by the programmer. Couldn't be easier than that!

Oracle has taken the behavioural interfaces further, and implemented 2 additional behavioural interfaces:

• CollectionComponent - any component such as UIXTable that pages across records and is useful when screen real-estate is limited or you want to stop the user querying all records in 1 hit. It starts at a particular index in a row set, and includes the number of records to show on each page.
• DialogSource - any component that opens a ADF Faces dialog, and in turn needs to be notified when the dialog closes. An extension of ActionSource and notably used on UIXCommand controls. Includes listeners for passing values to and from the dialog.
  

Again in summary it can be seen that JSF or ADF Faces components are ultimately served by a set of Java classes that plug into the JSF framework. Understanding the classes, how they help categorise the components, including their functionality, and showing similarities, can help your understanding of the plumbings of the JSF components.