Search the Catalog
Designing Active Server Pages

Designing Active Server Pages

Scott Mitchell's Guide to Writing Reusable Code

By Scott Mitchell
1st Edition September 2000
0-596-00044-8, Order Number: 0448
356 pages, $29.95

Chapter 1
Introduction

As the Web has become a more integral part of everyday life and business, web sites have matured from small, static sites into rich, data-driven, complex applications. Several technologies, including dynamic scripting technologies, like Active Server Pages and Perl, have aided along the way, making the Web a more viable application medium. This book focuses on using Active Server Pages to quickly and easily build powerful and dynamic web sites.

Although the server-side tools for building web sites have experienced a nice maturation, the processes used for building these sites have not. What, specifically, is Active Server Page design? What is currently wrong with ASP design? Why hasn't the art of designing ASP pages advanced? What can be done to improve ASP design? The first three questions will be answered in this chapter. The last one, however, is a meaty one; it is addressed in this chapter, and answered over the next seven chapters.

This chapter not only addresses these questions, but also introduces functions and programming styles that will be used extensively throughout this book.

What Is Application Design?

Designing a single ASP page is trivial. The challenges involved in designing ASP pages arise when large web sites with hundreds of web pages are being crafted. These large web sites are, in their own rights, full-scale applications. Therefore, before we examine Active Server Page design, we will first take a step back and discuss application design. As we'll see shortly, application design is a long, arduous process, involving much more than simply punching out code.

Imagine that you have just been assigned the task of creating a new program that will be deployed to all of the employees in your company. This program will allow the users to query a centralized database and place the results into a number of formats that correspond to various interoffice forms your company uses. What do you do first? How do you get started?

Designing, coding, testing, and deploying an application is known as application development. Temporally, it can be viewed as the time span from when the program was first conceptualized to when its first stable version was available for use. (Of course, application development does not end with the first, stable release of a product. Rather, it continues as long as updates and enhancements of the given product are being made.) An entire branch of the computer science discipline is dedicated to studying various application-development methodologies. While there are a number of different methodologies, they all usually share a certain number of phases, which include:

In classical software development, developers usually follow this flow, working on the application's design before moving on to writing the actual code. For example, large software companies draft very detailed plans for their software projects before a developer writes a single line of code.

Designing for the Web

With the Web, the design stage usually focuses on the aesthetics of the web site, such as the look and feel of each web page. This makes sense, since in the Web's earlier days, the vast majority of web sites were static, their usefulness and allure directly dependent upon their HTML design. As the Web matures, though, and web sites become more dynamic, it is important that adequate time be spent on the design of the scripts that run a site.

Simply put, the design phase in web site development focuses too much on the layout and HTML issues and too little on the programmatic side. That's not to say that HTML design is unimportant: it is very important. The end users benefit directly from the HTML design. Imagine a site that had terrible HTML design, a site cumbersome to navigate and difficult to use. Chances are, after one visit to this site, you'd not come back.

Script design, on the other hand, benefits the developers directly, and the end users indirectly. For example, if your dynamic web site contains robust, easy-to-update scripts, the developers will directly benefit from reduced time spent in the coding phase when a new feature needs to be added. The end users will indirectly benefit from such well-designed scripts, since the less code a developer has to write, the less buggy her code will be. Additionally, well-designed scripts require less maintenance time, making it easier to add new functionality to existing scripts. (The benefits of code reuse and robust scripts are discussed in more detail in the next section, "What's Wrong with ASP Design?") Since both HTML design and script design are important, it is essential that adequate time be spent on both.

Since ASP pages are scripts, ASP design is the art of crafting robust, reusable code. Good design requires planning, documentation, and above all, patience. Before you begin writing code for a particular ASP page, think of what the script needs to accomplish. Is it similar to the functionality of other ASP pages on the site? Have you created a page with similar functionality in a past project? How can you build this page so that it can be easily reused in future projects?

What's Wrong with ASP Design?

