Topics covered are 1> 2> 3> 4> 5> JSF Lifecycle Managed Beans Converters and Validators

Navigation Rules Event Handling JSF Lifecycle

6> We have FacesServlet as the main controller in JSF. There are 6 phases through which a jsf request goes through normally. 1> Restore view this phase is responsible for restoring the component hierarchy from the previous request and associating it with the FacesContext. FacesContext is something similar to ServletContext. UIViewRoot is the root node in the component hierarchy and is created in this

phase and added to the FacesContext. The phase checks if this page has been requested earlier or this is a new request

This is Restore View phase during initial request During the first request for the view, viewHandler.requestView() returns null as there is no view to be restored. When null value is returned, phases 2 to 5 are bypassed and FacesContext.renderResponse() is called by Restore view phase. Then Restore view phase invokes ViewHandler.createView() to create component hierarchy root UIViewRoot and it is added to the FacesContext. 2> Apply request values values from the current request are applied to the components in the hierarchy i.e. each component updates its state.

Command components queue up events in the event queue to be delivered in the invoke application phase. After Apply Request Values phase is completed, the request scope becomes empty as each component has new values. 3> Process validations in this phase the validators and the converters are processed associated with the components. This is to make sure that correct values are sent to the model. Values have to be in the correct form as well. That is why we have the converters.

Conversion of values submitted happens first and the converted value is validated.

processValidators() method is invoked on UIViewRoot which in turn invokes processValidators() on each individual component in the tree. If a conversion or validation error occurs, a JSF message is added to the FacesContext along with the clientid of the component and the renderResponse() is invoked to indicate that the lifecycle should directly skip to the Render Response phase after this phase is completed. 4> Update model values model is updated with the converted and validated values and the local values in the components are cleared.

processUpdates() is invoked on the UIViewRoot which in turn invokes processUpdates() on each component. Where should the new value be stored in the model? For this, the value binding is used to determine which property of the managed bean should be updated with the available value. Once the model is updated, the component value is cleared. The model may have implemented some validations and if those fail, again a message is added to the FacesContext along with the components clientId and response is rendered to the user. renderResponse() is invoked to indicate that after the Update Model Values phase is completed, invoke the Render Response phase. 5> Invoke application action events are processed. Queued events from the previous phases are processed. 6> Render response render the response to the client and maintain the new component tree structure which will handle the next incoming request from the user.

Jsf tags on a page when processed create a component tree. Component tree contains java objects corresponding to the ui elements on the jsf page.
<h:inputText value="#{user.name}"/> this tag will produce html output through an associated renderer. <input type=text value=associated value/> this process of converting jsf tags into html code is called encoding.

one important thing to note is the id of the components. In jsf, a components id is always prefixed by the form name

<input type=text id=form_id:txtbox1/> Managed Beans it has to be a javabean i.e. a class having default constructor, which has private properties and getter/setter methods to access them. They can have other methods as well. <faces-config>
<managed-bean> <managed-bean-name>user</managed-bean-name> <managed-bean-class>com.xyz.UserBean</managed-bean-class> <managed-bean-scope>session</managed-bean-scope> </managed-bean> </faces-config> <managed-bean> <managed-bean-name>user</managed-bean-name> <managed-bean-class>com.xyz.UserBean</managed-bean-class> <managed-bean-scope>session</managed-bean-scope> <managed-property> <property-name>name</property-name> <value>me</value> </managed-property> <managed-property> <property-name>password</property-name> <value>secret</value> </managed-property>

</managed-bean>
when the bean instance is created, name and password would have values set. 3. Navigation - <h:commandButton label="Login" action="login"/> <navigation-rule> <from-view-id>/index.jsp</from-view-id> <navigation-case> <from-outcome>login</from-outcome> <to-view-id>/welcome.jsp</to-view-id> </navigation-case>

</navigation-rule> view id strings must start with a /. dynamic navigation <h:commandButton label="Login" action="#{loginController.verifyUser}"/>
String verifyUser() { if (...) return "success"; else return "failure"; }