Download FAQ History |  | API Search Feedback

> ## The Lifecycle of a JavaServer Faces Page

> The lifecycle of a JavaServer Faces page is similar to that of a JSP page: The client makes an HTTP request for the page, and the server responds with the page translated to HTML. However, because of the extra features that JavaServer Faces technology offers, the lifecycle provides some additional services by executing some extra steps.

> Which steps in the lifecycle are executed depends on whether or not the request originated from a JavaServer Faces application and whether or not the response is generated with the rendering phase of the JavaServer Faces lifecycle. This section first explains the different lifecycle scenarios. It then explains each of these lifecycle phases using the `guessNumber` example.

> ### Request Processing Lifecycle Scenarios

> A JavaServer Faces application supports two different kinds of responses and two different kinds of requests:

> - Faces Response: A servlet response that was created by the execution of the Render Response phase of the request processing lifecycle.
> - Non-Faces Response: A servlet response that was not created by the execution of the Render Response phase. An example is a JSP page that does not incorporate JavaServer Faces components.
> - Faces Request: A servlet request that was sent from a previously generated Faces Response. An example is a form submit from a JavaServer Faces user interface component, where the request URI identifies the JavaServer Faces component tree to use for processing the request.
> - Non-Faces Request: A servlet request that was sent to an application component, such as a servlet or JSP page, rather than directed to a JavaServer Faces component tree.

> These different requests and responses result in three possible lifecycle scenarios that can exist for a JavaServer Faces application:

> - Scenario 1: Non-Faces Request Generates Faces Response
>   An example of this scenario is when clicking a hyperlink on an HTML page opens a page containing JavaServer Faces components. To render a Faces Response from a Non-Faces Request, an application must provide a mapping to the `FacesServlet` in the URL to the page containing JavaServer Faces components. The `FacesServlet` accepts incoming requests and passes them to the lifecycle implementation for processing. Section describes how to provide a mapping to the `FacesServlet`.
> - Scenario 2: Faces Request Generates Non-Faces Response
>   Sometimes a JavaServer Faces application might need to redirect to a different Web application resource or generate a response that does not contain any JavaServer Faces components. In these situations, the developer must skip the rendering phase (Render Response) by calling `FacesContext.responseComplete`. The `FacesContext` contains all of the information associated with a particular Faces Request. This method can be invoked during the Apply Request Values, Process Validations, or Update Model Values phases.
> - Scenario 3: Faces Request Generates Faces Response
>   This is the most common scenario for the lifecycle of a JavaServer Faces application. It is also the scenario represented by the standard request processing lifecycle described in the next section. This scenario involves JavaServer Faces components submitting a request to a JavaServer Faces application utilizing the `FacesServlet`. Because the request has been handled by the JavaServer Faces implementation, no additional steps are required by the application to generate the response. All listeners, validators and converters will automatically be invoked during the appropriate phase of the standard lifecycle, which the next section describes.

> ### Standard Request Processing Lifecycle

> The standard request processing lifecycle represents scenario 3, described in the previous section. Most users of JavaServer Faces technology won't need to concern themselves with the request processing lifecycle. However, knowing that JavaServer Faces technology properly performs the processing of a page, a developer of JavaServer Faces applications doesn't need to worry about rendering problems associated with other UI framework technologies. One example involves state changes on individual components. If the selection of a component such as a checkbox effects the appearance of another component on the page, JavaServer Faces technology will handle this event properly and will not allow the page to be rendered without reflecting this change.

> Figure 20-2 illustrates the steps in the JavaServer Faces request-response lifecycle.

> Figure 20-2 JavaServer Faces Request-Response Lifecycle

> #### Reconstitute Component Tree

> When a request for a JavaServer Faces page is made, such as when clicking on a link or a button, the JavaServer Faces implementation begins the Reconstitute Component Tree stage.

> During this phase, the JavaServer Faces implementation builds the component tree of the JavaServer Faces page, wires up event handlers and validators, and saves the tree in the `FacesContext`. The component tree for the `greeting.jsp` page of the `guessNumber` example might conceptually look like this:

> Figure 20-3 `guessNumber` Component Tree

> #### Apply Request Values

> Once the component tree is built, each component in the tree extracts its new value from the request parameters with its `decode` method. The value is then stored locally on the component. If the conversion of the value fails, an error message associated with the component is generated and queued on the `FacesContext`. This message will be displayed during the Render Response phase, along with any validation errors resulting from the Process Validations phase.

