1) Introduction
This article will explain the sequence of activities that will take place while processing the Request in a typical Web Application. The various phases like the Restore View Phase, Apply Request Values Phase, Process Validations Phase, Update Model Values Phase, Invoke Application Phase and Render Response Phase are covered briefly. First-time readers of JSF are requested to read the introductory article Introduction to Java Server Faces in JavaBeat.
2) Life-cycle Phases
As soon as a JSF Application in initiated by calling the Faces Servlet (which is configured in the web.xml file), series of activities will take place. These activities come under the category of JSF Request Processing Life-cycle Phases. The phases are,
- Restore View
- Apply Request Values
- Process Validations
- Update Model Values
- Invoke Application
- Render Response
The above Life-cycle Phases are not sequential. For example, the control may be re-directed to Render Response Phase from Process Validation phase in case of any Conversion or Validation Errors.
3) Restore View
A JSF View or Simple View is nothing but a collection of UI Components. For example, consider the following login form,
<f:view>
<h:form>
<p>Enter your username:
<h:inputText
value="#{LoginBean.username}"
id="usernameTextField"
required="true"/>
<h:message for="usernameTextField" />
</p>
<p>Enter your password:
<h:inputSecret
value="#{LoginBean.password}"
id="passwordTextField"
required="true"/>
<h:message for="passwordTextField" />
</p>
<h:commandButton value="Submit Values" action="loginWelcome"/>
</h:form>
</f:view>
The above form has a root UI Component called 'view'. It is having three child components namely a text-field (with identifier 'usernameTextField'), a password-field (with identifier 'passwordTextField') and a command button with name 'Submit Values'. So, this whole set-up represents a view. It is also possible to have any number of sub-views as represented by a 'sub-view' tag in a single form. The state of the view can either be stored in the Server or in the Client Browser. If it is stored in Server, then it might be cached in the HttpSession object, else it may be represented as hidden text-fields in the client end. The strategy whether the view state is stored in Server or Client is determined by the property called 'javax.faces.STATE_SAVING_METHOD'.
The default value for this property is 'server' which means that the view state is restored in the Server. The other permitted value is 'client'. This property is specified in the Configuration file (web.xml) as follows,
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
Now, let us see the activities happening in this phase. If the request is made to a URL for the first time, then a new View object is created and rendered to the Client. Else (because the view state is already found in the cache), the view is restored and displayed. In our example case, we saw three child components. Any Custom Convertors, Validators, Renderers, if attached for the UI components, will be restored in this phase.
In case, if the UI Component values are directly mapped to the property defined in a Managed Bean, then the value for the property is restored and it is associated with the View. Most of the works are handled by the ViewHandler class through its method restoreView().
|
