java.net: Wiki

A JSF UI Component is represented at runtime by an instance of a Java class that includes javax.faces.component.UIComponent as an ancestor in its inheritance hierarchy.

It is easy to adhere to this definition, but in practice, component authors need to do more than just this in order to get the most from JSF and to conform to user's expectations of what a JSF UI Component is. To do so, one of the following best practices must be followed.

extend your component class from an existing subclass of UIComponent that most closely represents the meaning and behavior of the piece of the UI you are encapsulating in the component.
extend your component class directly from UIComponentBase and implement the appropriate "behavioral interface"(s) that most closely represents the meaning and behavior of the piece of the UI you are encapsulating in the component.

Note that the first best practice includes the second one "for free" since the stock UIComponent subclasses already implement the appropriate behavioral interfaces.

The available subclasses of UIComponent are shown in this class diagram, taken from The Java EE 5 API Documentation. The "behavioral interfaces" are listed at the top of the diagram.

For example, the meaning and behavior of a "date picker" component is to allow the user to choose a date, usually with a nice UI, such as a calendar. Using the first best practice, the JSF UI Component for this "date picker" could extend from UIInput because the user is inputting a value. Note that UIInput extends from UIOutput because all components that allow the user to input a value also show that value to the user as well. Using the second best practice, the JSF UI Component for this "date picker" could extend from UIComponentBase and implement EditableValueHolder because the component is something that holds a value that the user can edit.

What does it mean for a jMaki widget to be a JSF UI Component?

To continue with the "date picker" example, imagine the following jMaki widget used in a JSF page:

<a:widget name="dojo.calendar" />

Currently, this tag will cause a JSF UI Component that only adheres to the narrow definition of what it means to be a JSF UI Component to be placed in the tree. In order for jMaki to get the most from JSF, and to conform to JSF user's expectations for the components they use, the JSF UI Component that sits behind the <a:widget name="dojo.calendar" /> tag must follow one of the two best practices listed above. Doing so will enable use-cases such as the following, which JSF users expect and need to find in their components:

<%@ taglib prefix="a" uri="http://jmaki/v1.0/jsf" %>
<%@ taglib prefix="tr" uri="http://myfaces.apache.org/trinidad" %>

<a:widget name="dojo.calendar" value="#{user.birthday}"
          valueChangeListener="#{model.dateChosen}">

  <tr:validateDateTimeRange minimum="#{prefs.bornBefore}"/>

</a:widget>

Norbert's jMaki eventListener is a great start, but it still is not as seamless an integration with JSF as it could be.

-- Main.edburns - 29 May 2008

Topic JMakiJSF . { View | Diffs r2 < r1 | More }

java.net RSS