In my consulting experience, I have found that many developers don't spend any time working on the design of their scripts. Rather, they just start coding once they have an understanding of what the web site needs to look like and what tasks it needs to accomplish.

Such an approach is inefficient and error-prone. If no thought is dedicated to determining the design of the ASP scripts before they are actually written, then for each similar script, the developer essentially reinvents the wheel. For example, imagine the developer has four ASP scripts that need to make modifications to a database. While these scripts may not be identical, assume they all have many functional similarities. Why should the developer spend the time to create each page separately, when one generic page would do?

There is a direct correlation between the amount of code you write and the number of bugs in your program. Typos and silly mistakes catch us all, and they occur proportionally to the amount of raw source code actually written. If we can reduce the number of total ASP scripts that need to be written by generalizing certain scripts to handle the functionality present in the previous four, we will create less buggy ASP applications.

Furthermore, intelligent ASP script design will not only save time and bugs in our current project, but also in future projects. Once a robust module is written to handle a specific task, if that task needs to be completed in a future project, we need only reuse our existing code! With hasty design techniques, code is often written without looking toward the future.

Why Hasn't ASP Design Advanced?

Despite the advantages of a lengthy ASP design stage, ASP pages are still typically designed hastily. Rigorous ASP design hasn't gained wide acceptance due to three reasons:

While ASP design has been lacking, it is not because ASP makes such design difficult. In fact, quite the opposite is true; several techniques can be used to create robust, reusable ASP scripts. In the next section, "What Can Be Done to Improve ASP Design?" and throughout the rest of this book, we'll be looking at the tools and methodologies to accomplish this.

What Can Be Done to Improve ASP Design?

Even though ASP scripts are, obviously, scripts, there are several approaches that can be taken to modularize your source code and encapsulate complex tasks. These include using server-side includes, taking advantage of VBScript classes, and making calls to the Server.Execute and Server.Transfer methods.

Server-Side Includes

One of the most common approaches to creating modularized code is to use server-side includes (SSI). Server-side includes are used to import ASP code into an ASP page. The benefit of being able to import code from one ASP page to another is you can create individual ASP pages with common functions or classes, and have these functions and class definitions imported into the pages that require their use. Instead of having to cut and paste a particular function that is needed in several ASP web pages, you can place that function in a single file, and then use a server-side include to import the function definition into each ASP page that needs to make use of that particular function.

For example, imagine that you run an e-commerce site. Conceivably, there are a number of ASP pages in which you need to compute the sales tax. Rather than hardcode a sales tax percentage in each of these pages, you could create a single function--ComputeTotalWithSalesTax--that would accept the total less the sales tax as a parameter, returning the new total including sales tax. Example 1-1 contains an example of the ComputeTotalWithSalesTax function.

Example 1-1: Determining the Sales Tax

Function ComputeTotalWithSalesTax(curTotalLessSalesTax)
  Const curSalesTax = 0.0695
  ComputeTotalWithSalesTax = curTotalLessSalesTax + _
          curTotalLessSalesTax * curSalesTax
End Function

TIP: 

The above snippet of code places business logic--determining the sales tax--within an ASP page. As we'll discuss in Chapter 7, business logic should be placed in custom components. The above code snippet only serves to show an example of using server-side includes.

If this function existed on each page that needed to calculate the sales tax, imagine what would happen if the sales tax percentage changed. You would have to poke through every ASP page, checking to see if it referenced a hardcoded sales tax value, and if it did, make the appropriate change. Of course, if you missed a page, you'd be in for a headache when certain users were being charged less tax than others.

Needless to say, such an approach is error-prone; furthermore, the developer who chooses this approach is ulcer-prone. A wiser decision would be to place a single instance of the ComputeTotalWithSalesTax function into a file, say /CODEREUSE/ComputeSalesTax.asp, and then use server-side includes in each ASP page that needs to reference this function.

