Programming Tutorials

JSF Life Cycle

By: Fazal in JSF Tutorials on 2007-09-18  

Regardless of whether you are using JSF with JSP pages, servlets, or some other web technology, each request/response flow that involves JSF follows a certain life cycle. Several kinds of request/response cycles can occur in a JSF-enabled application. You can have a request that comes from a previously rendered JSF page (a JSF request) and a request that comes from a non-JSF page (a non-JSF request). Likewise, you can have a JSF response or a non-JSF response. We are concerned with these three request/response pairs:

• Non-JSF request generates JSF response
• JSF request generates JSF response
• JSF request generates non-JSF response

Of course, you can also have a non-JSF request that generates a non-JSF response. Because this does not involve JSF in any way, the JSF life cycle does not apply.

JSP pages have a relatively simple life cycle. A JSP page source is compiled into a page implementation class. When a web server receives a request, that request is passed to the container, which passes the request to the page class. The page class processes the request and then writes the response back to the client. When other pages are included or the request is forwarded, or when an exception occurs, the process includes a few more components or pages, but basically, a small set of classes processes a request and sends back a response.

When using JSF, the life cycle is more complicated. This is because the core of JSF is the MVC pattern, which has several implications. User actions in JSF-generated views take place in a client that does not have a permanent connection to the server. The delivery of user actions or page events is delayed until a new connection is established. The JSF life cycle must handle this delay between event and event processing. Also, the JSF life cycle must ensure that the view is correct before rendering the view. To ensure that the business state is never invalid, the JSF system includes a phase for validating inputs and another for updating the model only after all inputs pass validation.

In MVC, the presentation of data (the view) is separate from its representation in the system (the model). When the model is updated, the controller sends a message to the view, telling the view to update its presentation. When the user takes some action with the presentation, the controller sends a message to the model, telling the model to update its data. In JSF, the model is composed of business objects that are usually implemented as JavaBeans, the controller is the JSF implementation, and the UI components are the view.

The JSF life cycle has six phases as defined by the JSF specification:

• Restore View: In this phase, the JSF implementation restores the objects and data structures that represent the view of the request. Of course, if this is the client's first visit to a page, the JSF implementation must create the view. When a JSF implementation creates and renders a JSF-enabled page, it creates UI objects for each view component. The components are stored in a component tree, and the state of the UI view is saved for subsequent requests. If this is a subsequent request, the previously saved UI view is retrieved for the processing of the current request.
• Apply Request Values: Any data that was sent as part of the request is passed to the appropriate UI objects that compose the view. Those objects update their state with the data values. Data can come from input fields in a web form, from cookies sent as part of the request, or from request headers. Data for some components, such as components that create HTML input fields, is validated at this time. Note that this does not yet update the business objects that compose the model. It updates only the UI components with the new data.
• Process Validations: The data that was submitted with the form is validated (if it was not validated in the previous phase). As with the previous phase, this does not yet update the business objects in the application. This is because if the JSF implementation began to update the business objects as data was validated, and a piece of data failed validation, the model would be partially updated and in an invalid state.
• Update Model Values: After all validations are complete, the business objects that make up the application are updated with the validated data from the request. In addition, if any of the data needs to be converted to a different format to update the model (for example, converting a String to a Date object), the conversion occurs in this phase. Conversion is needed when the data type of a property is not a String or a Java primitive.
• Invoke Application: During this phase, the action method of any command button or link that was activated is called. In addition, any events that were generated during previous phases and that have not yet been handled are passed to the web application so that it can complete any other processing of the request that is required.
• Render Response: The response UI components are rendered, and the response is sent to the client. The state of the UI components is saved so that the component tree can be restored when the client sends another request. For a JSF-enabled application, the thread of execution for a request/response cycle can flow through each phase, in the order listed here and as shown in Figure below. However, depending on the request, and what happens during the processing and response, not every request will flow through all six phases.

In Figure, you can see a number of optional paths through the life cycle. For example, if errors occur during any of the phases, the flow of execution transfers immediately to the Render Response phase, skipping any remaining phases. One way this might occur is if input data is incorrect or invalid. If data fails validation in either the Apply Request Values or Process Validations phase, information about the error is saved and processing proceeds directly to the Render Response phase. Also, if at any point in the life cycle the request processing is complete and a non-JSF response is to be sent to the client, the flow of execution can exit the life cycle without completing further phases.