|
The Execute method provides ASP developers an excellent opportunity
to break up their applications into manageable, reusable components
of code that can be called only when necessary. In the past, an ASP
developer was forced to either programmatically redirect the
execution of a page to another page (a costly exercise in execution
speed, since it required that a header be sent to the browser to
redirect the browser's request) or include another file using
the #INCLUDE pre-processor directive. Neither
alternative was very useful. As previously mentioned, the Redirect
method of the Server object (see later in this chapter) calls for
another server-to-client-server round of calls for a page that was
slow. The #INCLUDE directive forces the ASP ISAPI
filter to retrieve the included file from the file system, insert it
into the current script, and interpret all the included code even if
it is never used by the including script.
The Execute method, on the other hand, allows you to execute other
scripts programmatically only when the logic in the calling script
requires it. That is, the Execute method allows you to dynamically
include scripts.
Note that just as with other scripts, scripts called through the
Execute method can add or modify HTTP headers included in the
response. However, just as with standalone scripts, if the called
script adds or modifies any HTTP headers after any response is sent,
an error will be generated.
As you might expect, the variable scope for each script (calling
script and called script) is distinct. For example, in the following
code, you have a variable called strName in both
scripts.
CALLING SCRIPT
<%
Dim strName
strName = "Sam"
Server.Execute("CalledScript.asp")
%>
CalledScript.asp
<%
Dim strName
Response.Write strName
%>
In the preceding example, strName is
declared in both scripts. However, it is not initialized in the
second script. In this example, Response.Write would result in
nothing being written to the Response, as the value of
strName in the called script is undefined.
When an ASP page calls Server.Execute to branch to another ASP page,
all of the former's built-in ASP objects are passed to the
called script. For example, any values in the Request object's
Form collection are available to the ASP page invoked by the call to
the Server object's Execute method.
Note that according to the Microsoft documentation, the Execute
method will allow you to add a QueryString parameter to the end of the
called URL. However, as of the writing of this addition of this book
(March 2000), adding a QueryString to a URL will generate an error.
According to Microsoft Technical Support, this is a known bug in IIS
5.0 and a fix is in development.
Finally, if you call a script using the Execute method from within a
script that you have set to transactional and the called script
causes the transaction to be aborted, the OnTransactionAbort event on
the called page will be called first and then, after the called
script has completed execution, the OnTransactionAbort event on the
calling page is executed. For example, suppose the following script,
CallingScript.ASP, calls the
CalledScript.ASP script further.
CALLINGSCRIPT.ASP
<%@ TRANSACTION=Required%>
<%
Server.Execute "CalledScript.asp?strName=bob"
Sub OnTransactionAbort( )
'Clean up code for CallingScript.asp.
End Sub
Sub OnTransactionCommit( )
Commit code for CalledScript.asp.
End Sub
CALLEDSCRIPT.ASP
<%@ TRANSACTION=Required%>
<%
.
.
.
'Processing code....
.
.
.
OnTransactionAbort( )
'Clean up code for CalledScript.asp.
End Sub
OnTransactionCommit( )
Commit code for CalledScript.asp.
End Sub
If in CalledScript.ASP script, an error occurs
that forces the transaction to abort, then the OnTransactionAbort
event code for CalledScript.ASP would be
executed and then the OnTransactionAbort event code for
CallingScript.ASP would be executed.
|