The life cycle of a JavaServer Faces page is similar to that
of a JSP page. The life cycle of a JSF web application starts when user makes a
request.
When the client submits a page, the JavaServer Faces
implementation must perform several tasks, such as validating the data input of
components in the view and converting input data to types specified on the
server side. So the series of steps that an application follows is called the life
cycle.
A JavaServer Faces application supports two kinds of responses
and two kinds of requests.
Faces response: A servlet response is one that is created by
the execution of the Render Response Phase of the request processing life
cycle.
Non-Faces response: A servlet response is not created by the
execution of the render response phase. An example is a JSP page that does not
incorporate JavaServer Faces components.
Faces request: A servlet request is sent from a previously
generated Faces response. An example is a form submission from a JavaServer
Faces user interface component, where the request URI identifies the JavaServer
Faces component tree to use for processing the request.
Non-Faces request: A servlet request is sent to an
application component, such as a servlet or JSP page, rather than directed to a
JavaServer Faces component tree.
Figure 1: JavaServer Faces request-response life
cycle
The JSF application has six steps in its life cycle.
1.
Restore View Phase
2.
Apply Request Value Phase
3.
Process Validations Phase
4.
Update Model Value Phase
5.
Invoke Application Phase
6.
Render Response Phase
1. Restore View Phase
RestoreView is the first phase in the JSF lifecycle. This
phase is used for constructing view to display in the front end. Every view has
its own view ID and it is stored in the FacesContext's session object. JSF View
is a collection of components associated with its current state. There are two types
of state saving mechanism.
·
Server
·
Client
The default value is server. If you specify state saving
method as the server, the state of each component will be stored in the server.
If it is client, it will be stored in the client side as hidden variables. This
value is configured in web.xml as follows.
Listing 1
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
In this phase a request comes through the FacesServlet
controller. The controller examines the request and extracts the view ID, which
is determined by the name of the JSP page.
The JSF framework controller uses the view ID to look up the
components for the current view. If the view does not already exist, the JSF
controller creates it. If the view already exists, the JSF controller uses it.
The view contains all the GUI components.
This phase of the lifecycle presents three view instances:
new view, initial view, and postback, with each one being handled differently.
In the case of a new view, JSF builds the view of the Faces page and wires the
event handlers and validators to the components. The view is saved in a
FacesContext object.
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.
In the case of an initial view (the first time a page is
loaded), JSF creates an empty view. The empty view will be populated as the
user causes events to occur. From an initial view, JSF advances directly to the
render response phase.
In the case of a postback (the user returns to a page he or she
has previously accessed), the view corresponding to the page already exists, so
it needs only to be restored. In this case, JSF uses the existing view's state
information to reconstruct its state. The next phase after a postback is the apply
request values.
2. Apply Request Value Phase
The purpose of this phase is for each component to retrieve
its current state. After the restoring of component tree in the previous phase
each component in the tree retrieves its new value and stores it locally.
Component values are typically retrieved from the request parameters. If
immediate attribute of a component is set to true, then the validation,
conversion, and events associated with the component is processed in this
phase.
If a component's immediate event handling property is not
set to true, the values are converted. Suppose field is bound to be an Integer
property, the value is converted to an Integer. An error message associated
with the component is generated if this conversion fails, and queued in the
FacesContext. This message will be displayed during the render response phase,
along with any validation errors resulting from next process validation phase.
At the end of this phase, the components are set to their
new values, and messages and events have been queued.
3. Process Validations Phase
The first event handling of the lifecycle takes place after
the apply request values phase. At this stage, each component will have its
values validated against the application's validation rules. The validation
rules can be pre-defined (shipped with JSF) or defined by the developer. Values
entered by the user are compared to the validation rules. If an entered value
is invalid, an error message is added to FacesContext, and the component is
marked invalid. If a component is marked invalid, JSF advances to the render
response phase, which will display the current view with the validation error
messages. If there are no validation errors, JSF advances to the update model
values phase.
4. Update Model Value Phase
After confirming that data is valid in the previous phase,
local values of components can be set to corresponding server side object properties-
backing beans. So bean properties will be updated. If the local data cannot be
converted to the types specified by the bean properties, the life cycle
proceeds directly to the render response phase and errors are displayed.
5. Invoke Application Phase
During this phase, the action method of any command button
or link that was activated is called. In addition, any events that were
generated during previous phases and that have not yet been handled are passed
to the web application so that it can complete any other processing of the
request that is required.
6. Render Response Phase
The response UI components are rendered, and the response is
sent to the client. The state of the UI components is saved so that the
component tree can be restored when the client sends another request. For a
JSF-enabled application, the thread of execution for a request/response cycle
can flow through each phase, in the order listed here and as shown in Figure
below. However, depending on the request and what happens during the processing
and response, not every request will flow through all six phases.
In Figure 1, there are a number of optional paths through
the life cycle. For example, if errors occur during any of the phases, the flow
of execution transfers immediately to the Render Response phase, skipping any
remaining phases. One way this might occur is if input data is incorrect or
invalid. If data fails validation in either the Apply Request Values or Process
Validations phase, information about the error is saved and processing proceeds
directly to the Render Response phase. Also, if at any point in the life cycle
the request processing is complete and a non-JSF response is to be sent to the
client, the flow of execution can exit the life cycle without completing further
phases.
Let us start with an example to display "Hello World."
The code is given below.
Listing 2
<%@page contentType="text/html"%>
<%@page pageEncoding="UTF-8"%>
<%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>JSP Page</title>
</head>
<body>
<f:view>
<h1><h:outputText value="Hello World" /></h1>
</f:view>
</body>
</html>
In order to use Java Server Faces Components in JSP pages,
we need to have access to the two tag library, the HTML component tag library
and the core tag library using html and core tag lib. We will discuss each one
with the features in coming sections. The code above has "f:view" as the
Core Tag which represents the root of view and all JSF component tags must be
inside view tag and "h:outputText" is the HTML Tag which represents
the Label.
Output
The following output will get printed on the screen.
Hello World
