News

JavaServer Faces 2.0 Composite Components

Posted by Charles Humble on Nov 04, 2008 02:56 PM

Community: Java
Topics: JCP Standards ,; Web 2.0 ,; Web Frameworks
Tags: AJAX ,; JSF ,; Java EE

JavaServer Faces 2.0 is the first major update of the Java EE standard specification since it was first released back in 2004. As such JSF 2.0 is a significant overhaul of the JSF specification and aims to address a number of the key pain points developers encounter when working with the web framework. Key changes include:

Replacing JSP with an alternative viewing technology based on Facelets.
Provision of a standardized resource handling mechanism: Many components require artifacts such as JavaScript files, images or CSS elements in order to render correctly. JSF 1.x has no facility for handling these so component developers typically have to develop their own mechanism.
Relocatable resources: Resources can be told where to render themselves, and this rendered location may be different from the resource tag placement in the view. This allows custom components and JSF pages to render resource references in the proper location so your CSS file reference can be included in the <head> section even if the component is included in the body.
System events: A publish/subscribe event model that supports events which are not specific to a particular application, but rather stem from specific points of time during the execution of a JSF application. Both UI components and the Application object (which is a singleton) can receive system events.
Additional scopes: A view scope and a component scope have been added. Support for a conversation scope is expected to be included through the Web Beans API.
Standardization of a "project stage" parameter: Project stage provides a means to affect JSF behaviour based on a set of pre-defined enums which may be set via a context parameter or JNDI. For example additional debug information might be displayed in a browser during development and suppressed in production. Defined stages are production, development, unit test, system test and extension with production as the default value. At run time you can query the application object for the configured value by calling Application.getProjectStage().
Reducing XML dependency by exploiting annotations and default values.
Extending the AJAX support introduced in JSF 1.2.

A number of these “big ticket” items come together to address one of the major pain points for developers working with JSF 1.x - the complexity of building custom components. With JSF 1.x a component author has to follow a number of steps to make a custom component available for use in markup pages. At a minimum, the component author has to implement both a JSP or Facelets Tag Handler, and provide a renderer for the component, both of which also require appropriate entries in the faces-config.xml file. Facelets, a JSF-centric alternative to JSP widely used by JSF developers, improves matters somewhat by providing support for templating via composite components. This approach involves creating an XHTML page that contains the template mark-up and components, and then using these as components in other pages. Any valid Facelet XHTML page can be used as a component, and unlike using Facelets with JSF 1.x, composite components in JSF 2 act as true UIComponents and can thus support validators, converters, and listeners (both action and value change). The composite components are handled as resources and can therefore exploit the new standard resource mechanism. So, for example, if a Facelet mark-up file named MenuPanel.html resides inside a resource library called ezcomp, then page authors can use this component by declaring the xml namespace xmlns:ez="http://java.sun.com/jsf/composite/ezcomp" and including the tag <ez:menuPanel /> in their pages.

The JSF 2.0 expert group have released Draft 2 for JSF 2.0 which is available for download from the JCP site. An implementation of the draft is also available. The specification is expected to reach final draft status by the end of the year.