Active Server Pages
In this section, we'll explore Active Server Pages technology. You should know about ASP for several reasons. First, the Outlook HTML Form Converter, a conversion tool that migrates Outlook forms to HTML forms, utilizes this technology. We'll examine the converter later in this chapter. Second, ASP is used in other areas, including Collaboration Data Objects (CDO) and Active Directory Services Interfaces (ADSI). We look more closely at CDO in Chapter 12 and ADSI in Chapter 15.
ASP Fundamentals
Active Server Pages are standard text files that contain HTML and script. The script can be written using any ActiveX scripting language, such as VBScript or JScript. The HTML files that most Web developers write differ from ASP files in two significant ways. First, instead of having an .htm or .html file extension, ASP files have an .asp file extension. When you install IIS, as a part of your installation you also install an Internet Server Application Programming Interface (ISAPI) component that processes all files with an .asp extension. This ISAPI component parses the ASP file and executes the appropriate script. Second, the actual script is processed on the Web server. The processed results can include client-side scripting code but for the most part is just simple HMTL. Returning only HTML has two benefits: any modern Web browser can view the results of an ASP application and the additional capabilities of the browser is less of an issue.
Since Active Server Pages supports VBScript, you can easily move from developing Outlook forms to developing ASP pages. The only difference in the development process is that you should use the CDO library to write your Active Server Pages application rather than the Outlook object library, because CDO was designed to be multiuser and server-based.
The following code is an example of an ASP application. This example uses the VBScript function Now to print the date and time that the ASP application ran on the Web server.
<%@ LANGUAGE="VBSCRIPT"%> <!DOCTYPE HTML PUBLIC ""-//IETF//DTD HTML//EN"> <HTML> <HEAD><TITLE>ASP Example</TITLE></HEAD> <BODY> <H1>I was created on <%=Now()%></H1> </BODY> </HTML> |
As you can see, the syntax of the ASP script is a little bit different from the syntax for Outlook code. To tell the Web server that you want to run a script on the server, you must enclose it in special characters: <% and %>. Active Server Pages supports placing your script directly in your HTML code—the script does not have to be in a separate section of the HTML file.
Take a look at the first line of the code:
<%@ LANGUAGE="VBSCRIPT"%> |
ASP assumes that the default language for server-side script is VBScript. If you replace VBSCRIPT with JSCRIPT, you can write server-side JScript code.
NOTE
You can specify the default ASP language for an application in the Management Console for IIS. Open the Properties window for an application, and in the Applications Settings area, click the Configuration button. On the App Options tab, type the desired default language in the Default ASP Language text box.
You might be wondering what the <%=Now()%> code does in this example. The equal sign (=) indicates that the code should evaluate the expression, which in this case returns the current date and time. As you will see, the equal sign in ASP is a shortcut for calling the Write method of the Response object.
Global.asa
If you've viewed the actual directories that contain .asp files, you might have noticed a certain file with the .asa extension: Global.asa. This is a special file in ASP applications that allows you to include global code that executes when an application starts and ends and also when a session starts and ends. One thing to remember is that the Global.asa is an optional file for your Web applications. A skeleton Global.asa file is shown here:
<SCRIPT LANGUAGE="VBSCRIPT" RUNAT="Server"> Sub Session_OnStart 'Put your session startup code here End Sub Sub Session_OnEnd 'Put your session termination code here End Sub Sub Application_OnStart 'Put your application startup code here End Sub Sub Application_OnEnd 'Put your application termination code here End Sub </SCRIPT> |
The Global.asa file contains stubs for your session and application start and end subroutines. To understand when these subroutines are called, you must understand what exactly constitutes a session and an application inside ASP.
Normally when you browse Web pages, the Web server does not remember who you are or where you have been, and it does not store any values associated with you. One of the features of ASP is that it transforms the applications you can build on the http protocol from being stateless to being able to track the state of users. This ultimately lets you create global variables that are maintained for users throughout an application.
An ASP application consists of a virtual directory and associated files. But to understand when an ASP application starts and ends, you'll need a little bit more explanation of how ASP works. For your Application_OnStart subroutine to be called, the first user must request an .asp file from the virtual directory of your ASP application. The user can request an HTML file or other types of files from that directory. However, these requests will not cause the Application_OnStart subroutine to be called. The user must explicitly request an ASP file. This is the only time this subroutine will be called, unless you restart the application. Restarting the application usually consists of restarting the Web service.
You should use the Application_OnStart subroutine to initialize global variables across the lifetime of the Web application. A good example of a variable to initialize or set in your Application_OnStart subroutine is one that counts the number of users who have used your application. To improve performance, for every user in your ASP application, you should initialize in the Application_OnStart subroutine any server components that you will use. Figure 7-4 illustrates a Web browser sending a request to an ASP application for the first time.
Figure 7-4. When the first user of an application requests an .asp file, the Application_OnStart event is fired and then the Session_OnStart event fires.
When the user who first requested the ASP page also browses an .asp file in your application, the Session_OnStart event is called. Unlike the Application_OnStart event, the Session_OnStart event is called for any user who makes an application file request. With ASP, each user of your application is considered to have a distinct session with the Web server. As a user browses Web pages in your ASP application, ASP implements and maintains state in a session by using cookies—whenever a user connects to your application, a file containing information (a cookie) is saved on the user's machine. When his session ends and he closes his Web browser, the cookie is removed and the session is invalidated. If he reconnected to your application, his machine would receive a new cookie and a new session would be started. For this reason, the users of your application must support and accept cookies; otherwise, your ASP applications will not fully function. You can still use the server-side script of ASP, but you cannot maintain state information for any of your users.
The Session_OnStart event is best used to initialize session variables for individual users. Session scope variables include a connection to Exchange Server for an individual user and personalized information that a user has set in your application—for example, a user could specify a background color for Web pages that is stored in a session variable. Then, each page the user accesses from your site during a session could be displayed in her personalized background color. Figure 7-5 shows each Web browser starting a new session when accessing an ASP application.
Figure 7-5. Whenever a new user accesses your ASP application, the Session_OnStart event fires. Application_OnStart fires only when the first user accesses your application.
The Session_OnEnd event is called when the session with the Web server ends. This end state can be reached in two ways:
- When the user has not requested or refreshed a Web page in the application for a specified amount of time
- By explicitly calling the Abandon method on the Session object
By default, IIS sets the timeout interval at 20 minutes. You can change this interval either through the administration program for IIS or by setting the TimeOut property on the intrinsic Session object in ASP. For example, to set a particular script timeout to 10 minutes, you would write the following code in your ASP application:
<% Session.TimeOut = 10 %> |
The second way to reach the end state—by explicitly calling the Abandon method on the Session object—immediately ends the session and calls the Session_OnEnd event.
NOTE
Applications discussed in later chapters (CDO Helpdesk, Event Scripting Expense Report, Routing Objects Expense Report) provide a logout menu option. This option calls another ASP file, which calls the Abandon method on the Session object to end the session.
One final note about sessions: you have to be careful when you redirect people to other virtual directories in your application. Developers, including me, commonly make the mistake of redirecting users to another virtual root and forget that this is considered by ASP to be an application. When you do this, the session variables you establish in one application will not transfer to the other application. If you want to share session variables between the two applications, you should place the second application under the same virtual directory in IIS as the first application.
When a Web application ends, the Application_OnEnd event is called. You end a Web application in one of two ways: by shutting down the Web server, or by stopping your application by using the Unload button in the IIS administrator. To use the Unload button, you must be running your Web application in a separate memory space. So make sure you save any application scope variables to a persistent medium, such as to your Exchange server or to a database, so that when your application restarts, the Application_OnStart event can reload the values. For example, you don't want a user-counter variable to restart at zero every time your application restarts. You should also destroy any server objects that you have created with an application scope. This will eliminate potential memory leaks on your server.
Built-In ASP Objects
The real power of ASP applications is that you can write server-side scripts and use their intrinsic objects. ASP and its built-in objects enable you to generate custom responses and maintain state information. The following section describes, in detail, five built-in objects in ASP: Application, Session, Request, Response, and Server.
NOTE
The only object not covered here is the ObjectContext object, available in IIS version 4.0. This object can be used for creating ASP applications with transaction capabilities. For more information on the ObjectContext object and transactions, consult the IIS product documentation.
Application Object
The Application object is used to store global data related to an application that can be shared among all users. By using the methods and properties of this object in your application, you can create and set variables that have an application scope. To make sure that you do not run into concurrency issues when setting your application-level variables, since multiple users can be using the same application simultaneously, the Application object provides two methods: Lock and Unlock. These methods serialize the access to application-level variables so that only one client at a time can read or modify the values. The following example shows how to use the Lock and Unlock methods to increment a user-counter variable whenever a user accesses the application. The example also shows you how to set and retrieve application-level variables by using the Application"("VariableName") syntax:
<HTML> <HEAD> <TITLE>Example: Application Object</TITLE> </HEAD> <BODY> <% Application.Lock Application("NumVisitors") = Application"("NumVisitors") + 1 Application.UnLock %> Welcome! You are visitor #<%=Application"("NumVisitors")%>. </BODY> </HTML> |
The Application object also contains two other collections beyond the variables collection—Contents and StaticObjects—which allow you to browse through the application-level objects and variables you have created. You probably won't use either of these collections in your final applications, but both of them provide great debugging functionality. For example, the Contents collection enables you to list all the items that have been added to your application through a script command, and the StaticObjects collection enables you to list all the items with an application scope that have been added using the <OBJECT> tag. By adding debug code to your application at design time, when you run into application object problems, you can make ASP list all the objects you have created with an application scope. The following code illustrates creating debug code for both the Contents and StaticObjects collections. You can see the code output in Figure 7-6.
<HTML> <HEAD> <TITLE>Debugging Application Objects</TITLE> <% 'Create some application variables Application.Lock Set Application"("oCDOSession") = _ Server.CreateObject"("MAPI.Session") Application("counter") = 10 Application.UnLock %> <P>Objects from the Contents Collection<BR> <% for each tempObj in Application.Contents response.write tempObj & "<BR>" next %> <P>Objects from the StaticObjects Collection<BR> <% for each tempObj in Application.StaticObjects response.write tempObj & "<BR>" next %> </BODY> </HTML> |
Figure 7-6. The debug output for the Contents and StaticObjects collections. As you can see, objects and variables both can have an application scope.
Session Object
The Session object is one you'll use a lot in your Web applications. It holds the variables for individual users across the Web pages in your application. When you place a variable in the Session object, that variable is valid only for the current user and cannot be shared among users in the same way that an Application variable can.
Like the Application object, the Session object contains the Contents and StaticObjects collections. You can also create session variables in the same way you create Application variables, by using the syntax Session("VariableName").
The properties for the Session object include CodePage, LCID, SessionID, and TimeOut. The CodePage property represents the language code page that will be used to display the content for the HTML page. The Outlook HTML Form Converter, which you'll learn about later in this chapter, uses this property in its converted forms, as shown here:
<% @LANGUAGE=VBSCRIPT CODEPAGE = 1252 %> |
You can use the LCID, or locale identifier, property in conjunction with the CodePage property. The LCID property stores a standard international abbreviation that uniquely identifies a system-defined locale.
The SessionID property returns to you the unique session identifier for the current user. You should remember, however, that this ID is unique only during the lifetime of the ASP application. If you restart your Web server and therefore restart your Web applications, the Web server might generate the same IDs it already generated for the users before the Web application was restarted. For this reason, you should avoid storing these IDs and attempting to use them to uniquely identify a user of your application. If you always need to uniquely identify your users whenever they access your application, you should use globally unique identifiers (GUIDs) in cookies, which are saved on the users' computers.
The fourth property of the Session object is the Timeout property. This property enables you to change the timeout period associated with a particular ASP session. Remember that by default, the timeout is set to 20 minutes. If you know that your application will be used for less than 20 minutes, you might want to decrease the duration of the timeout so that sessions end more quickly and resources are returned to the Web server at a faster rate.
The only method of the Session object is the Abandon method. As mentioned earlier, by calling this method, the user's session with the Web server as well as any associated objects and variables for that session are destroyed. If the user attempts to reconnect to the Web application, a new session starts on the server.
Request Object
The Request object allows you to access the information that was passed from the Web browser to your Web application. The Request object is crucial in ASP applications since it enables you to access user input for your server-side scripts. For example, suppose a user fills out an HTML form that you created. Once the user clicks the Submit button on the form, the Request object contains the form information that was passed to the server. By using the collections of the Request object, you can retrieve that information and design your application to respond based on the user's input.
Request object collections
The Request object collections are created when the user submits a request to the Web server either by requesting an ASP file or by submitting an HTML form via clicking the Submit button. The three collections of the Request object that you'll primarily work with in your ASP applications are the Form, QueryString, and ServerVariables collections.
NOTE
For information on the other two collections, ClientCertificate and Cookies, refer to the IIS documentation.
To understand when to use these collections, you first need to know about the different ways information can be passed from the Web browser to the Web server. Normally in your Web applications, you use HTML forms to gather input from the user so that you can use it in your calculations or store it in a data source. There are two main ways input can get passed to the Web server from the client browser: via the Get method and via the Post method. The example that follows shows an HTML page that contains both methods on the same page.
<html> <head> <title>Forms Galore</title> <meta name="GENERATOR" content="Microsoft FrontPage 3.0"> </head> <body> <form method="GET"" action="getinfo.asp"" name="GetForm"> <p>What is your e-mail address?</p> <p><input type="text" name="e-mail" size="20"></p> <p><input type="submit" value="Submit" name="GetSubmit"> </p> </form> <form method="POST" action="getinfo.asp" name="PostForm"> <p>What is your first name?</p> <p><input type="text" name="firstname" size="20"></p> <p><input type="submit" value="Submit" name="PostSubmit"> </p> </form> </body> </html> |
The Action attribute for each of the HTML forms specifies the same ASP file, getinfo.asp. The getinfo.asp file is shown here:
<HTML> <HEAD> <TITLE>Post and Get Methods Example</TITLE> </HEAD> </BODY> <%txtRequestMethod = Request.ServerVariables"("REQUEST_METHOD"")%> You selected to use the <B><%=txtRequestMethod%></B> Method. <P><% if txtRequestMethod="GET"" then %> You entered your e-mail address as: <B><%=Request.QueryString"("email")%></B> <% else %> You entered your first name as:  <B><%=Request.Form"("firstname")%></B> <% end if %> </BODY> </HTML> |
This ASP code uses the ServerVariables collection of the Request object to check whether the form's Request method was a Post or Get method. Once the file determines which method was used, it displays the correct information for that particular type of form. Figure 7-7 shows a sample of the Get method.
Figure 7-7. When a user types an e-mail address and submits the form, the Get method is used to pass the information to the Request object.
NOTE
You can also retrieve other server variables such as HTTP_USER_AGENT, which returns information about which browser the client is using; and LOGON_USER, which represents the Microsoft Windows NT account the user is currently logged on to. For a complete list of server variables, see the IIS documentation.
As you can see in Figure 7-7 with the Get method, the information from the form is actually appended to the URL—for example:
http://exserver/examples/getinfo.asp?email=thomriz@microsoft.com&GetSubmit=Submit
When data is appended to the URL using the Get method of a form, you use the QueryString collection of the Request object to retrieve the data. When using the QueryString collection, follow this format to retrieve the information:
Request.QueryString"("VariableName"") |
Because the information that is passed to your application appears in the address of the user's browser, the user can see it, so you might want to limit when you use the Get method. Instead, consider using the Post method.
The Post method places the form information inside the HTTP header, hiding the information from the client. However, when the Post method is used to submit form variables, you cannot use the QueryString collection. Instead, you need to use the Forms collection of the Request object. In the preceding example, the line
Request.Form"("firstname") |
retrieves the information the user typed into the First Name text box on the form. You can use this same syntax in your applications to retrieve information from an HTML form.
Response Object
The Response object is used to control the content that is returned to the client. For example, when you calculate a value on the server, you need a way to tell the ASP engine that you want to send the information back to the client. You do this by using the Write method of the Response object.
The Write method of the Response object will be the most commonly used method in your ASP applications. Even though you have not seen any explicit statements using the Response.Write method in the examples, they are there. The syntax <%=Variant%> is equivalent to <% Response.Write Variant %>. The shorthand version makes it easier for you to put these statements in your code quickly.
The Response object has a number of other collections, properties, and methods that you can use, such as the Expires property, which tells the Web browser how long to cache a particular page before it expires. If you do not want your clients to cache your Web pages, you would add the following line to your ASP files to cause your Web page to expire immediately on the user's local machine:
<% Response.Expires = 0 %> |
The Response object allows you to buffer the output of your ASP page. This is useful if you want to hold back the output of your ASP code until the script completes its processing. The best example for using buffering is to capture errors in your code. For example, by turning buffering on using the command Response.Buffer = True, you can check throughout your ASP code whether an error has occurred. If one has, you can clear the buffer without sending its contents by using the Response.Clear method, and then you can replace the output with new output such as Response.Write "An error has occurred. Please contact the administrator." Finally, you can call the Response.End method, which sends the new contents of the buffer to the client and stops processing any further scripts in the ASP.
Server Object
The Server object provides you with utility methods and properties to modify the information on your Web server. This object is used extensively in ASP applications because it contains both the CreateObject method and the ScriptTimeout property.
The CreateObject method allows you to create an object on the Web server by passing in the ProgID for the object. Let's look at an example. To create a CDO object, you would type this in your ASP file:
Set oSession = Server.CreateObject("MAPI.Session") |
ASP creates an object and passes that object to you in the oSession variable. By default, when you do this on an ASP page, the object has page-level scope. This means that when ASP is done processing the current page, the object is destroyed. Therefore, you might want to create objects on a page and then store them by assigning them to either session variables or application variables, as shown in this code snippet:
<% Set oSession = Server.CreateObject("MAPI.Session") Set Session("oSession") = oSession %> |
As you learned earlier, an object that is assigned either a session or an application scope will be destroyed when either the session or the application ends, respectively. The one issue to watch out for with the CreateObject method and some objects is potential performance loss. You can instantiate almost every object on your Web server as an ASP object, but some objects are specifically designed to run in a server-based, multiuser environment such as CDO. When you instantiate an object that was not designed for an ASP environment, the application performance might suffer if many people hit the page containing that object at the same time.
The ScriptTimeout property of the Server object allows you to specify how long a script should run before it is terminated. By default, an ASP script can run for 90 seconds before it is terminated, but this might not be enough time to retrieve data from a data source. By using the following syntax for this property, you can increase or decrease the amount of time the script will run before termination:
Server.ScriptTimeout = numseconds |
Avoid increasing this number much beyond 90 seconds, because users who are waiting for long periods of time might assume the page did not load correctly, and they might click their Stop and then Refresh buttons continuously, flooding your Web server with requests.
Server-Side Include Files
One other powerful feature beyond the intrinsic objects of ASP is the ability to use server-side include files in your ASP files. Include files are just text files containing script or HTML that you want to add to your ASP page. Outlook Web Access, which you will learn about later in this chapter, relies heavily on server-side include files for common code libraries in its ASP files. Here are some examples of server-side include files:
<!-- #include file="library/vbsfunctions.inc" --> <!-- #include virtual="/library/vbsfunctions.inc" --> |
Server Components
ASP can take advantage of built-in objects and also use server components to add functionality to ASP. An example of two such components are Microsoft ActiveX Data Objects (ADO) and CDO. ADO allows you to connect to many types of databases; CDO allows you to connect to Exchange Server and other messaging servers. You can also write your own components using any COM-based development tool.
NOTE
There are a number of other components packaged with ASP that you can use in your applications, including Ad Rotator, Browser Capability, Content Linking, Content Rotator, File Access, Page Counter, and Permission Checker. If you want to learn more about these components, you should refer to the documentation that ships with IIS version 4.0.
EAN: 2147483647
Pages: 184