Apple WebObjects 3.5 - Manual (Page 126)

Chapter 7 Managing State
126
• Backtracking. Because each page carries a record of the state existing at the
time of its creation, backtracking can make the page state and the actual
state disagree. If, for example, the user make five guesses in the
SessionStores example, backtracks two pages, and submits another guess,
the application will claim that four guesses were made, when the actual
number is six.
• Frames. Storing state in the page is a problem if the “pages” in question are
frames. Your state can quickly get out of sync. For example, suppose you
have a mail application with two frames. One of the frames shows a list of
messages with one message selected, and the other frame shows the text of
the selected message. If you delete the message in the top frame, the state
of the bottom frame isn’t updated (unless you implement your own
solution).
• Archiving. Because WOStateStorage works by archiving the objects to be
stored, only objects that can be archived using the Foundation framework’s
archiving mechanism can be stored. That is, the objects must conform to the
NSCoding protocol (or the next.util.Coding interface in Java). For scripted
objects, you don’t need to worry about this. WebScript provides a default
archiving implementation that will archive data stored in the object’s
instance variables. For compiled objects (whether Java or Objective-C), on
the other hand, you have to implement the archiving methods yourself, as
described in “Storing State for Custom Objects” (page 131).
State in Cookies
A “cookie” is another way that a web application can store state information on
the client machine. Instead of being part of the HTML page as with the state-
in-the-page mechanism, a cookie is passed as part of the HTTP header
information. Here is the syntax for the cookie header line:
Set-Cookie: NAME = VALUE ; expires= DATE ; domain= DOMAIN_NAME ;
path= PATH ; secure
The NAME=VALUE association is the only required field. It holds the cookie’s
data and the name by which it can be accessed. The other fields are optional and
set limitations on when the data will be passed from the client back to the server,
as shown in the following table:
Field Description
expires The date after which the cookie is no longer valid. Once a cookie expires, the client will no
longer return it to the server, and the client is free to delete it.