When using a server-side include to import the contents of one file to another, the text from the included file is just dumped straight into the file that issues the server-side include. Using a server-side include is functionally identical to copying the entire contents of the included file and pasting them into the file that initiated the server-side include. Therefore, if you have Option Explicit declared in the file that issues the server-side include (which you always should), you will need to have every variable you use in the included file declared in the included file. Also, the code in the file to be included should be placed within an ASP code block, using either the <% and %> delimiters or the <SCRIPT RUNAT=SERVER LANGUAGE="VBSCRIPT"> and </SCRIPT> delimiters.

TIP:  

ASP pages are not the only type of file that can execute server-side includes. Later in this chapter, in the section "File types that can perform server-side includes," we'll look at using server-side includes in non-ASP pages.

To revisit our sales tax example, if we created a file to hold the sales tax computing function and named that file /CODEREUSE/ComputeSalesTax.asp, we would want to enter the following code into that file:

<%
Function ComputeTotalWithSalesTax(curTotalLessSalesTax)
  Const curSalesTax = 0.0695
  ComputeTotalWithSalesTax = curTotalLessSalesTax + _
          curTotalLessSalesTax * curSalesTax
End Function
%>

Note that the above code is nearly identical to the code in Example 1-1. The only difference is the code snippet above contains the <% and %> delimiters around the ASP code. Remember, this is needed to be properly included.

Now, for each page that needs to access this function, we need to add a single line of code. The following is an example ASP page that uses a server-side include to make the ComputeTotalWithSalesTax function accessible:

<% @LANGUAGE="VBScript" %>
<% Option Explicit %>
<!--#include virtual="/CODEREUSE/ComputeSalesTax.asp"-->
<%
  Dim curTotal
  curTotal = 46.72
 
  'Output the total with sales tax
  Response.Write "Cost Before Sales Tax: " & FormatCurrency(curTotal, 2)
  Response.Write "<BR>Cost After Sales Tax: " & _
           FormatCurrency(ComputeTotalWithSalesTax(curTotal), 2)
%>

The server-side include has two forms:

<!--#include file="filename"-->

and:

<!--#include virtual="filename"-->

If you use the file keyword, then filename is relative to the directory in which the ASP page that issues the server-side include resides. If you use the virtual keyword, filename is relative to the web server's root directory. For example, if from an ASP page in the /MyASPScripts directory you had:

<!--#include file="ComputeSalesTax.asp"-->

then the file ComputeSalesTax.asp would need to exist in the /MyASPScripts directory; if it did not, an error would result when attempting to use the server-side include.

Remember that when using the virtual keyword, you need to specify filename relative to the Web's root directory, regardless of the directory that the ASP page that issues the server-side include exists in. Therefore, if in an ASP page you used:

<!--#include virtual="/CODEREUSE/ComputeSalesTax.asp"-->

the file ComputeSalesTax.asp would need to exist in the /CODEREUSE directory, regardless of what directory the ASP page that issued the server-side include existed in.

Use the virtual Keyword Religiously

When using a server-side include, there is no reason why you should use the file keyword. Commonly used modules should be placed in specific directories (such as /CODEREUSE ). Using the virtual keyword relieves any concern about being able to correctly specify the path relative to the executing ASP page.

