O'Reilly logo

JavaServer Faces by Hans Bergsten

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Saving the View State

One of the key differences between JSF and a standalone application GUI framework like Swing is how component state is handled. In a standalone application, maintaining state is not an issue, because the user interface and the application logic is all part of the same operating system process, on the same machine—as long as the application is running, state is simply kept in memory. With JSF, on the other hand, the user interface is presented to a client (a browser) that is separated from the application logic by a network, communicating through a stateless protocol (HTTP). Unless special care is taken to handle state, the application forgets all about the client and its state as soon as it has sent the response to an individual request.

There are two ways to deal with this: save the state on the server and send back a state identifier with the response that the client returns for all new requests, or send back the complete state to the client and have it return the state with each request.

The Servlet and JSP specifications provide support for the first approach—passing and identifier back and forth, keeping the state on the server—and expose it as a session scope: a collection of named values on the server representing a specific client’s state. The identifier is sent between the client and the server either in a cookie or encoded in the URLs. JSF hides all the details, but if you’re curious, I recommend my JavaServer Pages book (O’Reilly) or Jason Hunter ...

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required