Scribd
Upload
159 views

Prepared By: Rajat Gupta

The six phases of the JSF application lifecycle are restore view, apply request values, process validations, update model values, invoke application, and render response; this lifecycle handles restoring existing views, processing and validating user input, updating data models, executing business logic, and generating the response. The apply request values, process validations, and update model values phases specifically work to retrieve and validate user input, convert it to the appropriate types, and update backend beans and objects.

Uploaded by

Hitesh Bhakuni
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
159 views

Prepared By: Rajat Gupta

The six phases of the JSF application lifecycle are restore view, apply request values, process validations, update model values, invoke application, and render response; this lifecycle handles restoring existing views, processing and validating user input, updating data models, executing business logic, and generating the response. The apply request values, process validations, and update model values phases specifically work to retrieve and validate user input, convert it to the appropriate types, and update backend beans and objects.

Uploaded by

Hitesh Bhakuni
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 12

Prepared By : Rajat Gupta

 The six phases of the JSF application lifecycle


are as follows :

1. Restore view
2. Apply request values; process events
3. Process validations; process events
4. Update model values; process events
5. Invoke application; process events
6. Render response
 This phase of the lifecycle presents three view instances: new view,
initial view, and postback, with each one being handled differently.

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.

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.

Postback : (the user returns to a page 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 apply request
values.
 The purpose of the apply request values phase is for each
component to retrieve its current state. The components
must first be retrieved or created from the FacesContext
object, followed by their values. Component values are
typically retrieved from the request parameters

◦ During this phase the default conversion takes place(like if any


inputText is mapped to Integer in the bean). If any conversion fails
then error message associated with the component is generated
and queued on FacesContext. This message will be displayed
during the render response phase, along with any validation errors
resulting from the process validations phase.

◦ Every input control that has an editable value also has an


immediate property. If this property is set to true, validation takes
place in this phase instead of the Process Validations phase.
◦ Action sources, like a button or a hyperlink, also have
an immediate property, and if that property is true,
they will fire action events during this phase as well.
◦ During this phase, the decoding code can also add
events or perform other operations based on the
request. Once the action event has been created, it is
added to the FacesContext for later processing in the
Invoke Application phase.
◦ After this phase is completed, any existing events are
broadcast to interested listeners.
In the Process Validations phase, JSF traverses the
component tree and asks each component to make
sure its submitted value is acceptable.
◦ Before validation can occur, the submitted value is
converted, by using the converter registered for the
component.
◦ If both conversion and validation are successful for all
components whose values were submitted, the
lifecycle continues onto the next phase. Otherwise,
control will skip to the Render Response phase,
complete with validation and conversion error
messages.
◦ Once the component’s submitted value has been
validated, its local value is set based on the converted
submitted value
◦ If the local value has changed, the component also
generates a value-change event.
◦ At this point, value-change events (and any other
events associated with this phase) are fired and
consumed by the appropriate listeners. These
listeners have the option of outputting a response
directly or jumping directly to the Render Response
phase.
 The fourth phase of the JSF application lifecycle -- update
model values -- updates the actual values of the server-
side model -- namely, by updating the properties of your
backing beans (also known as managed beans). Only bean
properties that are bound to a component's value will be
updated.
◦ Now that we are sure all of the local values of the components are
updated and valid, and of the correct type, it’s okay to deal with
any associated backing beans or model objects.
◦ Because objects are associated with components through JSF EL
expressions, this is where those expressions are evaluated, and
properties are updated based on the component’s local value.
◦ You can see that the value property is the expression
"#{helloBean.numControls}". JSF will use this to find an instance of
a bean stored under the key helloBean, searching each of the
servlet scopes—request, session, or application
◦ Once this phase has completed, the framework will broadcast any
events to all interested listeners. As always, a listener could jump
to the Render Response phase or return a response itself.
 At the fifth phase of the lifecycle -- invoke application --
the JSF controller invokes the application to handle Form
submissions. The component values will have been
converted, validated, and applied to the model objects, so
you can now use them to execute the application's
business logic.
 At this phase, you also get to specify the next logical view
for a given sequence or number of possible sequences.
You do this by defining a specific outcome for a successful
form submission and returning that outcome. For
example: on successful outcome, move the user to the
next page. For this navigation to work, you will have to
create a mapping to the successful outcome as a
navigation rule in the faces-config.xml file. Once the
navigation occurs, you move to the final phase of the
lifecycle.
 In the sixth phase of the lifecycle -- render
response -- you display the view with all of
its components in their current state.
 The secondary goal of this phase is to save
the state of the view so that it can be restored
in the Restore View phase if the user requests
it again.
 During the encoding process for each
component, converters are also invoked to
translate the component values into strings
for display

You might also like