Life Cycle of JSF

The JSF framework processes a request in predefined steps similar to other Web application frameworks. You can also develop a Web application in JSF, without knowing the request processing details. This reduces the efforts in the enhancements of the existing JSF application. While discussing about the phases of the JSF request process life cycle, the request processing details are also explored.

The request-processing life cycle starts as soon as a request is submitted to the JSF controller Servlet and ends when the client receives a response for the request. Following are the six different phases of JSF request processing life cycle and are given in the order they are executed by the JSF framework:

1. The Restore View Phase
2. The Apply Request Values
3. Phase The Process Validation Phase
4. The Update Model Values Phase
5. The Invoke Application Phase
6. The Render Response Phase

The execution of all these phases is not required for a given request. The request processing life cycle can be terminated in any phase by executing FacesContext.responseComplete() method, which skips the other phases of the life cycle. For example, when an invalid input is found in the Process Validation Phase, the current page/view is to be redisplayed and some of the phases, such as the Invoke Application Phase, may not execute.

These phases altogether make sure that the processing of a request follows a logical path. For example, no application logic is executed before the form is validated for the input data. Further, implementation of these life cycle phases helps a developer in concentrating on business logic instead of form validation and data conversion. The basic idea behind implementing the life cycle is to make sure that before executing any business logic invoked as a consequence of some action, we have a fully populated backing bean with all validated data.

If you want to create custom JSF UI components, you need to concentrate on the first and last phases of the JSF request processing life cycle.

In a JSF-based application, whenever a request is received by the controller Servlet, an instance of the javax.faces.context.Facescontext class is created. The FacesContext object contains the state information related to the current JSF request. The FacesContext object is accessed and modified in almost all the request life cycle phases. Let’s discuss all six phases of the JSF request processing life cycle with the description of all the functions performed by the framework.

1. The Restore View Phase

A view can be defined as a collection of components in a request page. All the components in a request page or view are grouped together as a tree; therefore, every view is a tree of components having a unique identification, that is view ID. The JSF controller Servlet finds the view ID from the request, which can be determined by the requested JSP page name. The controller can load the existing view or can create a new view if it does not exist.

The Restore View phase can handle three different views, new view, initial view, and postback. In the case of a new view, this phase creates the view of the request page and associates event handlers and validators to the components in the view. This phase also stores the view as a root component using setViewRoot() method on FacesContext instance. When the JSF page is requested for the first time, the view needs to be loaded for the first time (initial view) and the controller creates an empty view. In the case of the initial view, the framework directly moves to render the response page.

If the user requests a page accessed earlier (postback), the controller needs to restore the view with the current state of the view. In the case of postback, the next phase after the Restore View phase is the Apply Request Values phase.

2. The Apply Request Values Phase

There is a set of JSF UI components that receive the input as request data from the user and then process it. In the Apply Request Values phase, the JSF implementation iterates the component objects in the component tree and requests every component to decode itself. Decoding is the process in which the framework sets the submitted values for the components based on the request parameters. The component value can be validated in this phase if the immediate property is true for the component. In case of validation error, an error message is added and the render response phase starts. If the immediate property of the component is set to false, then the submitted string values are converted into the desired data type. At the end of this phase, each component stores recent values submitted through the current request. After the completion of this phase, the existing events are broadcasted for the associated event listeners.

The action events can fire in this phase but are handled in the invoke application phase. In this phase, they are created and added to the FacesContext instance.

3. The Process Validation Phase

In this phase, the values of all the components are validated against some validation rules. We can associate a given component with some JSF standard validator or can define our own validators. The validators are registered with the components of the JSF page. In case, the value of a given component is found invalid, a validation error message is added in the FacesContext and the render response phase starts to display the current view with the validation message. The following code snippet shows an Html input Text component created with a validator to validate its value for its length:

All the value change events associated with different components are fired and used by the appropriate listener in this phase. If all the submitted values are found valid, the framework enters into the update model values phase of the life cycle.

4. The Update Model Values Phase

The Process Validation phase ensures that all component values are valid. After validating component values, all values of the backing beans or model objects are updated with the component values to save the state of components so that these values can be used in subsequent requests. Every component can be associated with some backing bean property and the backing bean is updated with the current value of the component. The following code snippet shows the code to associate the name property of student backing bean with an Html Input Text component:

In the preceding code snippet, backing bean properties are associated with a component through a value binding expression, such as #{sudent.name}. When these expressions are evaluated, FacesServlet searches for the appropriate backing beans in request, application, or session scope. By the end of this phase, we have all component values set with all validated user inputs and updated backing beans. Now, we are ready to execute our business logic in the invoke application phase.

5. The Invoke Application Phase

In the previous phases, we have not executed any business logic. We have just updated the component model and backing bean model with the current and valid data. In the Apply Request Values phase, we have added all action events in the FacesContext for their handling in the invoke application phase. In the invoke application phase, the JSF framework broadcasts all the added action events, which are further handled by the registered action event listeners. We can register some backing bean methods as action listeners or action methods. The action method may contain the logic for different operations, such as rendering responses and adding messages. Action methods are also integrated with the navigation model and help in determining the next view or page to be displayed.

After the completion of all phases and handling of all events by the respective listeners, the framework is ready with the next view for the user.

6. The Render Response phase

The Render Response phase is the last phase in the JSF request-processing life cycle. This phase is responsible for sending responses to the client. The state of the view (component tree) is saved in this phase before the response is rendered for the client. The state of the view can be stored on the server-side using client session or can be saved on the client-side using hidden fields. Saving the state of a view is important, so that it can be restored in the Restore view phase in case of postback. In the case of postback, all error messages that are added in the Apply Request Values phase, Process Validation phase, or Update Model Values phase are also displayed along with the current state of the components in the view.

JSF framework is not bound to a particular display technology to render the response to the client. We can have different approaches to render the responses. We can use the output of the encoding method with the markup code, which is either stored in some template resource or generated by another application for the client. The JSF implementation uses a different approach, that is, it uses the output of decoding methods with some dynamic resources such as the JSP page.

During the Render Response phase, all component values are converted into a string to be displayed. When this phase completes, the Web container sents the response to the client as a response page in the browser.

We have discussed all six phases of the JSF request processing life cycle that explain how a JSF request is changed into JSF response. A brief explanation of Faces and Non-Faces request and responses are as follows:

• Faces Response: Refers to the Servlet response constructed after the execution of Render Response phase of the request processing life cycle.
• Non-Faces Response: Refers to the Servlet response, which is not constructed by the execution of Render Response phase, for example, a JSP page that does not have JSF components.
• Faces Request: Refers to the Servlet request sent from previously generated faces response, for example, a form submitted from a JSF UI component, where request URI recognizes JSF component tree for processing the request.
• Non-Faces Request: Refers to the Servlet request sent to an application component, such as Servlet or JSP page, rather than directed to the JSF component tree.

These four request and response types lead to four combinations, which define the request and response scenarios that may occur in a Web application based on JSF. In the case of Non-Faces request or Non-Faces response, the JSF request processing life cycle is not followed.

Learn more about JSF Architecture.