[Myfaces Wiki] Update of "SaveState" by WernerPunz

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for change notification.

The following page has been changed by WernerPunz:
http://wiki.apache.org/myfaces/SaveState

New page:
= UISaveState =
== Description ==

Traditional JSP Applications save their state information within HttpSession objects. This is an easy to use but not always satisfying approach:

    * HttpSession objects must have an expiration date (timeout) that prevents the server from running out of memory over the time. The always boring question for web admins: How long should I set the session timout?
    * Server restarting is a thrilling task: Will all objects in active sessions be serialized and restored successfully? If business classes have changed in the meantime, this task is likely to fail.
    * Running multiple redundant servers is a challenge. You must use cluster environments which are expensive and difficult to handle.

MyFaces supports a different approach. It makes it possible to write sophisticated applications without any use of the HttpSession. All state information of the current view and the model beans can be encoded to the client response. MyFaces introduces a new Component "UISaveState" with the corresponding Tag <x:save_state>.
Example (see "sample1.jsp" of the "examples" web application):

{{{
<x:save_state id="save1" value="#{calcForm.number1}" />
<x:save_state id="save2" value="#{calcForm.number2}" />
<x:save_state id="save3" value="#{ucaseForm.text}" />
}}}            

The current values of the three properties number1, number2 and text are automatically saved within the client response and get restored at the next client request.

You can also save the whole bean.
Example:

<x:save_state id="saveCalcForm" value="#{calcForm}"/>
            

The whole bean automatically is saved and restored by MyFaces. To be able to save and restore the value of a bean property or the bean itself, it must implement the Serializable interface.

== Scoping and Traversing with x:saveState ==

By using savestate you can ease object passing and traversing between pages. Thus enabling scopes on the frontend side of things
which are smaller than session and longer than request, without having to put an extra burden on the session object.

Usage:
you simple set a 

{{{
<x:save_state id="save1" value="#{scopebean}" />
}}}

on page 1

then you do something which pushes you to page2

{{{
<x:save_state id="save1" value="#{scopebean}" />
}}}

on page 2 should restore the entered data from page1 at the beginning of the phase cycles.
thus once you reference scopebean on page2 you will get the values from page1.
You can do this for as many pages as you want. The scopebean is dropped from the cycle
the moment the user runs into a page without a save_state statement.

=== Advantages over the classical session approach === 

It is safer, because you do not have to explicetly drop the objects. And you do not put extra burden on the session.

=== Disadvantages ===

Every object dropped into the savestate component has to be serializable, thus you put extra burden onto the server,
onto the servers disk and you might get a small performance hit compared to the session approach.