Section 5.2. Structure of a JSF Application

5.2. Structure of a JSF Application

JSF applications are web applications built on the Java Servlet framework, so they follow the same general packaging scheme as any other J2EE application (see Chapter 2 for more information). The jar files for the JSF implementation must be available on the web application's classpath (usually accomplished by putting the appropriate jar files into the WEB-INF/lib directory).

For the reference implementation, the FacesServlet must be configured in the web.xml file for the application. This servlet provides the JSF engine: it's responsible for processing requests for JSF-based pages and returning the UI in HTML format. For our example, we're going to treat all resources with a .faces extension as a JSF target, so we configure the FacesServlet like this:

   <servlet>         <servlet-name>Faces Servlet</servlet-name>         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>         <load-on-startup>1</load-on-startup>     </servlet>       <!-- Faces Servlet Mapping -->     <servlet-mapping>         <servlet-name>Faces Servlet</servlet-name>         <url-pattern>*.faces</url-pattern>     </servlet-mapping>

Mapping *.faces to the FacesServlet instructs the servlet container to delegate all requests ending with .faces to the JSF engine.

5.2.1. JSF Lifecycle

So what happens when a request is sent to the JSF engine? In short, the JSF engine creates a tree containing a set of "components," each corresponding to an element of the user interface for the page being submitted, and ensures that the correct user values are applied to those components. The component tree is used to process the request, and an appropriate response is generated for the user. The FacesServlet accomplishes this in six steps:

1. Restore view

   The JSF engine looks at the request and matches it to a view definition, which is usually defined in a JSP file. By default, the view definition is found by looking for a .jsp file with the same base name as the request URI. A request for /view/books.faces will use /view/books.jsp as the view definition. The engine then creates the component tree based on the view definition.

2. Apply request values

   If any HTTP parameters were submitted along with the request, the JSF engine will try to map them to specific user interface components on the page. Otherwise, the engine skips to step 6, which renders the page and returns it to the client.

3. Process validations

   After applying any request values to the page, the JSF engine will cycle through all of the input validators associated with each component. If any validations fail, the page is rerendered with the original data, and, depending on how the developer set the page up, warning messages may be displayed.

4. Update model values

   If the validation process succeeds, the underlying Java beans associated with each UI component are updated.

5. Invoke application

   After the model has been updated, the JSF engine invokes any business logic actions requested by the user.

6. Render response

   The JSF engine renders a response for the user. Depending on the results of step 5, this may be the view associated with the page that was originally requested, or it may be a different view.

After steps 2 through 5, the JSF engine will process any events that were triggered during the processing activity. The event model allows you to override the lifecycle if necessaryfor instance, jumping from the Apply Request Values phase to the Render Response phase. We won't get into that in much detail in this chapter, but you should know the capability is there.

The Restore View phase is particularly important. This is where the JSF engine produces the component tree, which is an object hierarchy containing all of the JSF UI components within the requested view. This tree is used for all of the subsequent processing stages, and it maintains its state across multiple requestswe'll see an example of how this works when we talk about user interface events in a few pages.

5.2.2. The JSF Configuration File

JSF relies heavily on a single configuration file , faces-config.xml, located in your web application's WEB-INF directory. This file is where you keep track of navigation rules, managed beans, localization information, and any other configuration data required by more advanced JSF features. Configuring web applications via XML will be familiar to users of Struts, although the JSF framework does more behind the scenes than Struts does, reducing the overall complexity of the file. For example, you don't have to define your action classes and the related forms as you do in Struts: the server loads Faces resources automatically based on URL patterns.

Here's an example of a very simple faces-config.xml file for the sample application. We'll look at it in more detail shortly.

 <?xml version='1.0' encoding='UTF-8'?>   <!DOCTYPE faces-config PUBLIC   "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"   "http://java.sun.com/dtd/web-facesconfig_1_1.dtd">   <faces-config>       <application>         <locale-config>             <default-locale>en</default-locale>         </locale-config>     </application>         <!-- Navigation rules here -->       <!-- Bean definitions here -->   </faces-config>

In the beginning of the file, we define the application's default localization setting, which is English. In the rest of this section, we'll show how to set up the various Java beans we want JSF to manage for us and the navigation rules our application should follow.

If the file gets too unwieldy, you can split it into parts, with each file defining configuration information for a subset of your application. To do this, add an initialization parameter named javax.faces.CONFIG_FILES to the FacesServlet configuration in web.xml, containing a comma-separated list of configuration files. Large projects with multiple developers will probably need to do this since it allows you to define settings for different modules of an application separately.