> If events have been queued during this phase, the JavaServer Faces implementation broadcasts the events to interested listeners. See Implementing an Event Listener for more information on how to specify which lifecycle processing phase the listener will process events.

> At this point, if the application needs to redirect to a different Web application resource or generate a response that does not contain any JavaServer Faces components, it can call `FacesContext.responseComplete`.

> In the case of the `userNumber` component on the `greeting.jsp` page, the value is whatever the user entered in the field. Since the model object property bound to the component has an `Integer` type, the JavaServer Faces implementation converts the value from a `String` to an `Integer`.

> At this point, the components are set to their new values, and messages and events have been queued.

> #### Process Validations

> During this phase, the JavaServer Faces implementation processes all validations registered on the components in the tree. It examines the component attributes that specify the rules for the validation and compares these rules to the local value stored for the component. If the local value is invalid, the JavaServer Faces implementation adds an error message to the `FacesContext` and the lifecycle advances directly to the Render Response phase so that the page is rendered again with the error messages displayed. If there were conversion errors from Apply Request Values, the messages for these errors are displayed also.

> At this point, if the application needs to redirect to a different Web application resource or generate a response that does not contain any JavaServer Faces components, it can call `FacesContext.responseComplete`.

> If events have been queued during this phase, the JavaServer Faces implementation broadcasts them to interested listeners. See Implementing an Event Listener for more information on how to specify in which lifecycle processing phase a listener will process events.

> In the `greeting.jsp` page, the JavaServer Faces implementation processes the validator on the `userNumber` `input_number` tag. It verifies that the data the user entered in the text field is an integer from the range 0 to 10. If the data is invalid, or conversion errors occurred during the Apply Request Values phase, processing jumps to the Render Response phase, during which the `greeting.jsp` page is rendered again with the validation and conversion error messages displayed in the component associated with the `output_errors` tag.

> #### Update Model Values

> Once the JavaServer Faces implementation determines that the data is valid, it can walk the component tree and set the corresponding model object values to the components' local values. Only input components that have `valueRef` expressions will be updated. If the local data cannot be converted to the types specified by the model object properties, the lifecycle advances directly to Render Response so that the page is re-rendered with errors displayed, similar to what happens with validation errors.

> At this point, if the application needs to redirect to a different Web application resource or generate a response that does not contain any JavaServer Faces components, it can call `FacesContext.responseComplete`.

> If events have been queued during this phase, the JavaServer Faces implementation broadcasts them to interested listeners. See Implementing an Event Listener for more information on how to specify in which lifecycle processing phase a listener will process events.

> At this stage, the `userNumber` property of the `UserNumberBean` is set to the local value of the `userNumber` component.

> #### Invoke Application

> During this phase, the JavaServer Faces implementation handles any application-level events, such as submitting a form or linking to another page.

> At this point, if the application needs to redirect to a different Web application resource or generate a response that does not contain any JavaServer Faces components, it can call `FacesContext.responseComplete`.

> The `greeting.jsp` page from the `guessNumber` example has one application-level event associated with the `Command` component. When processing this event, a default `ActionListener` implementation retrieves the outcome, "success", from the component's `action` attribute. The listener passes the outcome to the default `NavigationHandler`. The `NavigationHandler` matches the outcome to the proper navigation rule defined in the application's application configuration file to determine what page needs to be displayed next. See Navigating Between Pages for more information on managing page navigation. The JavaServer Faces implementation then sets the response component tree to that of the new page. Finally, the JavaServer Faces implementation transfers control to the Render Response phase.

> #### Render Response

> During the Render Response phase, the JavaServer Faces implementation invokes the components' encoding functionality and renders the components from the component tree saved in the `FacesContext`.

> If errors were encountered during the Apply Request Values phase, Process Validations phase, or Update Model Values phase, the original page is rendered during this phase. If the pages contain `output_errors` tags, any queued error messages are displayed on the page.

> New components can be added to the tree if the application includes custom renderers, which define how to render a component. After the content of the tree is rendered, the tree is saved so that subsequent requests can access it and it is available to the Reconstitute Component Tree phase. The Reconstitute Component Tree phase accesses the tree during a subsequent request.

Download FAQ History |  | API Search Feedback

All of the material in The Java(TM) Web Services Tutorial is copyright-protected and may not be published in other works without express written permission from Sun Microsystems.