Download
FAQ
History
HomeHomeNext API
Search
Feedback
Divider

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:

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

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.

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:

guessNumber Component Tree

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.

Divider
Download
FAQ
History
HomeHomeNext API
Search
Feedback
Divider

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.