Table of Contents Previous Section

How to Store State in the Page

By default, when you use session and persistent variables, their state is stored in the application. However, you can also choose to store state in the page. To store state in the page:

  1. In the HTML template associated with the page, add a WebObject that represents the state you want to store:
  2. <WEBOBJECT NAME="FORM">
          <WEBOBJECT NAME = "STATE"></WEBOBJECT>
          <WEBOBJECT NAME = "NAME_FIELD"></WEBOBJECT>
          <P> 
          <WEBOBJECT NAME = "SUBMIT_BUTTON"></WEBOBJECT><P>
    </WEBOBJECT>
    

    Notice that this WebObject is declared inside a form This is required since the state will be stored in a hidden field, and in HTML, hidden fields have to be inside forms.

  3. Add a corresponding declaration to the declarations file associated with the page:
    STATE: WOStateStorage{ };
    

When you run your application, your state is stored as the ASCII representation of an NSData object in the location you specified in your HTML template.

Note: If your page has multiple forms and you're storing state in the page, you should include a WOStateStorage element in each form. If you fail to do this, when you submit a form that doesn't have a WOStateStorage element in it, all of your state will be lost.

Storing State for Custom Objects

When state is stored in the page, objects are archived into an NSData object. If you have custom classes for which you need to store state, they must know how to archive and unarchive themselves. To achieve this, your custom classes must conform to the NSCoding protocol and implement its encodeWithCoder: and initWithCoder: methods. encodeWithCoder: instructs an object to encode its instance variables to the coder provided; an object can receive this method any number of times. initWithCoder: instructs an object to initialize itself from data in the coder provided; as such, it replaces any other initialization method and is only sent once per object.

Note: Most of the Foundation classes already conform to the NSCoding protocol. This section only applies to the custom classes you write yourself.

For example, the DodgeDemo ShoppingCart class in the WebObjects examples includes the following implementations for encodeWithCoder: and initWithCoder:.

- (void)encodeWithCoder:(NSCoder *)coder {
  [super encodeWithCoder:coder];
  [coder encodeObject:carID];
  [coder encodeObject:colorID];
  [coder encodeObject:colorPicture];
  [coder encodeObject:packagesIDs];
  [coder encodeObject:downPayment];
  [coder encodeObject:leaseTerm];
}
- initWithCoder:(NSCoder *)coder {
  self = [super initWithCoder:coder];
  carID = [[coder decodeObject] retain];
  colorID = [[coder decodeObject] retain];
  colorPicture = [[coder decodeObject] retain];
  packagesIDs = [[coder decodeObject] retain];
  downPayment = [[coder decodeObject] retain];
  leaseTerm = [[coder decodeObject] retain];
  car = nil;
  return self;
}

Note: If you're developing WebObjects applications on Windows NT, your code shouldn't invoke [super encodeWithCoder:coder]. This is because in the version of the Foundation Framework running on Windows NT, NSObject doesn't conform to the NSCoding protocol.

For more information on archiving, see the NSCoding, NSCoder, NSArchiver, and NSUnarchiver class specifications in the Foundation Framework Reference.

Table of Contents Next Section