Java Server Faces (JSF) is a framework for simplifying web based user interface development and integration. The UI development and integration is simplified through templates and custom components. JSF leverages Standard Java Servlet (FacesServlet) and XML based templates and minimizes the use of Java to integrate the various components.
There are couple of known implementations to the JSF framework. Implementations include MyFaces and Sun RI. The standard framework itself stipulates mandatory implementation of certain components and thus all implementations are almost similar. The tutorials to follow will include examples based on standard framework components and components from Apache’s MyFaces implementation. There are many different component libraries that can be added on to the basic implementation. Component Libraries include Apache’s Trinidad, jBoss’ RichFaces, IceFaces, and Tomahawk. Different component libraries carry different set of components and you can choose a library that best suits your UI needs.
JSF Life Cycle
Although it is not always important to completely understand the JSF life cycle to successfully develop a JSF application, a fair understanding of the phases comes in handy while attempting to do application specific tasks including error handling, validation, exception handling, rendering, applying conversion, etc.
Figure 1: JSF Diagram
There are six different standard phases in the JSF lifecycle. The above diagram shows the usual order in which the six phases execute. The order may change at times, due to validation errors or other short-circuiting actions like hitting the cancel button.
The first phase of the JSF lifecycle is the Restore View phase. Whenever a button or hyperlink is clicked and a JSF page is requested, this phase gets initiated. As the phase initiates, the JavaServer Faces implementation builds the view of the page. It attaches event handlers and validators to the components available in the view and then saves the view to the instance of FacesContext. Every event handler, validator, convertor of the application’s component tag has access to the FacesContext instance. The FacesContext instance has all the information that is required to process a request.
Apply Request Values
After the view (the component tree) is restored, each and every component uses its decode method to extract its new value from the request parameters. The value that was extracted using the encode method is stored locally on the component. During this phase, errors generated due to conversion failures are queued on the FacesContext. The error messages will be displayed during the render response phase.
During this phase, if the application needs to redirect to a non-JSF resource or a different web application, it can do so by calling FacesContext.responseComplete. If there are queued up events, the JavaServer Faces implementation broadcasts the events to the interested listeners during this phase.
If any component has the immediate attribute set to true, then conversions, validations and events will be carried out during this phase.
When this phase ends, the messages and events are queued and the components have their new values.
During this phase, all the validations are carried out. Each component in the component tree is checked for attached validation, and the validation rules are checked against the values stored in the component. If a validation fails, the JSF implementation queues the error message in the FacesContext instance and directly jumps to the render response phase and the messages are displayed. During this phase, if the registered event handler or validation methods call the render response phase, the implementation jumps to the render response phase. If there are queued up events, the JavaServer Faces implementation broadcasts the events to the interested listeners . During this phase, if the application needs to redirect to a non-JSF resource or a different web application, it can do so by calling FacesContext.responseComplete.
Update Model Values
Once the component values have been validated, the JavaServer Faces implementation can go through the component tree and apply the component local values to the corresponding server side object properties. If the local component value cannot be converted to the data type specified in the server side object, the JavaServer Faces implementation jump to the render response phase directly and displays an error page. The JSF implementation will update the bean properties pointed at by the component’s value property. If renderResponse method is called by any updateModels method or listeners, the JavaServer Faces implementation directly jumps to the render response phase. During this phase, if the application needs to redirect to a non-JSF resource or a different web application, it can do so by calling FacesContext.responseComplete.If there are queued up events, the JavaServer Faces implementation broadcasts the events to the interested listeners during this phase.
The JavaServer Faces implementation handles all application-level events. Application-level events include form submits. During this phase, if the application needs to redirect to a non-JSF resource or a different web application, it can do so by calling FacesContext.responseComplete
This is the phase the response is rendered for the user. During this phase, the JavaServer Faces implementation hands over the control to the JSP container, if the application is using JSP page. If this is the first request to the page, the components will be added to the component tree as the JSP container traverses the tags. If this is not the first request to the page, the components are already available in the component tree. Once ensuring the components are in the component tree, the components will render themselves as the JSP container parses the tags in the requested page.
If the request is not the first request for the page and if errors were encountered during the apply request values phase or process validation phase or update model view phase, the original page is rendered as it is. The queued up error messages in the FacesContext instance are displayed on the screen.
If there are no errors, the content of the view is rendered and the state of the current response is saved to make it available for the next restore view phase upon request of the same page.
If the user inputs some invalid data and click submit, the tree is rebuilt during the restore view phase and the entire life cycle continues.
This is all for today’s article. Hope you liked it.