Table of Contents Previous Section

Summary

Why Do I Need to Store State?

You need to store state because pages aren't persistent in a WebObjects application. Variables that aren't session or persistent only live for the duration of a transaction, which is defined as a client request coming in and a response page going out.

What Are My Options for Storing State?

You can:

What Are the Basic Differences Between Storing State in the Application and Storing State in the Page?

When you store state in the application, objects are stored intact in memory. When you store state in the page, objects are archived into an NSData object, and the ASCII representation of the NSData object is put in the dynamically generated HTML page.

What Do I Need to Do to Store State?

You need to declare variables for which you want to store state as either session variables (in the application script) or as persistent variables (in a component script).

When you store state in the application, you don't have to do any extra work beyond declaring variables as session or persistent. When you store state in the page, you have to put a WOStateStorage element inside of a form in your page's HTML template. Also, all of the objects for which you're storing state in the page must be able to archive and unarchive themselves---this isn't a requirement for state in the application.

Can I Mix Approaches?

You can use different approaches (state in the application or state in the page) for different pages in your application. However, you can't mix approaches on a single page.