Spring Web Flow for better workflow management in JSF

An alternative to the JavaServer Faces CustomNavigationHandler

JavaServer Faces is a powerful framework for component-based Web UI development, but its CustomNavigationHandler introduces more complexity into rules-based navigation than you need. In this article, Ravi Shankar Nair shows you how to integrate a little flow -- Spring Web Flow, that is -- into an existing JSF application, bringing truly customizable and reusable navigation to your evolving JSF applications.

JavaServer Faces (JSF) is a successful technology for component-based Web UI development. One of the main advantages of JSF's component-based approach is that you need not revamp your application every time client technologies evolve, as they tend to do. The popularity of JSF also is growing with the emergence of JSF extension frameworks like Seam, MyFaces, and ICEfaces.

Java Web application development with JSF can be surprisingly easy once you master its intricacies. That said, JSF's default mechanism for managing workflow is not very powerful in terms of integration with existing technologies. Enterprise systems require more advanced workflow management than JSF provides. JSF falls short when it comes to embedding rules to determine the destination and routing of non-JSF pages, as well as handling exceptions and global transitions.

In this article I share my experience of integrating the open source Web application framework Spring Web Flow with JSF. JSF beginners through intermediate developers will benefit from the practical examples, illustrations, and code snippets in the article. You will learn something about JSF and Spring Web Flow, as well as being introduced to an integrated development solution that leverages them both.

JSF in brief

JavaServer Faces is a Java-based Web application framework that simplifies the development of user interfaces for Java Web applications. Unlike other traditional request-driven MVC Web frameworks, JSF uses a component-based approach. The state of UI components is saved when the client requests a new page and then is restored when the request is returned. Out of the box, JSF uses JavaServer Pages as its display technology. It can also accommodate other display technologies, such as XML User Interface Language. JSF includes the following:

  • A set of APIs for representing UI components and managing their state, handling events and input validation, converting values, defining page navigation, and supporting internationalization and accessibility
  • A default set of UI components
  • Two JSP custom tag libraries for expressing JSP pages
  • Faces interface within a JSP page
  • A server-side event model
  • State management
  • Managed Beans (Java beans created with dependency injection)
  • Unified Expression Language for both JSP 2.0 and JSF 1.2

The JSF specification was developed under the Java Community Process as JSR 127, which defined JSF 1.0 and JSF 1.1, and JSR 252, which defined JSF 1.2. JSF 2.0 is being developed as JSR 314.

JSF's request processing lifecycle

JSF represents an exceptionally sophisticated implementation of the traditional MVC/Model 2 architecture, as shown in Figure 1. Unlike other Model 2 architectures, the controller servlet in JSF (FacesServlet) cannot be extended, because it is a final Java class.

A diagram showing how JSF implements MVC.
Figure 1. JavaServer Faces implements the MVC pattern

One of the biggest advantages of JSF is that it automatically assigns form components (such as fields or checkboxes) to the fields/methods of the data model. JSF uses Unified Expression Language for this value/method binding. The innumerable code snippets typically associated with request.getParameter() are simply replaced with these binding expressions.

As is the case with any Web application, the primary task is to take requests (mostly instances of HttpRequest) from the client and deliver responses (mostly instances of HttpServletResponse). Client in this case refers to Web browsers such as IE and Firefox. As you see in Figure 1, however, JSF can also render responses from mobile device clients and other sorts of browsers.

The process of taking data through the entire request-response lifecycle is divided into a series of steps, or phases, as shown in Figure 2.

A diagram showing the JSF request-processing lifecycle.
Figure 2. The JSF request-processing lifecycle

Figure 2 depicts the six phases of the JSF lifecycle, which is explained in detail elsewhere on JavaWorld. I'll just briefly list the phases here:

Restore View
Creates a server-side component tree representing the application UI.
Apply Request Values
Issues a request.Parameter for all fields of the UI (all Strings).
Process Validations/Conversions
Validates strings and converts them to data types.
Update Model
Updates model objects with fresh/new data.
Invoke Application
Invokes application logic (such as a business method of an EJB) and navigates to a new page if necessary.
Render Response
The response may be rendered in HTML, XUL, or WML, depending on the client device.
1 2 3 4 Page 1
Page 1 of 4