JSF application life cycle

Phases of the JSF application life cycle

The six phases of the JSF application life cycle are:

1. Restore view
2. Apply request values; process events
3. Process validations; process events
4. Update model values; process events
5. Invoke application; process events
6. Render response

Phase 1: Restore view

In the first phase of the JSF life cycle — restore view — a request comes through the FacesServlet servlet. The servlet examines the request and extracts the view ID, which is determined by the name of the JSP page.

The JSF framework controller uses the view ID to look up the components for the current view. If the view doesn't already exist, the JSF controller creates it. If the view already exists, the JSF controller uses it. The view contains all the GUI components.

This phase of the life cycle presents three view instances: new view, initial view, and postback, with each one being handled differently. In the case of a new view, JSF builds the view of the Faces page and wires the event handlers and validators to the components. The view is saved in a FacesContext object.

The FacesContext stores the state information JSF needs to manage the GUI component's state for the current request. The FacesContext stores the view in its viewRoot property; viewRoot contains all the JSF components for the current view ID.

In the case of an initial view (the first time a page is loaded), JSF creates an empty view. The empty view is populated as the JSP page is processed. From an initial view, JSF advances directly to the render response phase.

In the case of a postback (the user returns to a page he or she has previously accessed), the view corresponding to the page already exists, so it needs only to be restored. In this case, JSF uses the existing view's state information to reconstruct its state.

Phase 2: Apply request values

The purpose of the apply request values phase is for each component to retrieve its current state. The components must first be retrieved or created from the FacesContext object, followed by their values. Component values are typically retrieved from the request parameters, although they can also be retrieved from cookies or headers. The value from the request parameter for many components is stored in the component's submittedValue.

If a component's immediate event-handling property is set to true, the values are converted to the proper type and validated (more on conversion in the next phase). The converted value is then stored in the component. If the value conversion or value validation fails, an error message is generated and queued in the FacesContext, where it will be displayed during the render response phase, along with any other validation errors.

Phase 3: Process validation

Conversion and validation normally happen in the process validation phase. The component converts the component's submittedValue and stores it. So if the field is bound to an Integer property (for example), the value is converted to an Integer. If the value conversion fails, an error message is generated and queued in the FacesContext, where it will be displayed during the render response phase, along with any validation errors.

The first event handling of the life cycle takes place after the apply request values phase. At this stage, each component's values are validated against the application's validation rules. The validation rules can be predefined (shipped with JSF) or defined by the developer. Values entered by the user are compared to the validation rules. If an entered value is invalid, an error message is added to FacesContext, and the component is marked as invalid. If a component is marked as invalid, JSF advances to the render response phase and skips the rest of the phases, which will display the current view with the validation error messages. If no validation errors occur, JSF advances to the update model values phase.

Phase 4: Update model values

The fourth phase of the JSF application life cycle — update model values — updates the server-side model's actual values by updating the properties of your managed beans. Only bean properties that are bound to a component's value are updated. Notice that this phase happens after validation, so you can be sure that the values copied to your beans' properties are valid (at least at the form-field level; they could still be invalid at the business-rule level).

Phase 5: Invoke application

At the fifth phase of the life cycle — invoke application — the JSF controller invokes the application to handle form submissions. The component values will have been converted, validated, and applied to the model objects, so you can now use them to execute the application's business logic.

It is during this phase that your action-handler methods are called, such as the persist() method and the read() methods in the sample application's ContactController.

At this phase, you also get to specify the next logical view for a given sequence or number of possible sequences. You do this by defining a specific outcome for a successful form submission and returning that outcome. For example: on successful outcome, move the user to the next page. For this navigation to work, you must create a mapping to the successful outcome as a navigation rule in the faces-config.xml file. Once the navigation occurs, you move to the final phase of the life cycle. JSF takes the object returned from the action method and calls its toString() method. Then it uses this value as the outcome for the navigation rules. (Part 1 covers configuring navigation rules.)

Phase 6: Render response

In the sixth phase of the life cycle — render response — you display the view with all of its components in their current state.

The figure below is an object state diagram of the six phases of the JSF application life cycle, including validation and event handling: