Active Server Pages Objects
ASP hosts a number of built-in objects that are available to the developer. These objects help manage everything from variables to form submission. The objects are simple to use and can be called directly from code without any special syntax. In this section, we examine the ASP objects available in Visual InterDev for the Internet developer. Properties and methods supported by these objects are described in Appendix D.
Application Object
The Application object allows you to create application variables, variables that are available to all users of an application. All users who request Web pages from the same virtual directory can share any application variables defined in those pages.
Listing 5-3 shows a code sample that uses the Application object. In this example, an application variable is used to track the last time the page was visited.
Listing 5-3. The Application object.
<%@ LANGUAGE="VBSCRIPT"%> <HTML> <HEAD> <TITLE>Application Variables</TITLE> </HEAD> <BODY BGCOLOR="FFFFFF"> This page was last visited on <%=Application("Time")%> <%Application.Lock%> <%Application("Time") = Now%> <%Application.Unlock%> </BODY> </HTML> Creating an application variable is a simple matter of addressing the Application object with the name of the new variable you want to create. For example, the following code produces an application variable named Company and sets its value to NewTech:
Application("Company") = "NewTech" The name is arbitrary, and the variable can contain any kind of information, whether numbers or text.
Because the variable is available to a number of users simultaneously, you must deal with concurrency; that is, you cannot guarantee that two users will not try to set the variable to different values at the same time. To deal with this situation, the Application object supports Lock and Unlock methods. The Lock method locks the entire Application object, not just the variable you are changing, so always unlock the Application object immediately after changing a variable value:
Application.Lock Application("Company") = "NewTech" Application.Unlock Although application variables are useful for temporary storage of data, they can't be used to store data permanently. The data in an application variable is destroyed when the Application_OnEnd event fires. Be sure to move application variables to permanent storage, such as a database, if you want to save the values after the application terminates.
Session Object
In programming applications, developers are often less concerned about data shared by many users and more concerned about data related to an individual user. ASP supports variables for individual users through the Session object, which allows you to create session variables for use by individuals.
Listing 5-4 shows how to define some session variables in the GLOBAL.ASA file. Defining session variables is just as simple as defining application variables. All you have to do is address the Session object with the name of the variable you want to define. The big difference between application and session variables is the scope. Session variables are reserved for just one user and last as long as the user continues the session. Once the user stops requesting pages from a given virtual directory for 20 minutes, the data is gone.
Listing 5-4. Creating session variables.
<SCRIPT LANGUAGE="VBScript" RUNAT="Server"> ' You can add special event handlers in this file, which ' will be run automatically when special Active Server ' Pages events occur. To create these handlers, add ' a subroutine with a name from the list below that ' corresponds to the event you want to use. For example, ' to create an event handler for Session_OnStart, you would ' put the following code into this file (without the ' comments): ' ' Sub Session_OnStart ' **Put your code here ** ' End Sub ' EventName Description ' Session_OnStart Runs the first time a ' user runs any page in ' your application ' Session_OnEnd Runs when a user's session ' times out or quits your ' application ' Application_OnStart Runs once when the first ' page of your application ' is run for the first time ' by any user ' Application_OnEnd Runs once when the Web ' server shuts down </SCRIPT> <SCRIPT LANGUAGE=VBScript RUNAT=Server> Sub Session_OnStart Session("Company") = "NewTech" Session("EMail") = "info@vb-bootcamp.com" End Sub </SCRIPT> Session variables can be created in any Web page or GLOBAL.ASA file, and they can be accessed from any Web page in the application where the variables were originally defined. You can retrieve the values of session variables by reading them out of the Session object. The following code reads the session variables established in Listing 5-4 and displays them in text fields:
<FORM> <P><INPUT VALUE=<%=Session("Company")%>>Company</P> <P><INPUT VALUE=<%=Session("EMail")%>>E-Mail</P> </FORM> Earlier in this chapter, Internet applications were described as stateless transactions between a Web server and a browser. If Internet applications are stateless, how does ASP remember session variables for each user of an application? The answer is that the session variables are saved on the server for each client. The browser itself receives a unique identifier that tells the server which set of data belongs to that client. The client stores the identifier, called a Globally Unique Identifier (GUID), and uses it later to retrieve the data stored by the server. Thus, each client can have individual data for each application used on the Internet.
Request Object
An Internet application certainly differs in many ways from a typical client/server application, but they are similar in that the application absolutely depends upon the transfer of data between client and server. When a Web server wants to send data to a client, it does so by creating a Web page and sending it. When a client wants to return data to the Web server, the browser relies on the process of form submission.
To send data to a Web server, a client utilizes a form with <FORM> tags, which contain data input fields such as text boxes. The client packages the entered data into the data fields and subsequently submits the package to the back end.
The process of submitting a form is controlled by two attributes of the <FORM> tag: METHOD and ACTION. The METHOD attribute of the <FORM> tag determines how the data is sent to the server. This attribute has two possible values: POST and GET. POST tells the browser to package all data inside the form and send it to the server. GET, on the other hand, sends the data as an integral part of the Uniform Resource Locator for the target page. The ACTION attribute specifies the target page for the submitted data. The following code, for example, sends all data from the text fields to a page named DATA.ASP by the POST method:
<FORM METHOD="POST" ACTION="http://www.vb-bootcamp.com/data.asp"> <P><INPUT TYPE="TEXT" NAME="txtName"></P> <P><INPUT TYPE="TEXT" NAME="txtEMail"></P> <P><INPUT TYPE="SUBMIT"></P> </FORM>
The special control designated in the form as TYPE="SUBMIT" is a button that is clicked by the user when the form is ready for submission. Clicking the button causes the browser to package the data in the text fields and submit it. The format of the submitted data is strictly defined so that the server knows what to expect from the client. The data takes the form of Field=Value pairs sent to the server in clear text format. If, in the preceding example, you typed NewTech into the txtName field and Info into the txtEMail field, the following text would be sent to the page DATA.ASP:
txtName=NewTech&txtEMail=Info
On the server side, this data could then be parsed back into fields and values and used by the server for any purpose, including data access or creating and sending e-mail. This is where the Request object comes in. The Request object is used by ASP to parse submitted data received from a client. To use the Request object, simply provide the name of the field you would like to examine, and the Request object returns the value. For example, the following code would return the value NewTech:
<%=Request.Form("txtName")%> Request.Form is used anytime you want to examine the contents of a form submitted to an ASP page. The Request object is available only to ASP pages and can return data only from a form submitted directly to your page. You cannot access data from forms that were not submitted to your page.
Many Internet applications use sequential form submission to accomplish a task such as drilling into a database. However, there are times when a user does not need to fill out a form and submit it and would rather simply click a hyperlink to view data. This too can be accomplished by using the Request object.
Creating a hyperlink that is capable of submitting data requires an anchor, or <A>, tag. The anchor tag uses the HREF attribute to designate a target page and to carry data to the target page when the user clicks the link. A question mark (?) separates the target page and the data. Consider the example in which the form submitted txtName and txtEMail fields. If you wanted to submit the same data using a hyperlink, you might write this code:
<A HREF= "http://www.vb-bootcamp.com/data.asp?txtName=NewTech&txtEMail=Info"> Click here to submit data! </A>
Notice how the data attached to the hyperlink takes the format Field=Value, just as it does in a submitted form. As long as you provide the data in this format, the Request object will be able to parse it. Strangely, you cannot use the syntax Request.Form on data submitted through a hyperlink. Instead, you must use Request.QueryString, which works in the same way as Request.Form but is used on data submitted by a hyperlink. Thus, the following code returns the value NewTech from the hyperlink:
<%=Request.QueryString("txtName")%> The Request object has several other uses as well. You can, for example, use Request to retrieve all kinds of information about the client. You can access everything from cookies sent with the client's request to the user agent string of the browser. Listing 5-5 shows a simple example of using the ServerVariables collection of the Request object to determine the Microsoft Windows NT account that the client is logged on to.
Listing 5-5. Determining the Windows NT logon account.
<%@ LANGUAGE="VBSCRIPT"%> <HTML> <HEAD> <META NAME="GENERATOR" Content="Microsoft Visual InterDev 1.0"> <META HTTP-EQUIV="Content-Type" content="text/html; charset=iso-8859-1"> <TITLE>Server Variables</TITLE> </HEAD> <BODY BGCOLOR="WHITE"> <H1> You are logged in under <%=Request.ServerVariables("LOGON_USER")%> </H1> </BODY> </HTML> Server variables provide a wide range of information about the client and the Web server. Complete documentation of all variables supported in this collection can be found in Visual InterDev, but accessing any particular variable is simply a matter of reading the collection. For example, the following code returns the user agent string of the client browser:
<%=Request.ServerVariables("HTTP_USER_AGENT")%> Response Object
The Response object manages the content returned to a browser by ASP. In fact, although you might not realize it, you use the Response object in every ASP page. When you use the angle bracket/percent sign/equal sign combination (<%=variable%>) to return ASP-generated content, the equal sign is actually shorthand for the Write method of the Response object. Therefore, the following two lines of code are equivalent:
<%="NewTech"%> <%Response.Write "NewTech"%>
Because the Response object is used so frequently in ASP, the equal sign shorthand makes a lot of sense. Otherwise, you would have to type countless iterations of Response.Write into every ASP page.
Another useful feature of the Response object is the Expires property. Response.Expires specifies the time in minutes before the current page expires. If this property is set to zero, the Web page expires the moment it is downloaded and Internet Explorer will not cache the page.
Caching in Internet Explorer version 4.0 affects many development efforts and can prevent your site from behaving correctly. IE 4.0 actually caches pages in two ways: to disk and to memory. Most developers and users are familiar with page caching to disk and expect this to occur, but most people do not realize that IE 4.0 also caches pages to memory. In fact, IE 4.0 remembers in RAM the last five pages that were viewed. This can have a significant impact on the way your application behaves. Consider the following simple code to show a date/time stamp in a Web page:
<H1>The time is now <%Response.Write Now%>
Under normal conditions, IE 4.0 requests this page and the server script is run, causing the current time to appear on the page. However, if the browser moves to another page and then back to the page with the date/time stamp, the time will not change. This is because IE 4.0 has cached the results of the ASP page in RAM and does not request a new page when the browser returns. This behavior will continue until the user visits five different pages, after which the first page is flushed from the RAM cache.
You can prevent this caching behavior by setting the Expires property of the Response object to 0, forcing the Web page to expire. The complete code in Listing 5-6 displays the correct time whenever the page is visible—regardless of whether it is in the RAM cache.
RAM caching can cause strange effects at design time as well. Developers often make changes to a Web page in Visual InterDev, browse it, and wonder why the changes do not appear in the new page. This usually happens because the old version of the page is still in the RAM cache and IE 4.0 does not load the changed page. Therefore, when developing pages in Visual InterDev, always reload your page into the browser after making changes.
Listing 5-6. Forcing a page to expire.
<%@ LANGUAGE="VBSCRIPT"%> <%Response.Expires = 0%> <HTML> <HEAD> <META NAME="GENERATOR" Content="Microsoft Visual InterDev 1.0"> <META HTTP-EQUIV="Content-Type" content="text/html; charset=iso-8859-1"> <TITLE>Forcing a Page to Expire</TITLE> </HEAD> <BODY BGCOLOR="white"> <H1>The time is now <%Response.Write Now%> </BODY> </HTML>
Server Object
The Server object is a sort of catchall object, providing functions that are not related to each other in any way except that they are useful to the Internet developer.
Perhaps the most important of all the Server object functions is the CreateObject method, which creates an instance of an ActiveX component. The component can be either a built-in component that ships with Visual InterDev (discussed in the next section) or a component you make yourself in any language. In any case, using a server-side ActiveX component requires the CreateObject method.
CreateObject takes as an argument the ProgID of the ActiveX component that you want to use. A ProgID is a descriptive name for a component such as Excel.Sheet or Word.Basic. The following code shows how you could use the CreateObject method to generate an instance of an e-mail component that has a ProgID of Mail.Connector.
Set MyObject = Server.CreateObject("Mail.Connector") 
EAN: 2147483647
Pages: 84