Table of Contents
Previous Section
By default, WebObjects stores state on the application server. However, it also provides a mechanism for storing state in the page. This section discusses the advantages and disadvantages of each approach. Note that for a given page, you can't mix approaches, though you can use different approaches for different pages in an application.
The advantages of storing state in the application are as follows:
- Because state in the application is the default in WebObjects, you don't have to do any extra work to achieve it. All you have to do is declare session and persistent variables, and their state is automatically stored in the application.
- When you store state in the page, it's conceivable that the data could be modified by users. This isn't a problem when you store state in the application.
The disadvantages of storing state in the application are as follows:
- Scalability (limited to one application)
- You can't use round-robin to service requests for a given session since every request from that session has to go back to the same application on the same server.
- Scalability (your application can consume a lot of memory)
- When you store state in the application, your application grows with each request. Your state and thereby your application can consume a lot of memory. This isn't the case when you store state in the page.
- If your server crashes, you lose your state. This doesn't happen when you store state in the page---your server could crash and reboot, and as long as the user's browser is still running, the state is maintained in the application's pages.
The advantages to storing state in the page are as follows:
- Scalability (not limited to one application)
- When you store state in the application, every request for a given session has to go back to the same application on the same server. This isn't the case when you store state in the page---you can use a round-robin approach that performs load balancing across multiple versions of your application running on multiple servers.
- Scalability (application doesn't grow)
- When you store state in the page, your application doesn't grow with each new session and request.
- When you store state on the page, your state isn't dependent on the application. The server can crash and reboot, but as long as a user's browser is still running, the state continues to be stored in the pages of the application.
The disadvantages to state in the page are as follows:
- If your application has a lot of state, this means that a lot of data has to be passed from the user's browser to the application with every request.
- This could degrade your application's performance.
- WebObjects doesn't encrypt the data stored in a page (though you can implement your own encryption). Users could conceivably access and modify the data stored in a page, which wouldn't be a problem with state stored in the application.
- 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). If you're using frames, it's preferable to store state in the application.
- The only way to pass your state input to the application is by submitting a form.
- State in the page is stored in hidden fields. The contents of hidden fields can only be passed in a URL when you submit a form. This constrains your user interface---you have to use a button or an active image to perform an action in a page; otherwise your state information will be treated as if it doesn't exist. Note that you must use a button or active image; even if a hyperlink is placed inside of a form, clicking it won't have the effect of submitting the form.
- Need to implement archiving 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 (see the section "Storing State for Custom Objects" for more information). This isn't required for storing state in the application. This restriction only applies to custom classes---most of the Foundation classes you'll use already implement archiving and unarchiving.
- If a user restores state from an old page, it overwrites a session's current state.
- For example, suppose your application has a shopping cart object that users fill with items. A user might have put flowers in it on one page, and then put a t-shirt in it on a later page. If the user backtracks to the flower page and changes the order, the t-shirt is no longer included in the current state. This raises an interesting point---if you store state in the page, your application effectively maintains an "undo stack" of all of the previous state in your application. However, when you store state in the application, it represents just the latest snapshot of your state.
Table of Contents
Next Section