Addressing the Web s Statelessness
Addressing the Web's StatelessnessThe basic building blocks of the WebTCP/IP, HTTP, and HTMLdon't directly address any notion of a "session" on the Web. Users don't log in to the Web, nor do they ever log out. So without some additional work, each page visit stands alone, in its own context. Content is requested by the browser, the server responds, and that's the end of it. No connection is maintained, and the server isn't notified when the user leaves the site altogether. Out of the box, HTTP and HTML don't even provide a way to know who the users are or where they are. As a user moves from page to page in your siteperhaps interacting with things along the waythere's no way to track their progress or choices along the way. As far as each page request is concerned, there's only the current moment, with no future and no past. The Web is thus said to be "stateless" because it doesn't provide any built-in infrastructure to track the state (or status or condition) of what a user is doing. What does the Web's statelessness mean to you as a Web developer? It means that without some type of server-side mechanism to simulate the notion of a session, you would have no way to remember that a user has put something into a shopping cart, say, or to remember the fact that the user has logged in to your site. The Web itself provides no short-term memory for remembering the contents of shopping carts and other types of choices users make during a visit. You need something to provide that short-term memory for you. That's exactly what you will learn about in this chapter. The Problem of Maintaining StateThe fact that HTTP and HTML are stateless is no accident. A main reason the Web is so wildly popular is the fact that it is so simple. It probably wouldn't have gotten so big so fast if a whole infrastructure needed to be in place for logging in and out of each Web server, or if it assumed that you needed to maintain a constant connection to a server to keep your current session open. The simplicity of the sessionless approach also enables the tremendous scalability that benefits Web applications and the Web as a whole. It's what makes Web applications so thin and lightweight and what allows Web servers to serve so many people simultaneously. So the Web's statelessness is by design, and most people should be glad that it is. Except for us Web developers. Our lives would probably be a lot easier if some kind of universal user ID existed, issued by, um, the United Nations or something. That couldn't be faked. And that could identify who the user was, no matter what computer they were sitting at. Until that happens, we need another way to track a user's movements as they move through our own little pieces of the Web. Solutions Provided by ColdFusionExpanding on the Web application frameworkwhich already sets aside part of the server's brain to deal with each applicationColdFusion provides three types of variables that help you maintain the state of a user's visit from page to page and between visits. Similar to application variables (which you learned about in the last chapter), all three of these are persistent variables because they stay alive between page requests. However, they are different from application variables because they are maintained separately for each browser that visits your site. It's almost as if ColdFusion had a tiny little part of its memory set aside for each visitor. CookiesCookies are a simple mechanism for asking a browser to remember something, such as a user's favorite color or perhaps some type of ID number. The information is stored in the client machine's memory (or on one of its drives). You can store only a small amount of information using cookies, and users generally have a way to turn off cookies in their browsers' settings. Cookies have gotten a lot of bad press in the past few years, so many users turn them off at the browser level. NOTE Cookies aren't a ColdFusion feature per se, but a browser/Web server feature. ColdFusion just makes it easy to work with them. Client VariablesClient variables are like cookies, except that the information is stored on the server, rather than on the client machine. The values are physically stored in the server's Windows Registry or in a database. Client variables are designed to hold semi-permanent data, such as preferences that should live for weeks or months between a user's visits. Session VariablesSimilar to client variables, session variables are stored on the server. However, instead of being stored physically, they are simply maintained in the server's RAM. Session variables are designed to hold temporary data, such as items in a shopping cart or steps in some type of wizard-style data-entry mechanism that takes the user several pages to complete. Choosing Which Type of Variables to UseWith three types of per-visitor variables from which to choose, developers sometimes have a hard time figuring the best type to use for a particular task. We recommend that you look through this whole chapter before you start using any of them in your own application. However, in the future, you might want to refresh your memory about which type to use. Table 20.1 lists the major pros and cons of cookies, client variables, and session variables.
|
EAN: N/A
Pages: 282