Developing Web Applications

Execution Behavior of Scripts in ASP Pages

When you write ASP applications, you’re operating in the world of IIS 5.0 and HTTP. Web developers who don’t have a firm grasp of this architecture find themselves puzzled by strange errors in what seems to be straightforward code.

Consider the process shown in the following figure:

Requesting an .asp File from IIS 5.0

When a client browser requests an ASP page, a number of events occur in the following sequence:

The client requests an ASP page by sending an HTTP Request to the Web server.
Because the page has the .asp extension, the service (IIS 5.0) recognizes it as a scriptmapped file, and sends the file to the appropriate ISAPI extension (in this case, to Asp.dll) for processing. (This step does not occur when the client requests an HTML file.)
The ASP ISAPI processes any server-side include directives first, before any serverside script is compiled. Next, the script is executed, and dynamic text, if any, is incorporated into the page that will be returned to the client. (This step only happens when the page is first requested. Previously compiled pages are retrieved from a serverside cache for faster performance.)
The server creates the resulting HTML page to be sent back to the client. The page output is sent incrementally as the page is generated, or all at once if the response is buffered.
Once the client receives the ASP page, it loads any client-side objects and Java applets, executes any immediate client-side script code and displays the Web page according to the HTML specification.

While this process looks simple, keep in mind that the client and server could be hundreds, or even thousands, of miles apart. Therefore, when a problem arises, you must determine where the error is occurring. Is it on the client or on the server? Equally important is understanding when each operation takes place. After ASP completes its processing in step 3 and the server sends the response in step 4, it moves on to other activities and other clients. The only way the client can recapture the server’s attention is to request another page via the HTTP protocol. In other words, there is no real connection between the client and server. This is a very important concept.

Sometimes developers try to access server-side scripts or objects from the client, or conversely, client-side objects or scripts from the server. For example, consider client-side code that attempts to access one of ASP’s built-in objects, such as the Session object. The attempt is destined for failure, because the code running on the client has no way of accessing an object located on the server. A typical error message might appear as follows:

VBS Script Error: Object Required: Session

Now consider an example in which a server-side script attempts to manipulate a client-side object. Suppose the developer wants to use server-side script to populate a client-side control called ListBox1, using the following instruction:

<% ListBox1.AddItem Value1 %>

The problem is that the HTML page, including the list box, does not yet exist when the server-side code is executed. Therefore, this instruction generates an error.

On the other hand, you can use server-side code for generating client-side code in order to populate a list box. For example, you could create a Window_OnLoad event, which is executed by the browser as soon as the window and its child controls are created. The following code uses server-side script to provide the AddItem method with values stored in the variables Value1, Value2, and Value3.

<SCRIPT LANGUAGE="VBScript">
<!--
Sub Window_OnLoad()
   ListBox1.AddItem "<%= Value1 %>"
   ListBox1.AddItem "<%= Value2 %>"
   ListBox1.AddItem "<%= Value3 %>"
End Sub
-->
</SCRIPT>

Note If you use the HTML <SELECT> tag instead of an ActiveX control, the procedure is slightly more direct. Because a list box created with the <SELECT> tag is based on HTML code, you can use server-side scripting to generate the <OPTION> tags. Since the HTML is self-contained, you do not need to place any code inside a Window_OnLoad event.