您现在的位置： 
rface that wraps all the Windows Script interfaces
needed for dialog with a script language parser. It has a Language property through which you select a
language. VBScript and JScript?are the two usual options, but provided you have a compliant parser, any
scripting language is fine. Francesco Balena covered the ScriptControl in detail in the July 1999 issue of
MIND (see "Exploring the Microsoft Script Control"). Tobias Martinsson's article, "Active Scripting with
PerlScript," in the August 1999 issue of MIND, explores the use of Perl with ASP.
When it comes to using the ScriptControl you need to do three things: set up the language, add as many
objects as you want to the script namespace, and execute the script code. In my special edition browser, I
set the language to VBScript during the form load event. At the same time, I create instances of all the
objects I want to be visible to the script engine at runtime. Named items visible to the parser at runtime
is a concept that warrants further explanation. The whole set of named items forms the script's namespace.
A Windows Script parser (such as the Microsoft parser for VBScript) receives a vocabulary of known names
at startup. This dictionary contains the language's keywords and global resources such as variables,
objects, and subroutines. Behind each name (such as MsgBox) there's a programmable entity?whether it is a
parser-specific function or the method of a certain in-process COM object. You can add new names to this
namespace. Better yet, the interface of the ScriptControl (and thereby the Windows Script programming
interface) allows you to do this in a very handy way. Look at the following code snippet: Set
m_objResponse = CreateObject("MyASP.Response")
m_objScriptCtl.AddObject "Response", m_objResponse
Through the AddObject method, the ScriptControl adds a named item called Response to the script namespace.
From then on, it is considered a language item. Each call to this element is automatically routed to the
COM object you specified as the second argument of AddObject. Those two lines are part of the
CAspParser.Initialize method and m_objScriptCtl is the instance of the ScriptControl that is going to be
used for script processing.
Once you execute those lines, any script code you run through that instance of the ScriptControl
recognizes Response as a keyword and uses MyASP.Response to work with it. It's a very common technique in
scripting. Incidentally, this is the same technique that allows IIS to inject the true ASP object model in
the scripting context of a server-side ASP page. This workaround also makes it possible for Windows Script
Host (WSH) scripts to rely on a system-provided WScript object.
Call in Action
When the browser's main form is ready to parse and display the ASP code, it calls the ParseTextToFile
method, which takes two file names: the source ASP file and the target HTML file. When the method returns
successfully, the form simply navigates to the newly created local HTML page. The full source code of the
CAspParser class is shown in Figure 4. Let's see how it works step by step on a very simple ASP page:
<html>
<body>
<% X=1 %>
<% Response.Write "Hello, world!" %>
<hr>
The value of X is <%= X%>
</body>
</html>
The CAspParser class initializes the script control by setting the script language to VBScript (this is
not strictly necessary since the ScriptControl already defaults to it), and adding a brand new instance of
the MyASP.Response object to the namespace. The control then passes to the method ParseTextToFile. It
receives the name of the ASP file, verifies it has an ASP extension, and reads in all of its content. I
used the Scripting.FileSystemObject for clarity only (see Figure 4). Using the CreateFile API or other I/O
technique could give you better performance.
The string with all the ASP content is then parsed for <%…%> blocks. All the text outside of these
markers is written to the Response object. It accumulates the text into an internal string buffer that
emulates the stream where the real ASP Response object writes. In this way, the simulated Response object
caches all the output, just as the real ASP Response does when buffering is on. Note that under IIS 5.0
buffering is on by default, while it was turned off by default in earlier versions of IIS.
In Figure 4, the Response.Clear method is used to clear any buffered text that you accumulated through
repeated calls to Response.Write. This Clear method plays exactly the same role it does in the real ASP
object model you're used to on the server.
Now let's have a closer look at the implementation of the simulated ASP Response object. To further
illustrate the language neutrality of COM and to avoid the problem of writing objects in Visual Basic with
the same method names as some language keywords (such as Write or End), I decided to write the MyASP
objects using ATL and Visual C++? The implementation of the MyASP.Response object is straightforward (see
Figure 5). The MyASP objects need to expose methods with signatures that match the way you're using them
in your client-side ASP pages. If you're using the client-side ASP engine to work on specific client-only
pages, then there's no particular reason for you to use a custom object that mimics the ASP's Response.
You are better off writing a completely custom object with the programming interface you prefer. The need
to mimic the signatures of ASP intrinsic objects arises when you're writing dual pages to be used on the
Web as well as locally on a CD.
When you invoke the Write method on MyASP.Response, the text you pass in is added to an internal member
variable that's ready for return to the caller. This behavior mimics exactly what the ASP Response object
does internally when buffering is on. The Clear method empties the buffer. MyASP also implements a
property called ResponseBuffer that returns the current content of the output buffer. This property works
in much the same way as the ASP Flush method. Each time you read it, its contents are cleared. IIS itself
manages to send the transformed text to the browser via HTTP. Consequently, there's no need to make the
internal buffer available to the scripts in the ASP page. In fact, the ASP Response object doesn't have a
method or property (such as ResponseBuffer) that returns the text accumulated in the internal buffer. In
this client-side emulation, the browser needs to get the transformed text from the object, and a property
is more helpful than a subroutine like Flush.
Finally, the End method sets an internal variable to false. This variable is exposed through the
CanContinue property and is used to stop the loop that governs the parsing of the ASP text. As you can
see, the programming interface of the MyASP.Response object is similar?but not identical to?the ASP
Response object. The logic behind the two objects is shared to some extent, but it clearly differs as the
working context of the client and server-side editions of Response requires.
In Figure 6 you can see that both the custom browser and Internet Explorer render my simple page in the
same way. If you open Explorer in the folder that contains the specified ASP page and double-click the
item, in most cases Visual InterDev?will open because it is the program that is usually registered to edit
ASP files. If you want to be able to double-click on ASP files and see their content, you could associate
them with a program like Visual InterDev. However, remember that a generic ASP page might be using objects
like Session or Application that the client-side parser doesn't support.
Figure 6 The Custom Browser versus Internet Explorer
Consider a page like the following, which is nearly identical to the previous one except for a
Response.End statement. <html>
<body>
<% x=1 %>
<% Response.Write "Hello, world!" %>
<hr>
<% Response.End %>
The value of X is <%= x%>
</body>
</html>
Figure 7 shows that the End method correctly stops the processing. If you're confused by the truncated
output in the HTML textbox, don't be too concerned. Try viewing the same document through Internet
Explorer and HTTP and you'll see that the HTML the browser receives from the Web server is exactly the
same.
Figure 7 Using Response.End
A possible stumbling block in the conversion process is the meaning of the = sign which is often used
within <%...%> code blocks to denote Response.Write. In fact, The value of X is <%= x%>
is exactly the same as The value of X is <% Response.Write x %>
To deal with this particular situation (and other similar circumstances) I've added the ResolveAmbiguity
method to the CAspParser class. Each time that the script command begins with "=" it replaces the
character with a Response.Write.
A More Complicated Page
So far I've worked with a very simple ASP page. Let's use the client-side parser to work with a more
complex ASP page that involves databases. Figure 8 shows an ASP page that fills and displays a table with
a few records taken from an OLE DB data source. Despite the use of ActiveX Data Objects (ADO), the
structure of the page is relatively simple. To make this example more realistic I would need to implement
the Request object and the simulation of the POST and the GET HTTP commands. I'll cover
needed for dialog with a script language parser. It has a Language property through which you select a
language. VBScript and JScript?are the two usual options, but provided you have a compliant parser, any
scripting language is fine. Francesco Balena covered the ScriptControl in detail in the July 1999 issue of
MIND (see "Exploring the Microsoft Script Control"). Tobias Martinsson's article, "Active Scripting with
PerlScript," in the August 1999 issue of MIND, explores the use of Perl with ASP.
When it comes to using the ScriptControl you need to do three things: set up the language, add as many
objects as you want to the script namespace, and execute the script code. In my special edition browser, I
set the language to VBScript during the form load event. At the same time, I create instances of all the
objects I want to be visible to the script engine at runtime. Named items visible to the parser at runtime
is a concept that warrants further explanation. The whole set of named items forms the script's namespace.
A Windows Script parser (such as the Microsoft parser for VBScript) receives a vocabulary of known names
at startup. This dictionary contains the language's keywords and global resources such as variables,
objects, and subroutines. Behind each name (such as MsgBox) there's a programmable entity?whether it is a
parser-specific function or the method of a certain in-process COM object. You can add new names to this
namespace. Better yet, the interface of the ScriptControl (and thereby the Windows Script programming
interface) allows you to do this in a very handy way. Look at the following code snippet: Set
m_objResponse = CreateObject("MyASP.Response")
m_objScriptCtl.AddObject "Response", m_objResponse
Through the AddObject method, the ScriptControl adds a named item called Response to the script namespace.
From then on, it is considered a language item. Each call to this element is automatically routed to the
COM object you specified as the second argument of AddObject. Those two lines are part of the
CAspParser.Initialize method and m_objScriptCtl is the instance of the ScriptControl that is going to be
used for script processing.
Once you execute those lines, any script code you run through that instance of the ScriptControl
recognizes Response as a keyword and uses MyASP.Response to work with it. It's a very common technique in
scripting. Incidentally, this is the same technique that allows IIS to inject the true ASP object model in
the scripting context of a server-side ASP page. This workaround also makes it possible for Windows Script
Host (WSH) scripts to rely on a system-provided WScript object.
Call in Action
When the browser's main form is ready to parse and display the ASP code, it calls the ParseTextToFile
method, which takes two file names: the source ASP file and the target HTML file. When the method returns
successfully, the form simply navigates to the newly created local HTML page. The full source code of the
CAspParser class is shown in Figure 4. Let's see how it works step by step on a very simple ASP page:
<html>
<body>
<% X=1 %>
<% Response.Write "Hello, world!" %>
<hr>
The value of X is <%= X%>
</body>
</html>
The CAspParser class initializes the script control by setting the script language to VBScript (this is
not strictly necessary since the ScriptControl already defaults to it), and adding a brand new instance of
the MyASP.Response object to the namespace. The control then passes to the method ParseTextToFile. It
receives the name of the ASP file, verifies it has an ASP extension, and reads in all of its content. I
used the Scripting.FileSystemObject for clarity only (see Figure 4). Using the CreateFile API or other I/O
technique could give you better performance.
The string with all the ASP content is then parsed for <%…%> blocks. All the text outside of these
markers is written to the Response object. It accumulates the text into an internal string buffer that
emulates the stream where the real ASP Response object writes. In this way, the simulated Response object
caches all the output, just as the real ASP Response does when buffering is on. Note that under IIS 5.0
buffering is on by default, while it was turned off by default in earlier versions of IIS.
In Figure 4, the Response.Clear method is used to clear any buffered text that you accumulated through
repeated calls to Response.Write. This Clear method plays exactly the same role it does in the real ASP
object model you're used to on the server.
Now let's have a closer look at the implementation of the simulated ASP Response object. To further
illustrate the language neutrality of COM and to avoid the problem of writing objects in Visual Basic with
the same method names as some language keywords (such as Write or End), I decided to write the MyASP
objects using ATL and Visual C++? The implementation of the MyASP.Response object is straightforward (see
Figure 5). The MyASP objects need to expose methods with signatures that match the way you're using them
in your client-side ASP pages. If you're using the client-side ASP engine to work on specific client-only
pages, then there's no particular reason for you to use a custom object that mimics the ASP's Response.
You are better off writing a completely custom object with the programming interface you prefer. The need
to mimic the signatures of ASP intrinsic objects arises when you're writing dual pages to be used on the
Web as well as locally on a CD.
When you invoke the Write method on MyASP.Response, the text you pass in is added to an internal member
variable that's ready for return to the caller. This behavior mimics exactly what the ASP Response object
does internally when buffering is on. The Clear method empties the buffer. MyASP also implements a
property called ResponseBuffer that returns the current content of the output buffer. This property works
in much the same way as the ASP Flush method. Each time you read it, its contents are cleared. IIS itself
manages to send the transformed text to the browser via HTTP. Consequently, there's no need to make the
internal buffer available to the scripts in the ASP page. In fact, the ASP Response object doesn't have a
method or property (such as ResponseBuffer) that returns the text accumulated in the internal buffer. In
this client-side emulation, the browser needs to get the transformed text from the object, and a property
is more helpful than a subroutine like Flush.
Finally, the End method sets an internal variable to false. This variable is exposed through the
CanContinue property and is used to stop the loop that governs the parsing of the ASP text. As you can
see, the programming interface of the MyASP.Response object is similar?but not identical to?the ASP
Response object. The logic behind the two objects is shared to some extent, but it clearly differs as the
working context of the client and server-side editions of Response requires.
In Figure 6 you can see that both the custom browser and Internet Explorer render my simple page in the
same way. If you open Explorer in the folder that contains the specified ASP page and double-click the
item, in most cases Visual InterDev?will open because it is the program that is usually registered to edit
ASP files. If you want to be able to double-click on ASP files and see their content, you could associate
them with a program like Visual InterDev. However, remember that a generic ASP page might be using objects
like Session or Application that the client-side parser doesn't support.
Figure 6 The Custom Browser versus Internet Explorer
Consider a page like the following, which is nearly identical to the previous one except for a
Response.End statement. <html>
<body>
<% x=1 %>
<% Response.Write "Hello, world!" %>
<hr>
<% Response.End %>
The value of X is <%= x%>
</body>
</html>
Figure 7 shows that the End method correctly stops the processing. If you're confused by the truncated
output in the HTML textbox, don't be too concerned. Try viewing the same document through Internet
Explorer and HTTP and you'll see that the HTML the browser receives from the Web server is exactly the
same.
Figure 7 Using Response.End
A possible stumbling block in the conversion process is the meaning of the = sign which is often used
within <%...%> code blocks to denote Response.Write. In fact, The value of X is <%= x%>
is exactly the same as The value of X is <% Response.Write x %>
To deal with this particular situation (and other similar circumstances) I've added the ResolveAmbiguity
method to the CAspParser class. Each time that the script command begins with "=" it replaces the
character with a Response.Write.
A More Complicated Page
So far I've worked with a very simple ASP page. Let's use the client-side parser to work with a more
complex ASP page that involves databases. Figure 8 shows an ASP page that fills and displays a table with
a few records taken from an OLE DB data source. Despite the use of ActiveX Data Objects (ADO), the
structure of the page is relatively simple. To make this example more realistic I would need to implement
the Request object and the simulation of the POST and the GET HTTP commands. I'll cover
