ASP Primer: Making a Request
Use these bookmarks to jump around the tutorial:
[Request.Cookies:
Getting Stuff Out of a Cookie
[The
Handy Dandy Session Variable] [Request.QuryString:
Passing Information Along] Variables? I thought we
already talked about variables? Well, we talked about
"normal" variables. Session Variables are in a league all their own.
Session Variables are also very closely tied to cookies, which is why I
waited until now to present them to you. In many ways Session Variables
have a great deal more power and flexibility than regular variables but there
are some drawbacks as well. As you already know,
variables have a limitation of only being usable on the page that they are
created on. They are local to the page. For example, if you set variable "my_cash"
equal to "$22.00" on an ASP page and then refreshed the page or moved on to
another page, the value of "my_cash" would vanish. In fact, as soon as the page
finishes sending everything to the browser, the values in all of your variables
cease to exist. That is not true of Session Variables. With a Session
Variable you can move a value from page to page. While Session Variables
hold values just like any other variable, they have very different
implementations and requirements. Here are the key differences: You don't have to
declare a Session Variable with a Dim statement. By referencing a
Session Variable you will create it if it does not already exist. Session Variables
require that the user have cookies capabilities available and turned on. Here's an example of how
to create and use a Session Variable: <% Session("my_cash") =
"$22.00" %> In the example above we
are creating a Session Variable named "my_cash" and setting it equal to
"$22.00". In this one line we have created the Session Variable and
assigned it a value. Retrieving the value is
just as straight-forward: <% Response.Write "I
have " & Session("my_cash") %> So, what happens if you
retrieve a Session Variable value before it is assigned a value? You end up actually
creating a Session Variable that has no value in it. If we used the
example from above, "my_cash" would have been created when the Response.Write
was executed. It would have no value, though, since we were simply retrieving
the value. So, why do cookies have
to be turned on? It's because cookies are
the base technology for Session Variables. You see, ASP uses temporary
cookies to store your Session Variable values. It does this by creating a
cookie with a unique name that the server makes up. Each time a Session
Variable is referenced its value is retrieved from that temporary cookie.
The cookies are temporary because they only last while the user is having an
active session. If the user has left the site or walks away from their computer
for more than 30 minutes, the session is considered over and the cookie is
removed. If the user doesn't accept cookies at all then there is no place to
store the Session Variable values, therefore, no way to maintain the
values from page to page. By the way, the session
time-out can be changed to be longer or shorter than 30 minutes. We'll get to
that little trick later in the series when we get to the object that controls
session time. So, why not use
Session Variables all of the time? Most every ASP developer
I know will tell you to avoid Session Variables when at all possible.
They may seem like the easiest solution for everything, however, they have some
definite drawbacks. They add a lot of
additional communication traffic and overhead. Each time a Session Variable
is referenced, the server has to go and retrieve the information from the
special cookie. While this may not seem like a big deal, you can imagine what a
nightmare it would be for a server to track hundreds or thousands of users, each
with unique Session Variables. It can put quite a strain on the server. So, when is a good time
to use a Session Variable? Session variables
are perfectly fine to use as long as you use them sparingly. The best example
that I can think of is when securing pages. You can use a Session Variable
to grant access to secured pages by setting a single Session Variable to
a secret access value. Then each time a new ASP page is accessed, it first
checks to see of that Session Variable's value is correct for access. If
it isn't, the user is directed to a login page. If it is, the page is displayed.
This will be our practical example in the next installment of this series.The Handy Dandy Session
Variable
