|Developer's Daily||Perl Education|
|front page | java | perl | unix | dev directory | web log|
If you're trying to create any type of interactive web site -- such as an e-commerce shopping site -- you'll quickly run into a problem known as state maintenance. In short, this means that when a user moves from one page to another on your web site, you need to know what they've already purchased or viewed -- but you can't -- unless you manually maintain some type of state information as the user moves around.
In this article, we'll discuss how you can maintain state information
in your Perl/CGI programs by using "cookies" in your CGI programs.
Cookies are one way -- maybe the best way -- of maintaining state information
as a user moves around your web site.
The problem of state maintenance
As you may know, HTTP is a stateless communications protocol. This means that when a user moves from one page to another on your web site, no information is passed between the pages. Well, if you can't pass information from one page to the next as a user moves through your web site, how will you ever know what they're trying to buy?
The answer is "you can't", unless you implement some means of state
maintenance, i.e., the art of maintaining information as a user moves from
one page to another on your web site.
State maintenance options
Currently, there are several ways of maintaining state information. These methods are:
What's a cookie?
In web lingo, the term "cookie" or "cookies" refers to information that you can store on a client's computer for later retrieval. Yes, that 's right, cookies let you write information to the disk drives of your visitor's computer. (As you'll see however, the amount of information you can write is limited.)
Basically, you store information on a visitor's computer in the form of "name=value" pairs. For instance, you can save information like this on your visitor's computer:
Cookies also let you set other information. In your programs you can set and retrieve the following information for each cookie:
While it's very easy to set more than one cookie on a visitor's computer,
in the real world it seems that most web sites store only one or two cookies
Drawbacks of cookies
Before, diving right in, there are several potential pitfalls when using cookies that you need to be aware of:
When cookies were first designed by Netscape, many users were very reluctant
to allow web sites to store information on their hard drives. Now, several
years later, this technique is used by many sites and user's fears seem
to have subsided.
Other cookie restrictions
If writing information to the hard disk drives of your visitor's sounds interesting, consider the following restrictions:
As a final note, cookies can only be viewed from web servers in the
domain from which they were defined. This is a security precaution that
keeps one domain from seeing cookie information from other domains. This
means that you cannot see cookie information from yahoo.com or
aol.com, and they cannot see your information.
(a) A shopping cart application
Now, once the cookie is set when the user first enters your shopping
cart area, you can implement one of two possible approaches:
Because of the size limitations on cookies, most sites seems to use the first option. If you take this approach, all you need to do throughout the remainder of your application is retrieve the SHOPPER_ID, and use it to retrieve data in your shopping cart application. There's usually no need to re-set the cookie later in your application.
(b) A customized web site area
These are just two characteristics they can customize. Suppose the site is a real high-powered information site where the user can also set the font type, font size, the up-to-the-minute stock market information that should appear (i.e., display stock prices for Sun, Microsoft, and Yahoo), what news items should appear (sports, weather), etc. As you can imagine, this can lead to a very large number of customizable variables.
If I had a small web site, I might be tempted to set a simple cookie
or maybe store the same information in two separate cookies like this:
But, if the site was going to become very large at all, I would probably
just set a user id variable like this:
and then maintain all of the user preferences in a database. Otherwise the cookie may get too large or you may start saving a large number of individual cookies. (Please note that this is just my opinion; I suggest doing whatever you think is best in your application.)
To be continued ...
Well, that's probably a lot of information to consider, so we'll pause here for a short break.
We'll follow this article very shortly with some working Perl/CGI code
that you can use in your own programs. In Part 2, we'll show you (a) how
to set and (b) how to retrieve cookie information in your
Perl programs. We'll use the CGI.pm Perl module for all of this,
because, hey, it's the easiest way.