Why do you need to store state – Apple WebObjects 3.5 User Manual

Page 111

Advertising
background image

111

Most applications must be able to preserve some application state between
a user’s requests. For example, if you’re writing a catalog application, you
must keep track of the items that the user has selected before the user
actually fills out the purchasing information. By default, WebObjects stores
application state on the server. If this doesn’t meet your needs, WebObjects
provides several alternatives strategies for storing state.

This chapter describes why, when, and how to store state in a WebObjects
application. It compares all of the available state-storage strategies, shows
you how to implement your own state-storage strategy, plus it describes
how to control the amount of application state stored.

If you’re fairly new to WebObjects programming, you’ll probably just want
to read the first three sections of this chapter and skip the rest. As you begin
to write larger, more complex applications, memory demands and
performance become an issue. At that point, you should read the rest of this
chapter to learn about alternative state-storage strategies and how you can
control the amount of state stored.

Before reading this chapter, you should be familiar with concepts presented
in the chapter “WebObjects Viewed Through Its Classes.”

Why Do You Need to Store State?

Originally, the World Wide Web was designed solely for “stateless”
applications. An application could display pages and even request
information from the user, but it couldn’t keep track of a particular user
from one transaction to the next. Such an application is like a person with
no long-term memory. Each interaction begins with not so much as a
“Haven’t we met somewhere before?” and ends with an implied “Farewell
forever!” Stateless applications aren’t well-suited for online commerce
since it wouldn’t do to lose a customer’s order between the catalog and
billing pages. A remedy had to be found.

Given the ingenuity of software developers, not one but several solutions
have been advanced. They fall into two basic categories:

Storing state information on the client’s machine. With each transaction
the client passes the state information back to the server, in effect
“reminding” the server of the client’s identity and the state information
associated with that client.

Advertising