Microsoft Word - Sam's Teach Yourself MySQL in 21 Days - SAMS.doc

(singke) #1

be able to create this object. The Server object contains a few other rarely used methods and one property.
These are not relevant to what you are doing, so they won’t be discussed here.


The Request Object


The Request object is another built-in object provided by IIS. This object has a couple of often used
methods and properties. The Request object retrieves the values passed from a browser to a server in a
request. In the Guest Book example, a user submits his/her comments. These comments are passed along
with a request to the Web server. You would use the Request object to get these comments. These are
accessible via the QueryString property or the Form property. The values are stored as an associative
array or collection, which means they are stored in a name=value pair. To access the value in a Form or
QueryString, use the name that was used in the Web page to retrieve the value. In the Guest Book
example, you passed the comments to the server via a form. The comments were stored in the textarea
called Comments. To retrieve this value from the Active Server Page, you could use the QueryString
property as follows:


Request.QueryString("Comments")
The value returned would be the contents of the textarea called Comments. The QueryString
property contains all the requests passed between Web pages, regardless of their type. This means that
the information that is passed via HTML Forms or parameters in a URL (
?Last=Newton&First=Steve) will be held in the QueryString property. That is why it is the default
property. Most often, you’ll see a Request object such as the following:
Request("Comments")

instead of all spelled out
Request.QueryString("Comments")

The Response Object


The Response Object is the counterpart to the Request Object. The Response object sends data to the
client. The most often used method of this object is the Write method. This method will send output directly
to the browser. It is important to remember that because you are sending output to the browser, it must be in
a language the browser can understand—HTML. So all your output must be properly formatted HTML tags.
If it is not, it is likely that no one will ever see your output.
The next part of Listing 13.2 sets the properties of the ADO objects you created earlier. You'll get into
ADO a lot deeper later today. For now, take a look at lines 280–670 of Listing 13.2.


The first thing to notice here is that you can place VBScript within an Active Server Page anywhere.
Here, you have included some within the body of the Web page. This allows you to mix client-side and
server-side code. Things that will always remain static can be normal HTML code, while things that are
more dynamic can be created with VBScript.
Line 420, after the <% tag, resets your variable to 0. You then use a Do While...Loop block to walk
through the recordset. What happens here is that the interpreter checks to see if it is at the end of the
recordset; if it isn’t, it processes the next line of code; if it is, it ends the loop.
Inside the loop (lines 460–500) is an If...Else statement code block. Here you are alternating the
colors of the rows in the result table. This is a neat little trick that makes the results easier to view and
the users happy. You divide your counter by 2. Using the modulus function, you check to see if there is
a remainder. If there is a remainder, that means the row is odd, which you color silver. If there is no
remainder, meaning the row is even, you make it white.

The next block of code, lines 530–550, outputs the values of your recordset to the browser, keeping the
table format you started previously in the static code. It is necessary to do it this way because you do
not know how much data you have. Data is in constant flux, so there is no way of knowing how many
rows of data you have all the time. Think about the upkeep. If you had a static Web page that displayed
all your customers, you would have to insert a new row manually every time you added a new one and
delete a row every time someone went elsewhere. What a nightmare! This is one of the reasons why
merging Web pages with data is so popular.

Next, you move to the next record and the increment the counter variable (line 580). If you do not move
to the next record, the code will be stuck in an endless loop. The same contents will be displayed over
and over again. This is very frustrating for an end user, so be careful when using loops on the Web.

The final pieces of code, after the loop, perform clean up duties. You close your recordset and then the
connection. Then you end the server-side portion of the Web page and resume the static HTML again.
Free download pdf