| The BannerCo-Op - 1-1 Exchange + Cash | |
<Chapter 10: "Managing States and Events with Application and Session Objects" / ASP Book Home Page / Chapter 12: "Enhancing Interactivity with Cookies, Headers and Server Object">
|
...build a Foundation of Interactivity with Request and Response Objects. |
||||||||||||||||||||||||||||||||||||||||||||||||
|
Chapter 11Building a Foundation of Interactivity With Request and Response ObjectsThe first new business asset the World Wide Web gave us, and the single most important thing about the Web that changes traditional business models, is interactivity. There are many ways to make a Web site interactive. Forms are the most basic because they use static pages in an interactive, goal-directed manner. In Part III, "Working With Active Server Objects and Components," and Part IV, "Database Management with Active Server Pages," you learn about the other kinds of dynamic content that are not only possible now, but are actually easy to implement. You will see that this capability can be tapped at two levels: First, ActiveX controls provide dynamic content on static pages; second, Active Server Programs provide dynamic content with dynamic pages. In other words, ActiveX controls provide objects to insert on a page, whereas Active Server Pages provides objects to create pages on-the-fly. With all this power, the ASP developer can now reach the ultimate in interactivity: commercial transactions. In this chapter you lay a foundation for the next generation of basic interactivity. Even at this fundamental level, we feel strongly that with such a quantum leap in productivity and ease of use, ASP development will spawn an equally abrupt leap in the amount of "interactive variety" on the Web.
In the beginning...
The beginning of interactivity on the Web is the Common Gateway Interface (CGI). In the UNIX world, CGI remains the predominant technology of interactivity. CGI is an open architecture; it can implemented in almost innumerable ways. This open-mindedness comes with a price, however. CGI is difficult to write and maintain, especially for those unfamiliar with UNIX computing. It is processor-intensive: Each CGI call spawns another process for the server, increasing demands on processing resources. Database connectivity remains the most difficult and expensive aspect of CGI interactivity. All of these weaknesses are reasons that CGI has limited appeal to on-line business models. Arguably the most popular means of implementing CGI is the Practical Extraction and Reporting Language (Perl). For all their shortcomings, these two technologies, CGI and Perl, are modern miracles. CGI worked with stateless servers, and Perl was a powerful language designed to work with text files. They were mutually reinforcing. There was only one problem: Most Webmasters had little hope of exploiting this synergy, unless they hired a Perl programmer. We used to define a serious Webmaster as one who wasn't intimidated by the CGI/Perl alliance. To a serious Webmaster, interactivity was worth whatever cost it exacted, whether in cash to buy the Perl programs called scripts, or in the exertion necessary to learn a new programming language. This make or buy decision is really tough for most people who face the dilemma. The Web is a technology for all of us, not just the big corporations and the well-trained Information Technology staffs. How maddening it is to be within reach of the prize and yet frustrated by ignorance. Imagine, for a moment, the number of people who have had a great Web idea but who couldn't implement it. There are at least a dozen things over the last year we would like to have hosted on our Web sites. Multiply this by millions. There is a pent-up supply of creativity behind this block to dynamic interactivity. Active Server Programs will set loose this creativity. It's "scripting for the rest of us." Just imagine what the Web is going to look like when all of those ideas are implemented. It's going to be marvelous.
Before you begin to see, in detail, what this liberation force of Active Server Programming will bring, take a look at a typical (and justly famous) guestbook written in Perl by Matt Wright, a very good Perl programmer; many of us owe him much for his ubiquitous gem. By the way, Matt's source code is seven pages long! We're not going to clog up this chapter by listing it all here, but we are going to abstract key code blocks from it. If you've never done this kind of programming before, consider yourself lucky.
OK, so what does it take to make a Guestbook work using CGI, and why is it so difficult? CGI Input
So, the first step is to get information from the client to the server. The CGI/Perl technique parses the standard input from the POST method, used in the form found in guestbook.html. Standard input is UNIX-speak for the stream of data used by a program. This stream can be all of the characters entered from a keyboard up to and including the Enter keypress, or it can be the contents of a file that is redirected to a program. The Guestbook gets its stream of data from the transmission received through the POST method, used by the form in addguest.html. Recall from Chapter 4, "Introducing Active Server Pages," that in the HTTP transaction between the client and the server, something like this stream of data is called the "request body" (a term used often throughout this book). In the case here, this stream is a collection of name/value pairs for each form variable on the Guestbook (for fields left blank, the name variable has no value which is, itself, a value). Here's your first look at the CGI source code (it reads standard input into a memory buffer for the number of characters passed to the server from the client): # Get the input
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
Next, in Listing 11.1, the program splits these name/value pairs and stores them in an array (another memory buffer that stores values in a row, rather like a stack of kitchen plates). It can tell the boundary between pairs because the & character is used to encode them. Listing 11.1 GUESTBOOK.PL--An Associative Array of Form Variables and Their Values # Split the name-value pairs
@pairs = split(/&/, $buffer);
foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);
Now, each row in the array called @pairs has a string that contains the data entered in the form. Each row might also contain other special characters if the form data itself contains spaces or non-alphanumeric characters like & or %. These non-alphanumeric characters are converted to their hexadecimal ASCII equivalents. An % sign is inserted before these hex numbers to identify them as encoded characters (if the form data itself included a % sign then that character must first be converted to its ASCII value of 25. So that this value is not misinterpreted as the numeric value 25, it too must be encoded as %25). Spaces are always encoded with the plus sign.
So, when a Web client program makes a request of a Web server, the client passes everything from the type of client software making the request to the name/value pair of form variables filled in by the user on the client side of the transaction. For example, when visitors to a Web site fill in the Guestbook form completely, they send the following variables to the Web server: realname, username, url, city, state, country, and comments. Each variable has a value, and the pair is sent to the Web server in a form like this: realname=Michael+Corning. The entire string of variable/value pairs is encoded with the ampersand character like this: realname=Michael+Corning&username=mpc%40investing%2Ecom…
So, back in Listing 11.1, because each name/value pair is separated by an equal sign, the script puts everything to the left of the = in the name field and to the right of the = in the value field. Presto! A decoded query string. Next, in Listing 11.2, any special non-alphanumeric characters must be identified and converted back to their original values. Listing 11.2 GUESTBOOK.PL--Decode Non-alphanumeric Characters # Un-Webify plus signs and %-encoding
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$value =~ s/<!--(.|\n)*-->//g;
if ($allow_html != 1) {
$value =~ s/<([^>]|\n)*>//g;
}
$FORM{$name} = $value;
}
Keep in mind that all of this splitting and decoding of strings is going on behind the scenes during ASP processing. As you will see shortly, the QUERY_STRING is the same regardless of the technology driving the server. We will turn to a detailed discussion of the Request Object in the next section, but first take a look at what else is lurking in guestbook.pl. CGI Output
After the Perl script has figured out exactly what the Guestbook was saying, the program in Listing 11.3 opens the Guestbook's data file. Once open, the data file moves any contents currently in the file into another array (the Perl script is written so that new entries can be inserted or appended to existing data, according to the user's preference). The data file is then immediately closed with the close statement.
Listing 11.3 GUESTBOOK.PL--Editing of the Guestbook Entries File # Begin the Editing of the Guestbook File
open (FILE,"$guestbookreal");
@LINES=<FILE>;
close(FILE);
$SIZE=@LINES;
# Open Link File to Output
open (GUEST,">$guestbookreal");
Listing 11.4, then, writes the form data to the Guestbook data file. Listing 11.4 GUESTBOOK.PL--Writing the Entries to the Guestbook Entries File for ($i=0;$i<=$SIZE;$i++) {
$_=$LINES[$i];
if (/<!--begin-->/) {
if ($entry_order eq '1') {
print GUEST "<!--begin-->\n";
}
$FORM{'comments'} =~ s/\cM\n/<br>\n/g;
print GUEST "<b>$FORM{'comments'}</b><br>\n";
if ($FORM{'url'}) {
print GUEST "<a href=\"$FORM{'url'}\">$FORM{'realname'}</a>";
}
else {
print GUEST "$FORM{'realname'}";
}
if ( $FORM{'username'} ){
if ($linkmail eq '1') {
print GUEST " \<<a href=\"mailto:$FORM{'username'}\">";
print GUEST "$FORM{'username'}</a>\>";
}
else {
print GUEST " <$FORM{'username'}>";
}
}
print GUEST "<br>\n";
if ( $FORM{'city'} ){
print GUEST "$FORM{'city'},";
}
if ( $FORM{'state'} ){
print GUEST " $FORM{'state'}";
}
if ( $FORM{'country'} ){
print GUEST " $FORM{'country'}";
}
if ($separator eq '1') {
print GUEST " - $date\n<hr>\n";
}
else {
print GUEST " - $date<p>\n\n";
}
if ($entry_order eq '0') {
print GUEST "<!--begin-->\n";
}
}
else {
print GUEST $_;
}
}
close (GUEST);
Ninety-two lines of code! As we said previously, the other five pages of the guestbook.pl script are dedicated to sending an e-mail message to the person who just submitted an entry into the Guestbook and to displaying the contents of the entry for confirmation. Whew!
Interactive Liberation
In this section, we are going to introduce the basics of the Request and Response Server Objects. You will learn just enough about these remarkable assets to construct a simple guestbook, exactly like the one you just looked at. In Chapter 12, "Enhancing Interactivity with Cookies, Headers, and the Server Object," you will have fun with a really powerful feature of Active Server Pages: their ability to call themselves. The Request Object
In Chapter 10, "Managing States and Events with Application and Session Objects," you caught your first glimpse of the Request Object in action. There we saw how its Cookies collection was used to give the developer control over ASP sessions. In this section you explore a detailed discussion of this object. You will be going into some of the inner workings of HTTP. If that is material that you have been able to avoid up to this date, refer to the notes and sidebars we provide to fill the gaps in your understanding. The Request Object is the first intrinsic server object you need to fully understand. It is the connection between the Web client program and the Web server. Across this connection flows information from the following sources: the HTTP QueryString, form data in the HTTP Request body, HTTP Cookies, and predetermined ServerVariables. Because the Request Object accesses these collections in that order, so will we. Calls to this Server Object take the following generalized form: Request[.Collection]("variable")
As you can see, it is not necessary to specify which collection you are referring to when using the Request Object. It will search for the variable in all collections until it finds the first one, and it searches in the order given previously. If it finds no occurrence of the variable in any collection, Request returns empty. If you do specify a collection, however, you ensure two things:
The QueryString Collection The QueryString collection is the first one the Active Server searches. This is because query strings come from an HTTP GET method, and the GET method is the default request method in HTTP (makes sense because it's the original method appearing in HTTP/0.9 in 1991 the POST method didn't appear until HTTP/1.0 when HTML forms were introduced).
Query strings are the text that follows a question mark in a URL (which, by the way, is the reason they are called "query (or "question") strings"), and can be sent to a Web server two ways:
The first method is, by far, the most common way to create the query string. The second method is used by the Active Server when the client doesn't support (or has disabled) Cookies, and when you want to pass a parameter to an .asp file but don't want the trouble of a form. Session properties could also be used to pass parameters to an .asp file (see Chapter 12), but using the manual form of setting query strings takes less overhead (see note at the end of Chapter 12).
A Look Under the Hood of HTTP HTTP is a stateless protocol. This means that each request from a client requires a new connection to the server. In the strictest implementation of the protocol, this means that an HTML document with text and an image requires two separate transactions with the server: one to get the text and a second connection to retrieve the image. If the browser is capable, an HTTP connection header can be sent to the server with the keyword "Keep-Alive" so that subsequent calls by the client to the server will use the same TCP network connection. Internet Explorer 3.0 supports this header and owes much of its improvement in performance to this HTTP enhancement. In HTTP/1.0 there are three primary methods with which a Web client requests information from a Web server: GET, POST, and HEAD. We will focus here on the first two. As we said, GET is the most often used request method used on the Web. Every hypertext link uses it implicitly. When an HTML form is used, however, the HTML author decides which method to use to implement the Form element's ACTION. With forms there are issues the author needs to face in order to choose wisely. For the ASP developer, knowledge of the difference between these two methods ensures that the use of the Request Object will not yield unexpected results. For example, if you use a POST method in your form, don't expect to find the variable/value pairs to appear in the Request.QueryString collection. This collection is populated only when the form uses the GET method. The difference lies in the fact that the GET method is basically the read request of HTTP, and the POST method is the write method. That's why the GET method is still the default request method because most of the time you want to merely read the contents of an HTML file somewhere. Sometimes, however, you only want to read something special, so you include a query string along with your read request. Relying on an appended string is one of the major weaknesses of the GET method. The problem is that the URL and the query string go into an environment variable on the server. Each system administrator sets aside a fixed amount of memory for all environment variables. Many DOS programmers faced the same challenge as well. Because the environment space is limited, so is the size of the query string. There is no specific size to this limit, but there is always some size. The POST method, on the other hand, does not use a query string to communicate with the server. This frees it from the limitations of the old GET method and enables much more complex form data to be sent to a Web server. With the Post method, content is sent to the server separately from the request to read a URL. For this reason, the server variables CONTENT-TYPE and CONTENT-LENGTH are used by the POST method (and not by the GET method). Because the POST method is the write request of HTTP, we should not leave it before we note one important attribute of this method: It can write persistent data to the server. In other words, it can (theoretically at this writing) upload files. In November 1995, a Request For Comment was published by researchers at Xerox PARC. Their recommended changes to the HTML Document Type Definition (viz., the formal specification of some aspect of HTML) were simple, and the results of implementing the changes profound. It is important to remember that the POST method can write data to the server, and the GET method can't. Confused? Let's recap with Table 11.1. Table 11.1 Who's Who in the Request Object?
Every time you use a search engine you send a GET request to a server with a query string attached. For example, when you enter the following URL in your Web client http://guide-p.infoseek.com/Titles?col=WW&sv=IS&_lk=noframes&qt=HTTP+GET
you are telling the InfoSeek search engine to find all files in its database that have the words HTTP and GET. Everything after the ? is the query string and would appear in the QueryString collection of the Request Object. Note, this URL is one long string with no spaces (they've been URL encoded and will be converted back to spaces on the server).
Now that you have a better understanding of the differences and similarities of GET and POST methods, return to a focused discussion of the QueryString collection. The full specification of this method includes the way you access variables with multiple values: Request[.Collection]("variable")[(index)|.Count]
The brackets indicate optional details. You must always specify the variable in the Request collections to be retrieved, and you can optionally specify the collection name and/or information about any "data sets" that might be coming in from the client.
What is a "data set?" It is a collection of data with a common parent, and the parent, in turn, is a member of the QueryString collection. An example will make this clear. Suppose there is a form that is filled out by a financial planner. Financial planners can have many different designations, and they may want to be identified with all of them. So they fill out a membership application form giving their names and addresses. At the bottom of the form is a multi-select list box. If one particularly ambitious planner wants to add yet another acronym to his name, he must select all those designations that currently define his competence. As a result, the filled-out form is sent to the membership program on the Web server with all the usual personal identification fields along with this special field named "designations" that contains the following values: "CFP," "CPA," and "CFA." The Request.QueryString collection would have an item for each of the form variables, including one for "designations." The "designations" item would have a collection of its own (sometimes referred to as a "data set") and would return the value three with the call: Request.QueryString("designations").Count You could enumerate this data set two ways: First, by simply executing the command Request.QueryString("designations") you would see this result: "CFP, CPA, and CFA" (note it is a single comma-delimited string). Alternatively, you can walk through the data set with the following code block: <% For I = 1 to Request.QueryString("designations").Count %>
<BR><% =Request.QueryString("designations")(i) %><BR>
<% Next %>
The result is three separate text strings, one for each designation in the collection. The Form Collection As we said in the previous section, the POST method in HTTP/1.0 was designed to enable large amounts of data to be passed between client and server. In contrast, the GET method is limited to a fixed number of characters that it can append to the URI (limited by operating environment constraints on the server). This data is processed by the server as if it were STDIN data (such as data entered from a keyboard or redirected from a file). The data passed to the server with the POST method is usually formatted the same way as the GET method (viz., by URLEncoding), but it can also be formatted in a special way when necessary. There is one other subtle difference in terminology between GET and POST. With the GET method, elements of the query string are referred to as variables, and with the POST method they are parameters. This distinction serves to reinforce the simplicity of GET and the open-ended sophistication of POST. Fortunately for ASP developers, the way we handle Form and QueryString collections is virtually identical. The most important things to remember about these two collections and the methods that populate them are:
The Response Object
The Response Object is responsible for managing the interaction of the server with the client. The methods of this object include:
All but the Write method are advanced features of this powerful Response Object. In this section, you will learn the two ways this function is performed in .asp files, and you will see examples of when one method is more convenient than the other. We will also make some stylistic suggestions aimed at making your .asp files easier to read and to debug. As with our preliminary discussion of the Request Object, we introduce enough of these tools of the ASP trade to construct a simple Guestbook. In Chapter 12, "Enhancing Interactivity with Cookies, Headers, and the Server Object," we will cover the salient features of the remaining collections, methods, and properties of the Response and Request Objects. The Write Method The most fundamental process of ASP development is writing to the HTML output stream destined for the client. Everything else that .asp files may (or may not) do ultimately ends up at the Write method. Response.Write has a simple syntax. It needs only a quoted text string or a function that returns a string.
There are two ways of instructing the Active Server to output characters: explicitly with the Response.Write syntax, and implicitly with the .asp code delimiters. That is, anything appearing outside the <% (to mark the beginning of Active Server Pages source code) and %> (to mark its end) tags is implicitly written by the Active Server to the HTML file returned to the client.
In the extreme, you could write all your .asp files using Response.Write to send all HTML commands to the client. All the other characters in your .asp file, then, would be .asp source code, and every line would be wrapped in the <%…%> marker. Alternatively, all the HTML source code in your .asp file could be written as if it were merely an HTML file, and you would cordon off the ASP commands with judicious use of the <%…%> delimiters. Good programmers are far too lazy to use this method, but Listing 11.5 works: Listing 11.5 A Method for PeoplE who Like to Type <% and %. <%Response.Write("<!-- Created with HomeSite v2.0 Final Beta -->")%> <%Response.Write("<!DOCTYPE HTML PUBLIC " & CHR(34) & "-//W3C//DTD HTML 3.2//EN"& CHR(34) & ">")%> <%Response.Write("<HTML>")%> <%Response.Write("<HEAD>")%> <%Response.Write("<TITLE>Registration Results</TITLE>")%> <%Response.Write("</HEAD>")%> <%Response.Write("<BODY>")%> <%Response.Write("<FONT SIZE=+3>Thanks for writing! </FONT><P>")%> <%Set objConn = Server.CreateObject("ADODB.Connection")%> <%objConn.Open("guestbook")%> <%Set objRst = Server.CreateObject("ADODB.Recordset")%> <%Set objRst.ActiveConnection=objConn%> <%objRst.LockType = 3%> <%objRst.Source = "tblGuestbook"%> <%objRst.CursorType = 3%> <%objRst.Open%> Choosing which syntax to use should be guided by the rules of syntax in the English language and the rules of good government: less is better. Use punctuation only when it is absolutely necessary or when it improves clarity; write the fewest laws possible to ensure order and civility. In ASP development use the fewest delimiters possible. There are two reasons for this: laziness and program maintenance. Clearly, <% %> has fewer (though awkward) keystrokes, so it serves the laziness inherent in all good programmers; and fewer odd characters makes for more lucid logic (unnecessary delimiters are distracting to the human eye and virtually transparent to the server's eye). Lucid logic is easier to maintain (thereby further serving the programmer's natural laziness do I belabor the point?). There is one other reason for choosing implicit Write over the explicit, but we will have to wait a moment to see why. Listing 11.6 is easier to type and easier to read: Listing 11.6 GUESTBOOK.ASP--Opening the Guestbook Database <!--#INCLUDE VIRTUAL="/ASPSAMP/SAMPLES/ADOVBS.INC" <!-- This document was created with HomeSite v2.0 Final Beta --> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <TITLE>Registration Results</TITLE> </HEAD> <BODY> <FONT SIZE="+3">Thank you for registering!</FONT><P> <% Set objConn = Server.CreateObject("ADODB.Connection") objConn.Open("guestbook") Set objRst = Server.CreateObject("ADODB.Recordset") Set objRst.ActiveConnection=objConn objRst.LockType = adLockOptimistic objRst.Source = "tblGuestbook" objRst.CursorType = adOpenKeyset objRst.Open %>
If most of your .asp file is .asp source code (e.g., it has lots of ADO programming in it as the following Guestbook does), then you will use Response.Write only when you need to include HTML source code and it is not convenient to insert the end of .asp source tag, %>. This is awkward to describe, but easy to see, so take a careful look at the ASP version of the Guestbook that follows. Note: There isn't a single use of Response.Write in it.
Guestbook Made Easy
Now that you understand the basic operation and tradeoffs for using the Request Object and its QueryString and Form collections, take a look at how ASP can radically reduce the work required to deliver even the most basic kind of interactivity on the Web. Standard HTML
Using ActiveX and exploiting the power of ADO (which we will dive into with gusto in Part IV, "Database Management with Active Server Pages"), our Active Server Program uses 33 lines of code instead of 92, and it gives us the feedback form to boot! And we don't know about you, but we can actually read the Active Server Program. The first part of the .asp file, given in Listing 11.7, is simple HTML.
Listing 11.7 GUESTBOOK.ASP--The Header of the Guestbook Feedback Form <!--#INCLUDE VIRTUAL="/ASPSAMP/SAMPLES/ADOVBS.INC" <!-- This document was created with HomeSite v2.0 --> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <TITLE>Registration Results</TITLE> </HEAD> <BODY> <FONT SIZE="+3">Thank you for registering!</FONT><P>
ASP code
At this point we start writing .asp code. In the first block, Listing 11.8, we are making a connection with a database and a table. We need access to the table that permits us to append a new record and edit the contents of that record with the values passed to guestbook.asp from guestbook.html. We instruct the Active Server to open this table with a keyset cursor, using optimistic record locking, and we instruct it to complete the update of Guestbook entries with Listing 11.9.
<% Set objConn = Server.CreateObject("ADODB.Connection") objConn.Open("guestbook") Set objRst = Server.CreateObject("ADODB.Recordset") Set objRst.ActiveConnection=objConn objRst.LockType = adLockOptimistic objRst.Source = "tblGuestbook" objRst.CursorType = adOpenKeyset ' Alternatively you could move the values from the previous four ' lines of code onto the next line as properties of the Open method. objRst.Open
Listing 11.9 GUESTBOOK.ASP--Adding a New Entry objRst.AddNew objRst("realname") = Request.Form("realname") objRst("username") = Request.Form("username") objRst("url") = Request.Form("url") objRst("city") = Request.Form("city") objRst("state") = Request.Form("state") objRst("country") = Request.Form("country") objRst("comments") = Request.Form("comments") objRst.Update %>
Note the ending %> tag. If you think about these tags as if they were, themselves, programming logic (e.g., similar to the If...Then...Else construct), then you can see that to forget the %> would be like forgetting the End If in a regular code block. You're certainly welcome to surround all ASP commands with <%...%>, but why bother? Back to HTML
Having updated the underlying table with the new Guestbook entry, we continue writing the HTML file to the client. If we add another dozen lines to this program we can also redisplay the contents of the form and include a button that permits reentry. Alternatively, we could rename the guestbook.htm file into guestbook.asp and have it call itself changing the original "Submit" button to an "Update" button. We'll show you how to do this in the next Chapter 12, "Enhancing Interactivity with Cookies, Headers, and the Server Object." Listing 11.10 GUESTBOOK.ASP--Finishing Touches <HR> <A HREF="guestbook.html">Return to Guestbook</A> </BODY> </HTML> That's all there is to it. Remember our story at the beginning of this chapter? Well, if ASP was around back then, we would have been able to say to our boss, "Sure, boss; that's a slam dunk. We'll have a Guestbook for you before lunch." More Power To You
We have just skimmed over the power and features of the Request and Response Server Objects, just enough to be able to construct a simple Guestbook. There's much more available to the Active Server Program developer, however. As you continue reading this book, please keep in mind one very important idea somewhere near the front of your mind: Active Server Programming is going to enable those of us who are not professional programmers to do things not even they have been able to do before. We are going to see an explosion of creativity the depth and breadth of which will surprise everyone. Everyone but you. You're leading the way. From Here...In this chapter, we have built a new programming foundation for interactivity. You have seen what it used to take to get a simple Guestbook implemented on our Web sites, and you have tried your hand at doing it the ASP way. It really is amazing how much work we can get done with two ASP objects like Request and Response, isn't it? We turn our attention next to a discussion of the rest of the features of the Request and Response Objects, and we will introduce the Server Object.
© 1997, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company. Back |
<Chapter 10: "Managing States and Events with Application and Session Objects" / ASP Book Home Page / Chapter 12: "Enhancing Interactivity with Cookies, Headers and Server Object">
Last update: 30.10.99. Created by Konstantin Chapkanov.
