Java Authors: Jerry Melnick, Elizabeth White, Liz McMillan, Andreas Grabner, Tim Hinds

Related Topics: Java, AJAX & REA

Java: Article

New Features in JavaServer Faces 2.0

Developing server-side user interfaces (UI) for Java EE applications

JavaServer Faces (JSF) technology is used for developing server-side user interfaces (UI) for Java EE applications. JSF 2.0 architecture has introduced several new features, most of which we shall discuss in this article. The salient new features in JSF 2.0 are State Saving, Facelets, Navigation, Validations, Scopes, AJAX, Resource Handling, Composite Components, View Params, Client Behaviors, Event Handling, and Exception Handling.

State Saving
In JSF 1.2 the full component tree is saved/restored. Attributes are also stored and restored. Saving and restoring the full state has performance and memory issues as the complete state has to be saved and restored and the size of the state saved could be large. In JSF 1.2 each UIComponent saves/restores its own state in the component hierarchy using saveState and resoreState methods in StateHolder. If state saving were to be optimized, it would have to be added to each component class in the hierarchy.

JSF 2.0 has introduced partial state saving in which the initial state of the component tree is marked and only the delta state changes due to modifications are saved, which makes the size of the state saved small. Re-executing the view and subsequently updating with the saved delta state change restores the component tree. Instead of implementing the StateHolder interface, components in JSF 2.0 implement the PartialStateHolder interface, which provides the partial state feature. PartialStateHolder provides methods shown in Table 1.

Table 1

To make it easier for UIComponents to implement PartialSatetHolder the StateHelper, which is a Map-like interface with methods such as add, eval, get, put, remove, is provided to store a component's state such as attributes and listeners. Partial state saving makes the size of the state saved about four times smaller. As the state is restored by re-executing the view, restoring of the component tree could take more time than in JSF 1.2.

By default, JSF 2.0 uses partial state saving. The javax.faces.PARTIAL_STATE_SAVING context-param is provided turn off/on partial state saving. The partial state saving param may be changed using the PARTIAL_STATE_SAVING_PARAM_NAME param.

To implement state saving, JSF 2.0 has introduced tree visiting. In JSF 1.2 only one component could be invoked in a single tree traversal using the UIComponent.invokeOnComponent() method. If multiple components are required to be invoked as in an AJAX request or state saving, multiple tree traversals have to applied. With the tree visiting, multiple components may be invoked in a single tree traversal. Tree visiting is implemented using the visitTree(VisitContext context,VisitCallback callback) method. VisitContext is a context object that holds state for component tree visit. VisitCallback is an interface to visit a specified UIComponent in tree visit.

JSF 1.2 used the JSP view technology. JSF 2.0 uses the Facelets view definition language (VDL) as the default view rendering technology. Facelets is an extension to JavaServer Faces (JSF) and uses XHTML syntax to define a JSF page. Facelets are XHTML pages and by default use the .xhtml extension. The default Facelets suffix is specified by the DEFAULT_FACELETS_SUFFIX context parameter. The Facelets view handler in JSF 1.2 had to be specified in faces-config.xml with the following configuration:


In JSF 2.0 a view handler is not configured and the default view handler javax.faces.application.ViewHandler is used. The default faces-config.xml for Facelets in JSF 2.0 is an empty file. The default value of the DEFAULT_FACELETS_SUFFIX constant in the ViewHandler view handler is .xhtml. Other Facelets view mappings(view pages to be interpreted as Facelets) may be specified using the javax.faces.FACELETS_VIEW_MAPPINGS context parameter:


Navigation in JSF 1.2 is configured using navigation rules based on outcomes from a view id in faces-config.xml. For example, to navigate to output.jsp if the outcome from input.jsp is "success" and to navigate to error.jsp if the outcome is "error", specify the following navigation rule in faces-config.xml:


