JavaServer Faces

Using Client-Side State Saving During Development

A JSF-specific suggestion is to use client-side state saving during development; in other words, include this declaration in the web.xml file:

<faces-config>
  ...
  <context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>client</param-value>
  </context-param>
  ...
</faces-config>

The first time JSF processes a JSP page with JSF component actions, it creates the components and configures them based on the action element attributes’ values. It then saves the whole component tree, either on the server or in the response sent back to the client. When the next request for the same view arrives, JSF restores the saved component tree and does not reconfigure it based on action element attributes in the JSP page. This means that if you change an attribute value in the JSP page, or add or remove an attribute, the changes are ignored as long as the saved state is available.

If you use server-side state saving, one way to get rid of the view state is to kill the session, but this method is not guaranteed to work in all JSF implementations because the specification doesn’t say where on the server the state must be saved. While most implementations probably save the state in the session, there are other implementation options.

When you use client-side state saving, the state is always part of the response (typically encoded in hidden form fields in the response) so it can be sent back with the next POST request. But a GET ...