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 theFacesServlet
in the URL to the page containing JavaServer Faces components. TheFacesServlet
accepts incoming requests and passes them to the lifecycle implementation for processing. Section Invoking the FacesServlet (page 818) describes how to provide a mapping to theFacesServlet
.- 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 callingFacesContext.responseComplete
. TheFacesContext
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 theFacesServlet
. 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 thegreeting.jsp
page of theguessNumber
example might conceptually look like this:
![]()
Figure 20-3
guessNumber
Component TreeApply 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 theFacesContext
. 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 (page 885) 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 thegreeting.jsp
page, the value is whatever the user entered in the field. Since the model object property bound to the component has anInteger
type, the JavaServer Faces implementation converts the value from aString
to anInteger
.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 (page 885) 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 theuserNumber
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 thegreeting.jsp
page is rendered again with the validation and conversion error messages displayed in the component associated with theoutput_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 (page 885) for more information on how to specify in which lifecycle processing phase a listener will process events.
At this stage, the
userNumber
property of theUserNumberBean
is set to the local value of theuserNumber
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 theguessNumber
example has one application-level event associated with theCommand
component. When processing this event, a defaultActionListener
implementation retrieves the outcome, "success", from the component'saction
attribute. The listener passes the outcome to the defaultNavigationHandler
. TheNavigationHandler
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 (page 890) 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.