Summary

Tag name: <t:saveState>
UIComponent class: org.apache.myfaces.custom.savestate.UISaveState
Tag class: org.apache.myfaces.custom.savestate.SaveStateTag
Component type: org.apache.myfaces.SaveState
Component family: javax.faces.Parameter

Provides the ability to store a model value inside the view's component tree.

JSF provides three scopes for managed beans and therefore all the model objects that the managed beans reference: request, session, application. However a common requirement is a way for a model object to have a scope that is tied to the duration of the current view; that is longer than the request scope but shorter than session scope.

This component simply holds a reference to an arbitrary object (specified by the value property). Because this object is an ordinary component whose scope is the current view, the reference to the model automatically has that same scope.

When the value is an EL expression, then after the view is restored the recreated target object is stored at the specified location.

The object being saved must either:

• implement java.io.Serializable, or
• implement javax.faces.component.StateHolder and have a default constructor.

Note that the saved object can be "chained" from view to view in order to extend its lifetime from a single view to a sequence of views if desired. A UISaveState component with an EL expression such as "#{someBean}" will save the object state after render, and restore it on postback. If navigation occurs to some other view and that view has a UISaveState component with the same EL expression then the object will simply be saved into the new view, thus extending its lifetime.

Instructions

t:saveState enables you to persist beans and values longer than request scope, but shorter than session scope. It is ideal for persisting backing beans and values with the same scope as your view components. It does this by saving the target state with the component tree.

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.

<t:saveState id="save1" value="#{calcForm.number1}" />
<t:saveState id="save2" value="#{calcForm.number2}" />
<t:saveState 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.

<t:saveState 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.

Attributes