JSF provides a well defined processing life-cycle for handling page request and form post. It really isn’t necessary to understand the JSF life-cycle to use JSF but it helps when attempting to understand the process of applying values, conversion, validation, event handling, exceptions and rendering. The six phases show the order in which JSF typically processes a form post. The list shows the phases in their likely order of execution but the life-cycle can be short-circuited, which is what happens during form validation errors, pressing a cancel button or by setting a components immediate attribute to ‘true’.
The six phases of a request process
Restore view
JSF keeps a copy of the client view and component state on the server. During the restore view phase the JSF implementation will either create a new view for an initial page request, or render the server-side copy during a post-back request.
Apply request values
Updates the server-side view with the new component values.
Process validations
Performs conversion and/or validation of new component values.
Update model values
Updates the server-side component’s with their new values.
Invoke application
Invokes any server-side application logic contained within your managed bean.
Render response
Renders the new view as directed by your backing bean and/or navigation mapping.
The six phases discussion
Restore View
The Faces View is the server-side representation of the JSF UI component tree. The restore view phase will either create a fresh view or restore an existing view, if one exists. JSF stores all views and their component states within an object called the FacesContext. When the FacesServlet controller receives a request it examines the view id to determine if there is an existing copy of the view in storage. The FacesContext object contains all the state information JSF needs to manage the GUI component’s state for the current request in the current session. The FacesContext stores the view in its viewRoot property; viewRoot contains all the JSF components for the current view ID and the components state. Once the view has been created, or retrieved, JSF advances directly to the render response phase.
Apply Request Values
The purpose of the apply request values phase is for each component to retrieve its current state. During this phase the JSF runtime performs the job of processing name-value pairs from the incoming request. JSF assigns the request values to the components by calling the decode() method on each component in the view hierarchy. The decode() method process’ the request value and assigns it to the local value attribute of the component. If there are any errors during the value assignment an error message is generated and queued in the FacesContext object, where it will be displayed during the render response phase. If a component’s immediate attribute is set to true, then conversion, validation and events associated with the component are processed in this time.
Process Validation
Conversion and validation occurs when the JSF runtime calls the processValidators() method on each component in the view hierarchy. The processValidators() method will first initiate any data conversion that is required before validating the components value against the application’s validation rules. If there are any errors during the conversion or validation process the component is marked invalid and an error message is generated and queued in the FacesContext object. If a component is marked invalid, JSF advances directly to the render response phase, which will display the current view with the queued validation error messages. If there are no validation errors, JSF advances to the update model values phase.
Update model values
It is in the update model values phase that the properties of the managed bean are updated with the new values from the pages UI component’s to which they are bound. The JSF runtime initiates the update by calling the updateModel() method on each UIInput component in the view hierarchy.
Invoke application
During this phase any action handlers and event listeners that are bound to UI components are called. This is where any custom business logic may be invoked such as persisting or retrieving data. This is also the phase where page navigation may occur. You initiate page navigation by defining a specific outcome for a form submission and returning that outcome that is defined within a faces-config navigation mapping. Once the navigation occurs, you move to the final phase of the life-cycle.
Render response
It is in the final phase of the JSF life-cycle that displays the view with all of its components in their current, updated, state. The JSF runtime accomplishes this by calling the encode() method on each component within the component tree hierarchy. The render response phase also saves the current state of the view in the FacesContext object for subsequent view request or sever-side operations.
A note on immediate event handling
The immediate event handling attribute of a JSF component is used to handle events that normally don’t necessitate validating an entire form. A common example is found when updating a list of cities when a state is selected from a drop-down list. When the state is selected you don’t not want the entire form validated when all you want is the list of cities to be updated. This would be a good place to use immediate event handling.
Conclusion
A JSF page is represented as a tree of UI components, called a view. Upon a page request or form submission the JSF life-cycle begins. During the life-cycle, the JSF runtime must build the view while considering state information entered by a user or previously stored on the server. When the client submits a form, the JSF runtime must perform several tasks such as converting and validating the data and processing any registered events. The JSF runtime performs all of these tasks as a series of well defined steps as part of the JSF life-cycle.JSF life cycle « John Deringer: "Renders the new view as directed by your backing bean and/or navigation mapping"