|
|
 |
|
|
Using Cookies Cookies can persist on the client's computer for a variable amount of time. When writing a cookie to the client's computer, you can set when the cookie expires. This can be in a day, a week, or even a year. Cookies allow a user's state to be maintained beyond the current visit. The section "Passing Information Through the Querystring" earlier today looked at persisting a user's name throughout all the ASP pages on your Web site. Let's examine how you can use cookies to maintain this information. Listing 11.1 created a simple form in which the user was prompted to enter his or her name. This form, when submitted, passed the user's name through the querystring to Welcome.asp, the form processing script. Because you are going to use cookies to maintain state in this example, you don't need to worry about having all the hyperlinks in Welcome.asp passing along the querystring information. All you need to do in Welcome.asp is write the name of the user to a cookie. Listing 11.4 shows Welcome.asp, modified to use cookies to maintain the user's name. Listing 11.4 - Using Cookies to Maintain State
To maintain state using cookies, you only need to write the cookie to the client's computer once: when the user enters the information that you want to persist. After the user enters his or her name into the form created by Listing 11.1, Welcome.asp, shown in Listing 11.4, is called. Line 6 starts off by reading the user's name into the variable strName. Line 9 then creates a cookie named UserName and writes to it the user's name. Line 12 sets the cookie to expire in seven days. Assuming that the user accepts cookies, the user's name will be persisted for a week. Line 17 simply print outs the personalized welcome message. Lines 20 through 23 create a series of hyperlinks. Notice that with the cookie method you don't need to bother with appending the current querystring to the hyperlinks. The output of Listing 11.4, when viewed through a browser, is no different than that of Listing 11.2. The output can be seen in Figure 11.3. You can read the user's name from any other ASP page on your site by using the Request.Cookies collection to access the UserName cookie. On each page that you wanted to display your personalized greeting, you could simply add the following ASP code:
Using the Session Object The Session is used to maintain state only for the duration of a user's visit to your Web site. When each new user comes to your site, memory on the Web server is allocated to store the Session object for that user. This memory is released if the user does not visit your Web site for a certain length of time. This time period is 10 minutes, by default but can be set to a shorter or lengthier period. We will discuss the finer details of the Session object in "The Session Object." Each variable stored in the Session object is referred to as a session variable. You can create session variables with the following syntax:
where sessionVariableName is a string. The following lines of code create a number of session variables:
Line 1 creates a session variable named Today, which stores the current date. Line 2 creates a session variable named WelcomeMessage, which contains a string. Finally, line 3 stores a numeric value in the session variable named Age. Each time you create a new variable in the Session object, that bit of memory for each unique user increases, and the new variable is stored in that memory space. These variables are persisted for each user as long as the user keeps making page requests of the Web site. Therefore, the session variables can be used to maintain state. In both the sections "Passing Information through the Querystring" and "Using Cookies," you saw an example where the user would enter his or name. The name would then be shown in a personalized greeting on each Web page. You already know how to accomplish this with cookies and the querystring method - let's examine how you would use the Session object. You only need to slightly modify the code in Listing 11.4 to use the Session object to maintain state. Listing 11.5 contains the new code for Welcome.asp. Listing 11.5 - Using the Session Object to Maintain State
To maintain state using the Session object, you need to create a session variable for each bit of information that needs to be persisted. Because you only need to save the user's name, you can use just one session variable. Listing 11.5 starts off by reading in the name the user entered in the previous form (line 6). Next, on line 9, a single session variable, named UserName, is created. This session variable is then assigned the value of strName. Lines 12 through 21 have not changed from Listing 11.4. Line 14 simply prints out a personalized welcome message, whereas lines 17 through 20 create a series of hyperlinks. Notice that when using session variables, you don't need to bother with appending the current querystring to the hyperlinks. Again, the output of Listing 11.5, when viewed through a browser, is no different from that of Listing 11.2 or Listing 11.4. The output can be seen in Figure 11.3. To obtain the user's name in any other ASP page on your Web site, all you have to do is read the value of your session variable. Session variables are read using the following syntax:
You can display your personalized greeting on any ASP page with the following code:
The Session object uniquely identifies visitors via cookies. This means that session variables will not persist across ASP pages if the user has cookies disabled. Once again, the only sure-fire way to guarantee that state will be maintained for all your visitors is to use the querystring method. However, because the vast majority of users accept cookies, most Active Server Pages developers feel comfortable using cookies or the Session object to maintain state. A more detailed discussion is dedicated to this matter later today in the section "The Session Object."
Using the Application Object Application variables are sometimes referred to as global variables because any user can access any application variable from any ASP page. It is important to keep in mind that there is only one instance of the Application object for your Web site. Every single user to your Web site has access to the exact same set of application variables. Imagine that two users visit your site and that there exists an application variable named DefaultMessage, which contains the string Welcome to my Web site!. Imagine that the first user visits an ASP page that changes the application variable DefaultMessage to Hello, there!. After this change has been made, the second user visits another ASP page that displays the application variable DefaultMessage. The second user will see Hello, there! through his browser. Because there is only one instance of the Application object and because any user on any ASP page can alter application variables, when the first user changes the value of an application variable, the results are immediately noticed by the second user. You may be wondering how the Application object can be used to maintain state. Because the Application object is global among all users, you should not try to use application variables to maintain state on a user-by-user basis. However, if you have some global piece of information that you want to save for the entire Web site, application variables are often the way to go, especially if the information changes often. We will discuss when and how to use application variables in greater detail later today in the section "The Application Object."
Choosing the Approach that Works for You Now that you've studied the four methods of persisting state, which method should you choose? Because each approach has strong points and weak points, the method to use depends largely on the situation. Table 11.1 presents all four methods of maintaining state and lists under what conditions to use what method. Table 11.1 - Approaches to Maintaining State
Now that we've examined four ways to maintain state, we are going to delve into the Session and Application objects. Both of these built-in objects are useful but often misused. Because the Session and Application objects reside on the Web server, misusing these two objects can lead to a performance hit. The next two sections, "The Session Object" and "The Application Object," discuss not only how to use these objects but also how not to use these objects.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| |||||||||
Jupitermedia Corporation has two divisions: Jupiterimages and JupiterOnlineMedia
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Whitepapers and eBooks
Webcasts
Downloads and eKits
|
