What is the JavaServer Faces Framework?

The JavaServer Faces framework (JSR 314) is an integral part of the Java EE platform and aims to facilitate web development by providing the following:

• a user interface component model: JSF includes a standard component API, which enables you to use and create custom UI components for your applications. A UI component is a widget that has a specific appearance and guarantees certain behavior. For example, this can be a simple text field that includes built-in data validation and conversion with accompanying error messages, or it can be a complex data table that interacts with a back-end data store and offers scrolling and column sorting for users. Being able to reuse UI components for your application's interface (or acquire custom components from third-party vendors) becomes increasingly important as your application grows in size and complexity.
• an MVC development infrastructure: The framework provides a FacesServlet which works behind the scenes to dispatch requests to their appropriate handlers (usually backing beans that you create). You author page views using Facelets, the default view handler technology for JSF 2.0. These features, when operating in tandem with JSF's request processing lifecycle (described below), encourage your work to adhere to the MVC paradigm.

The JSF framework manages the request-response cycle by automating events that typically need to occur for each client request. These events are qualified into six distinct phases that are together known as the JSF request processing lifecycle. The book, JavaServer Faces 2.0: The Complete Reference by Ed Burns and Chris Schalk, describes the lifecycle phases as follows:

[T]he request processing lifecycle performs all of the necessary back-end processing for which one would otherwise have to write his or her own code. The lifecycle directs the processing of incoming request parameters, and it manages a server-side set of UI components and synchronizes them to what the user sees in a client browser. It also satisfies follow-up requests for images, style sheets, scripts, and other kinds of resources required to complete the rendering of the UI.^[1]

The six lifecycle phases, according to JavaServer Faces 2.0, are defined as follows:

1. Create or Restore View: Restores or creates a server-side component tree (View) in memory to represent the UI information from a client.
2. Apply Request Values: Updates the server-side components with fresh data from the client.
3. Process Validations: Performs validation and data type conversion on the new data.
4. Update Model Values: Updates any server-side Model objects with new data.
5. Invoke Application: Invokes any application logic needed to fulfill the request and navigate to a new page if needed.
6. Render Response: Saves state and renders a response to the requesting client.^[2]

One important concept of the JSF framework is the server-side UI component tree, or Faces View. This component tree is built and maintained in server memory for each client request, and is primarily associated with the first and last phases of the request processing lifecycle depicted above. Consequently, the application is able to maintain state between requests in a way that doesn't involve any manual coding on the part of the developer. In other words, the request processing lifecycle handles synchronization between the server-side View and that which is presented to the client. This enables you, the Java web developer, to focus on code that is specific to your business problem.

How Can JSF Benefit Your Project?

To understand JSF's benefits, let's take a second look at the AffableBean project and consider how the framework could be applied.

Strong Templating Support

Rather than creating your application page views in JSP pages, you'd be using Facelets technology instead.^[3] Facelets is a first-rate templating technology that enables you to maximize markup reuse and reduce redundancy in your page views. Also, because Facelets pages use the .xhtml file extension, you are able prepare views using standard XHTML syntax.

In the AffableBean project, we took measures to reduce redundancy by factoring out the header and footer markup for all page views into separate JSP fragment files, and then included them in views by using the <include-prelude> and <include-coda> elements in the deployment descriptor. Aside from the header, the layouts for each of the application's five page views were unique. However, many websites maintain the same layout across multiple pages. This is where templating comes in especially handy.

With Facelets templating, you have more control over which portions of markup get displayed for individual page views. For example, you could create a template layout that is common to all page views, and insert view-specific content into the template to render your views. In this manner, you could specify a title for each page view. (Notice that in the AffableBean application, the title remains the same for all page views.)

No Need to Handle Incoming Request Parameters

Upon reexamining the AffableBean's ControllerServlet, you can see that each time we implemented code for the supported URL patterns, it was necessary to manually extract user parameters using the request's getParameter method. When working in JSF, you often create backing beans, which are Java classes that are conceptually bound to a specific page view. Parameters are automatically extracted from a request (during phase 2 of the request processing lifecycle), and set as properties for the backing bean. JSF also takes care of casting the String values of your request parameters into the types that you have defined for your backing bean properties. For example, if you have a property defined as an int, and your incoming request parameter is a String whose value is "33", JSF automatically converts the value to an int before storing it in the backing bean.

