Simplified JSF Request Life Cycle

This is a simplified life cycle of a JSF request initiated by the browser. A later diagram will show additional steps and additional interfaces to the web application through JSF beans.

JSF requests are initiated when the user clicks on a command button (<h:commandButton> tag) or a command link (<h:commandLink> tag). These widgets are contained in a <h:form> tag. Data that the user has entered into any input widgets within the tag is included in the request.

Simplified JSF Request Life Cycle

JSF Request Life Cycle

Decode Request Update Model Invoke Application Render Response Why is This Important?

Decode Request

This involves retrieving the previous web page if there is one (it contains the form that the user fills in) and converting and validating request data. This is described in detail in a later presentation.

Restore View

  • Construct the component tree if this is the page's first request.
  • Otherwise, retrieve the component tree, retaining form information between requests.

Apply Request Values

  • Iterate over the component tree, allowing objects to store their values.

The values are stored in temporary locations, not in application beans. Transfer to application beans happens later.

Process Validations

  • Convert form strings to submitted values (objects of any type).
  • Perform validation checks.

Note that if there are conversion or validation errors then the next step is rendering the response. Bypassing invoking the application implies that the same web page is presented again.

Validatation errors can occur for two reasons:

  • Application developers put a required="true" attribute into the tag for an input widget and the user failed to fill in text or make a selection.
  • Application developers put additional validation constraints onto the tag for an input widget and the user input failed to meet those constraints.

Update Model

  • Update JSF beans.

This is where bean setters are invoked, updating the application for its next web page. EL expressions in the web page containing the request specify the beans and properties that need to be updated.

Invoke Application

  • Navigate as indicated by the action attribute of the button or link that caused form submission.

The action attribute can be just a string that names (.xhtml suffix omitted) the next web page to be presented to the user. The action attribute can also be an action method. Then the JSF framework invokes the method, which dynamically returns the string that names the next page.

Render Response

  • Encode the response and send it to the browser.

This is where bean getters are invoked to retrieve application data to be presented in the next web page. EL expressions in the next web page specify the beans and properties that need to be retrieved.

Why is the Life Cycle Important?

You may wonder why the life cycle is important. Here is why.

The life cycle determines the order of the interaction between the JSF framework and the JSF beans, which are the interface to your application. If a framework, and the ordering of its interaction with an application, is not well-designed it is important to be aware of its flaws.

That is not a problem with JSF. The ordering is the only one that makes sense. That being the case, it is still important to know the life cycle. Knowing the life cycle then tells you what you do not have to do.

With JSF you do not have to push the data through the application except to update permanent state as in a database. Instead, you can use lazy code that pulls data from the beans only when it is needed.

This means that data computations go into getters rather than setters. When you are making program modifications in a complex program it is much easier to be aware of the changes that are needed when your mind is focused on a one value and how to compute it in a getter, rather than focused a different value and how to compute all the other values that it affects.

  • JSF pages contain hierarchies of user interface (UI) components.

  • In the login example, the parent component is a form (h:form) and the children are the name field (h:inputText), password field (h:inputSecret), and button (h:commandButton).

  • Each tag has a tag handler class. These collaborate to create a component tree data structure:

  • Each component has a renderer that produces HTML output.

  • All text that is not a JSF tag is simply passed through.

  • The JSF tags are converted to HTML by their renderers.

  • For example, the renderer for the UIInput component converts 

         <h:inputText value="#{user.name}"/>
    into 
         <input type="text" name="unique ID" value="current value"/>

    The JSF framework obtains the current value of user.name from the user bean.

  • The JSF framework generates unique IDs for HTML elements so that they can be associated with beans. This process is called encoding.

  • User fills in form fields and clicks a command button.

  • Browser sends the form data to the server as a string of ID/value pairs in a POST request.

  • IDs allow UI components to associate the data sent with appropriate beans and actions:

    • UIInput components update bean properties.
    • When clicked, a UICommand component fires an action event that can result in navigation to another screen.

  • The big picture: