Table of Contents
Previous Section
As with most activities in a WebObjects application, state management is organized around the request-response loop. The exact steps in a cycle of the loop depend on where state is being stored---on the application server (which is the default), or in the page. WebObjects uses an NSDictionary to store state data in the application---in other words, when you store objects in the application, they're kept intact in memory. (The NSDictionary class stores data as key-value pairs; you access a value through its key.) When state is stored in the page, however, state data is copied from the application server and archived into an NSData object whose ASCII representation is then put into a hidden field in the page. (The NSData class provides an object-oriented wrapper for byte buffers.) The corresponding state data is subsequently removed from the server. For a discussion of the advantages and disadvantages of each approach, see the section "Storing State in the Application vs. Storing State in the Page." For more information on NSDictionary and NSData, see the Foundation Framework Reference.
Figure 1 illustrates the general sequence of events that occurs when an application receives a request (for example, when a user clicks a hyperlink).
The following steps describe in more detail how an application manages state when it receives a request:
A stateID is a value generated by WOApplication during request handling that's used to store and retrieve state information. A stateID is only present if the application has session or persistent variables---otherwise, the value returned is nil.
A stateID is an NSString that has the format sessionIdentifier.key.extension ---for example, 12.124563322.234. WebObjects doesn't require this format (in case you want to implement your own stateID scheme). However, it may be useful to understand why WebObjects takes this approach.
The sessionIdentifier uniquely identifies each user session. To prevent users from accessing the pages in another user's session, the stateID also includes a key field. The key is a randomly generated number; you can't access the pages in a session without the proper key. The key also ensures that if an application crashes and restarts (thereby renumbering the sessions), an existing session is not in danger of having its stateID duplicated. The extension is incremented with every transaction, which makes the URL for each transaction unique. This prevents the situation in which a user might be iterating on a single page, but the page is never refreshed since it's being cached by the browser.
The stateID method also snapshots the session and persistent variables and stores their state (whether in the application or in the page).
If so, WOApplication invokes stateDataForID:, which takes the state stored in the application, archives it into an NSData object, and returns the NSData object. The WOStateStorage element then puts an ASCII representation of this NSData object into a hidden field in the page.
State is frozen before a response is generated (it was frozen in Step 7, when the stateID method snapshotted session and persistent variable values and stored them). If you modify session or persistent variables during a response, those changes will be lost. The stored state will be used to restore state across your session the next time the application handles a request.