Your include files can contain HTML formatting and/or ASP code. Also, an include file can use server-side includes itself to further modularize the code! However, if you try to perform a cyclic include --that is, Page1.asp includes Page2.asp, and Page2.asp includes Page1.asp --an error message will be generated. (More verbosely, the only limitation for including files in included files is included files can't include the file that included them. Be sure to check out the sidebar, "An Interesting Lingo.") Forcing a cyclic include to generate an error makes sense, because if a cyclic include did not generate an error, Page1.asp and Page2.asp would recursively include one another until the web server ran out of available memory.

An Interesting Lingo

Using include files within include files allows for confusing, yet cool-sounding, statements. Imagine what people unfamiliar with server-side includes might think if they overheard you making a comment like: "Hey, Bob, in Report.asp, did you want the file included by the include to include stats.asp, which includes another included file, or do you want Report.asp not to include any included files that include included files?"

Example 1-2 contains the code for Page1.asp, while Example 1-3 contains the code for Page2.asp. If you visit Page1.asp through a browser, the error message shown in Figure 1-1 will be generated.

Example 1-2: Page1.asp Uses a Server-Side Include to Import the Contents of Page2.asp

<%
   Response.Write "Preparing to include Page2.asp<P>"
 
 
   'Include the file Page2.asp
%>
<!--#include file="Page2.asp"-->

Example 1-3: Page2.asp Uses a Server-Side Include to Import the Contents of Page1.asp

<%
   Response.Write "Preparing to include Page1.asp<P>"
 
 
   'Include the file Page1.asp
%>
<!--#include file="Page1.asp"-->

Figure 1-1. Attempting to perform a cyclic include generates an error message

 

File types that can perform server-side includes

ASP pages are not the only files that can perform server-side includes. Any file type that is mapped to asp.dll or ssinc.dll can perform server-side includes.

When a client requests a file from an IIS web server, the web server first determines the file extension being requested by the client. Next, the web server checks to see if that extension is mapped to a particular ISAPI DLL. If there is a mapping between that file extension and an ISAPI DLL, the ISAPI DLL is invoked. This is, essentially, what happens when you request an ASP page through your web browser.

ssinc.dll is an ISAPI DLL that allows server-side directives to be executed. A server-side include is one facet of server-side directives. See the "Further Reading" section for an article that discusses server-side directives in more detail. In IIS 5.0, files with the extensions .shtml, .shtm, and .stm are, by default, mapped to ssinc.dll, and therefore can perform server-side includes. Of course, files with these extensions cannot process ASP code, unless you explicitly map these extensions to be processed by asp.dll.

TIP:  

asp.dll is capable of performing only one type of server-side directive: server-side includes. ssinc.dll, on the other hand, can perform all server-side directives but cannot process ASP code. For more information on all of the server-side directives, be sure to refer to the article "Using Server-Side Directives" listed at the end of this chapter in the "Further Reading" section.

You can explicitly map particular file extensions to particular ISAPI DLLs. To change a file extension mapping in Windows 2000, go to Start Programs Administrative Tools Internet Services Manager (in Windows NT, open up the IIS MMC). A listing of the web sites on your computer should appear. Right-click on the web site whose file extension mapping you wish to alter, and click on Properties. A tabbed Web Site Properties dialog box will appear; select the "Home Directory" tab, and click the Configuration button. You should now be presented with the Application Configuration dialog box shown in Figure 1-2.

Figure 1-2. The "App Mappings" tab of the Application Configuration dialog box lists each file type's corresponding ISAPI DLL

 

Note that the .asp file extension is mapped to asp.dll, while the extensions .shtml, .shtm, and .stm are mapped to ssinc.dll. You can add, edit, and remove these mappings. For example, you could create a new extension mapping, having all files with the extension of .scott map to ssinc.dll. With such a mapping, files on your web site with the .scott extension would be functionally identical to files with extensions of .shtml, .shtm, or .stm; in short, .scott files would be able to perform server-side directives!

WARNING:  

Be careful when adding new application mappings. There is a bug in IIS 5.0 that can arise when the .htm extension is mapped to ssinc.dll and the default document is a .htm file. For more information on this bug, be sure to read: http://support.microsoft.com/support/kb/articles/Q246/8/06.ASP.

Dynamic server-side includes

Server-side includes are executed before any ASP code is processed. Due to this fact, you cannot specify a dynamic filename. For example, it would be nice to be able to do something like:

<%
  Dim strPage
  strPage = "/scripts/MyPage.asp"
%>
<!--#include virtual="<%=strPage%>"-->

However, since the server-side includes are performed before the ASP code is processed, the above code will cause IIS to complain that the file <%=strPage%> cannot be found. There are some methods available to fake dynamic server-side includes. One way is to use a Select Case statement, with a Case for each potential server-side include. For example, if you knew you would need to process the code in one of five potential include files, you could use the following code:

<%
Select Case strPageToExecute
   Case "IncludeFile1.asp" %>
    <!--#include virtual="/IncludeFile1.asp"-->
<% Case "IncludeFile2.asp" %>
    <!--#include virtual="/IncludeFile2.asp"-->
<% Case "IncludeFile3.asp" %>
    <!--#include virtual="/IncludeFile3.asp"-->
<% Case "IncludeFile4.asp" %>
    <!--#include virtual="/IncludeFile4.asp"-->
<% Case "IncludeFile5.asp" %>
    <!--#include virtual="/IncludeFile5.asp"-->
<% End Select %>

Each server-side include is issued immediately before any of the ASP code in the ASP page is run. That means all of the five server-side includes will be executed and their contents imported into the ASP page.

The downsides of this approach are that you are limited to a finite number of potential include files, and for each potential include file, you need to hardcode a case statement. As well, whenever you use an #include directive, the entire contents of filename are inserted into the ASP script before processing. If you have a large number of potential include files and these files contain large amounts of code, this could cause a performance bottleneck.

Another way to "fake" dynamic server-side includes is to use the FileSystemObject object model to read in the contents of the include file you are interested in inserting into your ASP page. The following code allows for a file to be inserted into an ASP script:

<% Option Explicit %>
<%
  '************************* DESCRIPTION **************************
  '* Output the entire contents of a text file, whose name can be *
  '* dynamically generated.                                       *
  '****************************************************************
  Dim strFileName, objFSO, objFile
 
  'Create an instance of the FSO object
  Set objFSO = Server.CreateObject("Scripting.FileSystemObject")
 
  'What file do we want to import?
  strFileName = "C:\InetPub\wwwroot\Adages.htm"
 
  'Open a text file, using the OpenTextFile method
  Set objFile = objFSO.OpenTextFile(strFileName)
 
  'Output the entire contents of the text file
  Response.Write objFile.ReadAll
 
  objFile.Close     'Close the file...
 
  'Clean up
  Set objFile = Nothing
  Set objFSO = Nothing
%>

TIP:  

Note that the FileSystemObject expects full physical filenames (C:\InetPub\wwroot\Adages.htm) and not virtual filenames (/Adages.htm).

The above code may seem like it accomplishes a dynamic server-side include, but it is a little misleading. Since the text file cannot be opened and read until the ASP script is running, if there is any ASP code within the file specified by strFileName, it won't be executed; rather, the ASP code will be output just like any other HTML content in the file! This method is an acceptable one if you only need a dynamic server-side include to read in an HTML header or footer. However, any ASP code in the file specified by strFileName will not be executed!

With ASP 2.0, truly dynamic server-side includes were impossible. However, with ASP 3.0 and the new Execute method of the Server object, true dynamic includes are possible! Server.Execute is discussed in the section "Using Server.Execute."

Naming your include files

When grouping common functions into a particular file to be included by other ASP pages, be sure to give the file an .asp extension. If you fail to do this, and a web surfer guesses the correct filename of an include file, the user can view the contents of the include file! Files with an .asp extension are safe from prying eyes because when an ASP page is requested, IIS steps in and executes the ASP page, turning the ASP code into HTML. Files without an .asp extension are not processed by IIS and are sent directly to the client. This can reveal the source code of your include files.

If for some reason, you must use include files with a non-ASP extension, be sure to place these files in a directory that has HTTP read permissions turned off. With the HTTP read permissions turned off, ASP pages can still import the contents of these include files, but if someone attempts to request these files directly through an HTTP-request (i.e., entering the full URL of the include file in their browser), they will receive an error message indicating that HTTP reads are not permitted.

Since developers often place constants, database connections, and common functions in include files, it is imperative that the contents of include files remain away from prying eyes.

It's true there is not a great chance that anyone will be able to exactly guess the name of an include file. However, that does not mean your include files are safe. Jerry Walsh has detected a potential security bug that can occur when using server-side includes. This security bug happens when you create an include file that has a programmatic error in it. For example, imagine a file named /CODEREUSE/dbConn.inc that contained the following code:

<%
  Dim objConn
  Set objConn = Server.CreateObject("ADODB.Conection")
  
  objConn.ConnectionString = "DRIVER={Microsoft Access (*.mdb)};" & _
                 "DBQ=" & Server.MapPath("/MyDatabase.mdb")
  objConn.Open
%>

Note that there is an error in the above code snippet: the class ID for the Connection object is misspelled, with "Conection" missing an "n." Many ASP sites use an include file to have one database connection file. However, making such a page with an error can yield disastrous results, as we'll see shortly. Now, if some page on your site uses this include file like so:

<% @LANGUAGE="VBScript" %>
<% Option Explicit %>
<!--#include virtual="/CODEREUSE/dbConn.inc"-->
<%
  'Do stuff with the database connection...
%>

an error will occur when a user visits the page, since there is an error in /CODEREUSE/dbConn.inc. Specifically, the user will see the error message:

Microsoft VBScript runtime error '800a004' 
 
Invalid Class String
 
/CODEREUSE/dbConn.inc, line 3

Notice that the full path to the include file is displayed in the error message! Since the include file does not contain an .asp extension, anyone who stumbles across this erroneous page can now visit your database connection script, which contains the path to your Access database (MyDatabase.mdb). The user can now download directly!

You might think you are safe if you do not provide some mechanism for your users to reach the ASP page that uses the erroneous include file. That is, if you provide no direct hyperlinks to this page, no user will see the error message and no user will know the include file's path. While it is true that no user will likely stumble across the ASP page, search engines may still index them!

Again, you might think that this is a minor problem and that there is an incredibly low probability that a search engine will index this odious page. However, if you go to AltaVista and enter the following search terms:

+"Microsoft VBScript runtime error" +".inc, "

you'll find that an alarming number of pages are returned that display the complete path to an include file whose contents can be read by any visitor!

The moral of this story: don't put files whose contents will be imported into ASP pages via a server-side include on your production web site until they have been thoroughly tested and do not contain any errors that will reveal their location. Or, more simply, just make sure you give your include files an .asp extension or place them in a directory where HTTP read permissions are turned off. Another potential solution is discussed in Chapter 3, Exception Handling. In that chapter, we'll look at how to have include files (and other ASP pages) handle errors more gracefully than simply spitting out an error message.

WARNING: 

According to an article on Microsoft's web site (http://msdn.microsoft.com/library/tools/aspdoc/iiwainc.htm), "...it is good programming practice to give included files an .inc extension to distinguish them from other types of files." Be sure not to follow this suggestion unless you place these files in a directory that has read permissions disabled.

Protecting the contents of your include files from prying eyes

There are some simple steps you can take to ensure that your include files' contents won't be seen by prying eyes. The two simplest options are:

More about server-side includes

Server-side includes are extremely useful for developing and using code modules. Placing common code in modules allows for easier code reuse. Throughout this book, server-side includes are used quite frequently. Often classes will be created that are used among many ASP pages. Rather than copying the class definition into each ASP page, it makes much more sense to define the class in a single file and to use a simple server-side include in all of the pages that need to utilize the given class.

Since server-side includes are used so frequently throughout this book, it is important you have a solid understanding of how they work. If you are a little rusty on server-side includes, I highly recommend that you take the time to read the following two articles:

VBScript Classes

Since Version 5.0 of the VBScript scripting engine, developers have had the opportunity to use VB-like classes in their VBScript code. Classes provide for an object-oriented-like programming approach when developing ASP pages, which greatly enhances the reusability of a particular ASP page.

Classes are great for creating black-box modules. For other developers to use a black-box module, they do not need to know any of the specific implementation details; rather, they just use the black box through its publicly accessible methods and properties.

We will discuss classes in detail in Chapter 4, Regular Expressions, Classes, and Dynamic Evaluation and Execution. Classes are used extensively in Chapter 5, Form Reuse, and Chapter 6, Database Reuse, as we look at code reuse techniques. Since classes encapsulate complexity, hide implementation details, and function as a black box for the developer, classes assist greatly when creating reusable code.

TIP:  

In Chapters and we will be examining reusable scripts that make heavy use of VBScript classes.

Using Server.Execute

Server.Execute can also be used to modularize your ASP code. Server.Execute branches the control flow from one ASP page to another. When the page that was called via the Server.Execute completes processing, control is returned to the page that issued the Server.Execute command. Figure 1-3 illustrates the semantics of Server.Execute.

Figure 1-3. Server.Execute branches the control flow to a separate ASP page, runs the page, and returns the control flow to the original page

 

Server.Execute's main advantage is its ability to perform truly dynamic includes. For example, using Server.Execute, you could do the following:

<%
  Dim strPage
  strPage = "/scripts/MyPage.asp"
  Server.Execute(strPage)
%>

When an ASP page uses Server.Execute to branch control to another ASP page, all of its built-in ASP objects are passed along. For example, if Page1.asp issues a Server.Execute("Page2.asp"), Page2.asp will have access to Page1.asp's intrinsic ASP objects. Remember that the Request object is an intrinsic ASP object and that it contains the Form and QueryString collections. Since all the intrinsic objects are shared from Page1.asp to Page2.asp, when Page2.asp attempts to read from either of these Request object collections, it is reading the values from Page1.asp's Request object collections. Now that's a mouthful!

For example, if Page1.asp simply had the code:

Server.Execute("Page2.asp") 

and Page2.asp simply had the code:

Response.Write Request("Age")

if we visited Page1.asp through a browser, entering the URL http://localhost/Page1.asp?Age=21, the Response.Write in Page2.asp would output 21.

To summarize: Server.Execute can be used in place of server-side includes when dynamic includes are needed. If you don't need dynamic includes, and a vanilla server-side include would suffice, I would recommend sticking with the server-side include.

Using Server.Transfer

Server.Transfer can also be used to improve ASP script design, although it cannot serve as a modularization technique like Server.Execute and server-side includes. Server.Transfer is similar to Server.Execute. If Page1.asp performs a:

Server.Transfer("Page2.asp") 

the control flow is transferred to Page2.asp. When Page2.asp finishes executing, control is not returned to Page1.asp. Figure 1-4 illustrates the semantics of Server.Transfer.

Figure 1-4. Server.Transfer branches the control flow to a separate ASP page, runs the page to completion, and stops executing

 

As with Server.Execute, when Page1.asp performs a Server.Transfer ("Page2.asp"), Page1.asp's built-in ASP objects are passed along to Page2.asp. Being able to access the Request.Form and Request.QueryString collections from Page1.asp in Page2.asp is an incredibly useful feature, which we'll capitalize on in Chapter 5 and in Chapter 6.

Server.Transfer improves ASP design by providing a mechanism to seamlessly move from one ASP page to another. Part of good application design is creating robust, reusable code, which usually results in the creation of several generic helper ASP pages. With Server.Transfer, we can "plug into" these helper pages, moving from one to the next. In Chapter 5 we'll look at applying Server.Transfer to gracefully hop from one ASP page to another!

Further Reading

At the end of each chapter you'll find a "Further Reading" section. These sections include links to articles that relate to the topics discussed within the chapter. These articles aren't prerequisites to understanding the topics covered in the chapter; rather, they are auxiliary readings, either describing some of the chapter topics in finer detail or providing information on related topics. In either case, I think you'll find these suggested readings worthwhile and beneficial.

Back to: Designing Active Server Pages


O'Reilly Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
International | About O'Reilly | Affiliated Companies

© 2001, O'Reilly & Associates, Inc.
webmaster@oreilly.com