JSF 2.0 has simplified navigation with the introduction of implicit navigation with which the navigation is based on the outcome. Implicitly the JSF application navigates to a view id with the same name as the outcome. For example, if the outcome is "output", the navigation handler navigates to output.xhtml, if provided. JSF 2.0 has also introduced conditional navigation with which the navigation handler navigates to a view id based on a condition EL expression specified in faces-config.xml. JSF 2.0 has also introduced the ConfigurableNavigationHandler class for configuring navigation programmatically. Preemptive navigation is another new feature used to determine the destination URL based on outcome. The new components h:button and h:link support preemptive navigation.

Validation in JSF 1.2 is implemented using built-in validators f:validateDoubleRange (for a double value with an optional range), f:validateLongRange(a long value with an optional range), and f:validateLength (a String with a minimum and maximum number of characters). JSF 1.2 also supports custom validators with the f:validator tag and the javax.faces.validator.Validator interface. JSF 1.2 did not have built-in provisions for empty field validation and validation with regular expressions.

JSF 2.0 has introduced validation of empty fields, which is also available for custom validators. Three new built-in validators have been added: f:validateRegex for regular expressions, f:validateRequired for required field, and f:validateBean for Bean validation, which is another new feature. Bean validation is implemented in conjunction with validation constrain annotations, which are defined in the javax.validation.constraints package. Validation constraint annotations annotate managed bean properties. For example the @Size annotation constrains size, and the @Pattern annotation requires conformance with a regular expression. Bean validation is supported with custom validators also.

Scopes and Configuration
As mentioned earlier the faces-config.xml in JSF 2.0 is an empty file. JSF 1.2 faces-config.xml has configuration for managed beans, managed bean properties, scopes, validators, converters, and renderers. JSF 2.0 has introduced annotations-based configuration for managed beans, managed bean properties, scopes, validators, converters, and renderers. New scopes: view, flash, and custom have been added for finer-grained scopes. JSF 2.0 has added a new configuration project stage that indicates the state of a project.

JSF 1.2 did not provide built-in support for AJAX, and an AJAX framework such as Ajax4jsf had to be used. Or AJAX had to be implemented with the XMLHttpRequest object without any framework. JSF 2.0 has added support for AJAX with the f:ajax tag, which includes support for partial page rendering and grouped components. AJAX support may also be added using the AJAX JSF library.

Resource Handling
Resources are files required by a JSF application such as CSS, JavaScript, and images. JSF 2.0 has added a ResourceHandler API that is based on path-based packaging conventions for serving resources. JSF 2.0 has also added new tags for resource handling; h:head, h:body, h:outputScript, and h:ouputStylesheet. Some of the other new resource handling features are relocating resources and ordering of multiple faces-config.xml application configuration resources.

Composite Components
JSF 2.0 has introduced a Composite Components tag library for creating composite components. A Composite component is a composite (collection) of other UI components. A composite component consists of a library, which makes use of the new resource handling feature, a definition page, and a using page, which are based on Facelets. A definition page defines a composite component and a using page makes use of a composite component.

View Params
JSF 1.2 includes support for sending parameters only in a POST request. View parameters add the provision to send request parameters in a GET request. View parameters are configured in the f:metadata tag using the f:viewParam tags. View params are EditableValueHolder components and may configured with validators and converters just as other EditableValueHolder components such as h:inputText. View parameters also support component system events using the f:event tag. Preemptive navigation, which was mentioned in the Navigation section, and bookmarking is made feasible with view params. View params may also be used with Faces redirects.

Client Behaviors
Behaviors are objects attached to components to provide additional functionality. Client behaviors are an implementation of behaviors with which scripts may be attached with components to be run from client-side events. A Facelet taglib is required for a client behavior. Client behaviors are added to a Facelets page using tags from the Facelets taglib.

Event Handling and Exception Handling
JSF 2.0 has introduced a new type of events called system events. System events are of two types: application scoped system events and component system events. System events are similar to, but with more precise granularity, to phase events. For event handling in an AJAX request the f:ajax tag includes a onevent attribute to register a callback Java Script function.

ExceptionHandler is a new class to handle unexpected exceptions. The f:ajax tag includes a onerror attribute for error handling callback function.

More Stories By Deepak Vohra

Deepak Vohra is a Sun Certified Java 1.4 Programmer and a Web developer.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.