No Need to Programmatically Configure Navigation

In order to set up navigation, we followed a certain pattern when implementing the ControllerServlet: For each incoming request, the getServletPath method is called to determine the requested URL pattern. After logic related to the URL pattern is performed, a RequestDispatcher is attained, and the request is forwarded to the appropriate page view. In numerous cases, the appropriate page view is specified by hard-coding the path using the userPath variable.

None of this is necessary when using JSF - navigation is handled by the framework. Your job would be to either associate page views with URL patterns and any logical outcomes using a Faces configuration file, or take advantage of JSF 2.0's implicit navigation feature, which automatically forwards a request to a view that has the same name as the requested URL pattern.

Built-in Validation Support

JavaServer Faces provides built-in server-side validation support. In the AffableBean project, we created a Validator class and manually coded logic to perform all validation. Using JSF, server-side validation would automatically occur at phase 3 of the request processing lifecycle.

It would be worthwhile to take advantage of this validation for the AffableBean checkout form, however some preliminary steps would be in order. Specifically, the HTML markup for form elements would need to be replaced with comparable tags from JSF's Standard HTML Library. This step converts the form elements into JSF UI components, which we can then specify validation actions on using JSF's Core Library. To give an idea, the side-by-side comparison below demonstrates an adaptation of the checkout form's "name" field.

<label for="name">name:</label>
<input type="text"
       id="name"
       size="30"
       maxlength="45"
       value="${param.name}" />

<c:if test="${!empty nameError}">
    Value is required.
</c:if>

<h:outputLabel value="name: " for="name">
    <h:inputText id="name"
                 size="30"
                 maxlength="45"
                 required="true"
                 value="#{checkoutBean.name}" />
</h:outputLabel>

<h:message for="name" />
                        

The <h:outputLabel> tag renders as an HTML <label> tag, whereas <h:inputText> renders as an <input> tag whose type is set to "text". Note the required attribute, which is set to true (shown in bold). This is all that's needed to ensure that the field is not left blank by the user. The <h:message> tag identifies the location where any validation error messages for the field should display. JSF's default error message for a field that requires user input is, "Value is required."

Continuing with the example, if we wanted to check whether input for the field hasn't exceeded 45 characters, we could apply the <f:validateLength> tag.

<h:outputLabel value="name: " for="name">
    <h:inputText id="name"
                 size="30"
                 maxlength="45"
                 required="true"
                 value="#{checkoutBean.name}">

        <f:validateLength maximum="45" />
    </h:inputText>
</h:outputLabel>

<h:message for="name" />

Well-Defined Division of Labor

As stated in the Java EE 6 Tutorial, "One of the greatest advantages of JavaServer Faces technology is that it offers a clean separation between behavior and presentation for web applications." If you are working on a large project that involves a team of developers, the framework functions as a blueprint which allows team members to focus on different areas of development simultaneously. For example, front-end developers can implement page views using tags from JSF's HTML Library, while programmers responsible for implementing component logic and behavior can "plug their work into" existing HTML library tags.

Ability to Render the View with Other Markup Languages

Suppose that the Affable Bean staff commission you at a later point to prepare a mobile version of their site, so users can access it using a hand-held device. JSF APIs are a flexible rendering technology that enable you to attach multiple renderers to the component tree (i.e., View) of a JSF-enabled application. In other words, it is possible to create custom components that, for example, render HTML when requested by a browser, or WML when requested by a PDA.

NetBeans Tutorials

JavaServer Faces

• Product Page: JavaServer Faces Technology
• Specification Download: JSR 314: JavaServer Faces 2.0
• Reference Implementation: GlassFish: Project Mojarra
• Official Forum: Web Tier APIs - JavaServer Faces
• The Java EE 6 Tutorial - Chapter 4: JavaServer Faces Technology
• The Java EE 6 Tutorial - Chapter 5: Introduction to Facelets
• JavaServer Faces 2.0: The Complete Reference [Book]
• Core JavaServer Faces [Book]
• JSF 2.0 Cookbook [Book]
• JSF 2.0 Refcard

GlassFish Web Hosting

• Joyent Cloud Hosting
• eApps Hosting
• Vision Web Hosting
• [DE]SYSTEMS
• JSPZone