您现在的位置： 
Cutting Edge A Client-side Environment for ASP Pages
这是一个由微软提供的功能强大的ASP-HTML转换工具.它将常用的ASP脚本转换为HTML从而减轻服务器的负担
下面是官方的英文原版介绍资料
ASP is a Web technology that relies specifically on capabilities of Microsoft?Internet Information
Services (IIS). For this reason, very few commercial products have attempted to provide an ASP-to-HTML
converter. The problem with such converters is that you must work in conjunction with the Web server to
trigger the ASP parser and find the intrinsic objects available. When you double-click on an HTML page
from the Explorer shell, you simply ask the browser to retrieve and render the source code of the file.
However, when you double-click on an ASP file from Explorer, you cannot ask the browser to translate it
into HTML.
Practical Reasons for an ASP Converter
OK, so an ASP-to-HTML converter might not be the tool that thousands of programmers dream of every night.
However, I can envision at least a couple of scenarios where such a tool would be very handy. The first
scenario was mentioned by Robert Hess in the April 2000 Web Q&A column. Suppose you have several pages
that require some interaction with a database on a frequently visited Web site. Writing them as ASP pages
looks like the perfect solution. However, if the database is not very volatile and the page output is not
highly dependent on the user's input, you could easily resort to plain old HTML for better performance.
For example, a list of suppliers is probably the kind of data that you would update only a few times a
year. Why rebuild that list on the fly each time it's requested, when a static HTML page would incur less
overhead?
An ASP-to-HTML tool could be used as a kind of batch compiler for ASP pages. You write them as server-side
resources, and then when you realize they are not particularly dependent on runtime conditions, you can
transform them into static HTML pages with either the .asp or .htm(1) extension.
While I'm on the subject, let me point out a significant improvement in the management of scriptless ASP
pages that's available with IIS 5.0. Until IIS 4.0, all resources with a .asp extension were subject to
parsing, whether or not they contained script code. With IIS 5.0 this drawback has been eliminated as IIS
checks for <%...%> blocks before loading the ASP parser.
An ASP-to-HTML converter would also be handy when you need to view ASP pages offline. For example, a
client recently asked me about the possibility of using a single development environment for building both
Web sites and CDs. I first considered using static HTML pages that could be viewed over the Web or in a
local browser, but the idea was soon dismissed given the complexity and the amount of content involved.
Also, my client could not guarantee any particular software configuration on the user's machine, and the
only product that could be supplied with the CDs was Microsoft Internet Explorer or a custom Web browser.
ASP looked like the natural choice for the Web side of the project, but what about the CD? To make ASP
work offline without a Web server, you need code that extracts all the <%…%> code blocks from the page
and processes them. In addition, this module would have to provide a simulated ASP object model and take
care of collecting the portions of plain HTML text. Then it would have to put it all together, combining
the static HTML code with the output of the processed scripts.
In this column, I will discuss the architecture of the offline ASP viewer and some implementation details.
In particular, I'll show you how to emulate the behavior of the ASP Response object. Next month, I'll
finish up the code, covering Request and Server plus some other related topics. This month's code shows
the potential of this approach and works with typical ASP pages, though it is not comprehensive. I won't
cover other ASP objects such as Session or Application because they are rarely needed in local scenarios.
The Browser's Role
To emulate ASP while working offline, you need a little help from the browser. Basically, the browser must
be able to detect whether the page to which it's about to navigate is a URL or a local path name and
whether it contains the .asp extension. If the user is calling a URL, the browser does what it would
normally do. Otherwise, it calls a custom module to locally parse the content of the ASP file.
Furthermore, the browser is involved when the ASP page that will be emulated contains forms and
hyperlinks. (I'll discuss this further next month.) Given these requirements, to deal with ASP pages
offline you need a customized version of the browser. While subclassing Internet Explorer or Netscape
Communicator is always possible, I suggest you write a brand new browser from scratch using existing Web
browser technology such as the Microsoft WebBrowser control. While I'll use Visual Basic?here, you can
also use C++. As a good starting point in C++, you can try the MFCIE or ATLBrowser samples, both of which
come with the latest Platform SDK. In Figure 1 you can see the layout of the browser. For illustration,
I've divided the client area into three blocks: one for the actual HTML rendering, one for the original
ASP text, and one for the expanded HTML text. Figure 2 shows the code for the browser.
Figure 1 The Custom ASP Browser
During the form's initialization, a new CAspParser object is created and set to work properly. Once you've
clicked the Go button, the browser detects whether you're calling the ASP page locally or over HTTP, and
acts accordingly. All the logic is hidden in the CAspParser class, which exposes three public functions:
Initialize, SetScriptControl, and ParseTextToFile. Initialize makes sure the scripting environment is
properly initialized and ready to work. Through SetScriptControl, the class receives the working instance
of the script environment (more on this later). ParseTextToFile parses the content of the given ASP file
and creates an output stream. Basically, the parser reads the whole content of the ASP file into memory
and then walks through it. It locates any occurrence of "<%", then copies the text that precedes "<%" to
the output buffer, and starts a new search for the closing tag, "%>". The command text is extracted and
processed separately. Any output is then appended to the response buffer.
The script code in the body of an ASP page may contain references to the intrinsic objects that form the
ASP object model. These well-known objects are listed in Figure 3. IIS is responsible for making these
objects?plus two more: ASPError and ObjectContext?available in the script's namespace when the parser is
about to process the content of the various code blocks. To obtain an ASP parser that works outside the
Web server, you should provide a replacement for these objects, which means building a client-side ASP
object model.
A Client-side ASP Object Model
One of the problems with Web applications is the inability to maintain state when working over HTTP. State
is the ability to associate variables and objects with a particular user. A tool to store individual
settings and resources can solve the problem. This is what the Session and Application objects provide,
albeit at different levels. But you don't always need to implement this feature in a client-side ASP
object model. In fact, a local ASP page is normally accessed by one user at a time and state management is
a far less important issue.
From the perspective of an offline ASP viewer, the key ASP objects are Response and Request because they
provide the basic functionality that make a page interact with the rest of the world. Whether you need to
implement all or a part of the standard methods and properties depends on your particular project.
Although ASP is tightly integrated with IIS and Microsoft Transaction Services (MTS), and COM+
environments, this doesn't mean that you cannot use a unified, yet ASP-based approach for the concurrent
development of products that deliver content through different media (like the Web and CDs). Offline pages
consumed without the intervention of the Web server are normally much simpler and don't need all the
features of an online Web application. Based on my personal experience, I suggest you implement a minimal
set of features (similar to those I discuss here) and then extend the set when your pages need to support
extra ASP features.
I deployed the first version of my project with only Response and Request objects. In particular, I only
implemented the Write method of the Response object, and just for the HTML content type. Request only
exposed the QueryString collection. In a second step, I added support for Response.End and the Request's
Form and ServerVariables collections. Later, I also added some special features such as new environment
variables and new offline-only objects, including Scripting.FileSystemObject.
The key questions concern how you simulate the Response or Request object and how you run all the script
code that an ASP file contains. To execute script code, you can either take advantage of the Microsoft
Script Control?a downloadable component (see http://msdn.microsoft.com/scripting/), or use the raw
Windows Script COM interfaces. For a primer, look at the Extreme C++ column in the August 1997 issue of
Microsoft Internet Developer. Since I'm developing an application in Visual Basic, using the Script
Control is the natural choice.
The Script Control
ScriptControl is an ActiveX?control without a user inte
这是一个由微软提供的功能强大的ASP-HTML转换工具.它将常用的ASP脚本转换为HTML从而减轻服务器的负担
下面是官方的英文原版介绍资料
ASP is a Web technology that relies specifically on capabilities of Microsoft?Internet Information
Services (IIS). For this reason, very few commercial products have attempted to provide an ASP-to-HTML
converter. The problem with such converters is that you must work in conjunction with the Web server to
trigger the ASP parser and find the intrinsic objects available. When you double-click on an HTML page
from the Explorer shell, you simply ask the browser to retrieve and render the source code of the file.
However, when you double-click on an ASP file from Explorer, you cannot ask the browser to translate it
into HTML.
Practical Reasons for an ASP Converter
OK, so an ASP-to-HTML converter might not be the tool that thousands of programmers dream of every night.
However, I can envision at least a couple of scenarios where such a tool would be very handy. The first
scenario was mentioned by Robert Hess in the April 2000 Web Q&A column. Suppose you have several pages
that require some interaction with a database on a frequently visited Web site. Writing them as ASP pages
looks like the perfect solution. However, if the database is not very volatile and the page output is not
highly dependent on the user's input, you could easily resort to plain old HTML for better performance.
For example, a list of suppliers is probably the kind of data that you would update only a few times a
year. Why rebuild that list on the fly each time it's requested, when a static HTML page would incur less
overhead?
An ASP-to-HTML tool could be used as a kind of batch compiler for ASP pages. You write them as server-side
resources, and then when you realize they are not particularly dependent on runtime conditions, you can
transform them into static HTML pages with either the .asp or .htm(1) extension.
While I'm on the subject, let me point out a significant improvement in the management of scriptless ASP
pages that's available with IIS 5.0. Until IIS 4.0, all resources with a .asp extension were subject to
parsing, whether or not they contained script code. With IIS 5.0 this drawback has been eliminated as IIS
checks for <%...%> blocks before loading the ASP parser.
An ASP-to-HTML converter would also be handy when you need to view ASP pages offline. For example, a
client recently asked me about the possibility of using a single development environment for building both
Web sites and CDs. I first considered using static HTML pages that could be viewed over the Web or in a
local browser, but the idea was soon dismissed given the complexity and the amount of content involved.
Also, my client could not guarantee any particular software configuration on the user's machine, and the
only product that could be supplied with the CDs was Microsoft Internet Explorer or a custom Web browser.
ASP looked like the natural choice for the Web side of the project, but what about the CD? To make ASP
work offline without a Web server, you need code that extracts all the <%…%> code blocks from the page
and processes them. In addition, this module would have to provide a simulated ASP object model and take
care of collecting the portions of plain HTML text. Then it would have to put it all together, combining
the static HTML code with the output of the processed scripts.
In this column, I will discuss the architecture of the offline ASP viewer and some implementation details.
In particular, I'll show you how to emulate the behavior of the ASP Response object. Next month, I'll
finish up the code, covering Request and Server plus some other related topics. This month's code shows
the potential of this approach and works with typical ASP pages, though it is not comprehensive. I won't
cover other ASP objects such as Session or Application because they are rarely needed in local scenarios.
The Browser's Role
To emulate ASP while working offline, you need a little help from the browser. Basically, the browser must
be able to detect whether the page to which it's about to navigate is a URL or a local path name and
whether it contains the .asp extension. If the user is calling a URL, the browser does what it would
normally do. Otherwise, it calls a custom module to locally parse the content of the ASP file.
Furthermore, the browser is involved when the ASP page that will be emulated contains forms and
hyperlinks. (I'll discuss this further next month.) Given these requirements, to deal with ASP pages
offline you need a customized version of the browser. While subclassing Internet Explorer or Netscape
Communicator is always possible, I suggest you write a brand new browser from scratch using existing Web
browser technology such as the Microsoft WebBrowser control. While I'll use Visual Basic?here, you can
also use C++. As a good starting point in C++, you can try the MFCIE or ATLBrowser samples, both of which
come with the latest Platform SDK. In Figure 1 you can see the layout of the browser. For illustration,
I've divided the client area into three blocks: one for the actual HTML rendering, one for the original
ASP text, and one for the expanded HTML text. Figure 2 shows the code for the browser.
Figure 1 The Custom ASP Browser
During the form's initialization, a new CAspParser object is created and set to work properly. Once you've
clicked the Go button, the browser detects whether you're calling the ASP page locally or over HTTP, and
acts accordingly. All the logic is hidden in the CAspParser class, which exposes three public functions:
Initialize, SetScriptControl, and ParseTextToFile. Initialize makes sure the scripting environment is
properly initialized and ready to work. Through SetScriptControl, the class receives the working instance
of the script environment (more on this later). ParseTextToFile parses the content of the given ASP file
and creates an output stream. Basically, the parser reads the whole content of the ASP file into memory
and then walks through it. It locates any occurrence of "<%", then copies the text that precedes "<%" to
the output buffer, and starts a new search for the closing tag, "%>". The command text is extracted and
processed separately. Any output is then appended to the response buffer.
The script code in the body of an ASP page may contain references to the intrinsic objects that form the
ASP object model. These well-known objects are listed in Figure 3. IIS is responsible for making these
objects?plus two more: ASPError and ObjectContext?available in the script's namespace when the parser is
about to process the content of the various code blocks. To obtain an ASP parser that works outside the
Web server, you should provide a replacement for these objects, which means building a client-side ASP
object model.
A Client-side ASP Object Model
One of the problems with Web applications is the inability to maintain state when working over HTTP. State
is the ability to associate variables and objects with a particular user. A tool to store individual
settings and resources can solve the problem. This is what the Session and Application objects provide,
albeit at different levels. But you don't always need to implement this feature in a client-side ASP
object model. In fact, a local ASP page is normally accessed by one user at a time and state management is
a far less important issue.
From the perspective of an offline ASP viewer, the key ASP objects are Response and Request because they
provide the basic functionality that make a page interact with the rest of the world. Whether you need to
implement all or a part of the standard methods and properties depends on your particular project.
Although ASP is tightly integrated with IIS and Microsoft Transaction Services (MTS), and COM+
environments, this doesn't mean that you cannot use a unified, yet ASP-based approach for the concurrent
development of products that deliver content through different media (like the Web and CDs). Offline pages
consumed without the intervention of the Web server are normally much simpler and don't need all the
features of an online Web application. Based on my personal experience, I suggest you implement a minimal
set of features (similar to those I discuss here) and then extend the set when your pages need to support
extra ASP features.
I deployed the first version of my project with only Response and Request objects. In particular, I only
implemented the Write method of the Response object, and just for the HTML content type. Request only
exposed the QueryString collection. In a second step, I added support for Response.End and the Request's
Form and ServerVariables collections. Later, I also added some special features such as new environment
variables and new offline-only objects, including Scripting.FileSystemObject.
The key questions concern how you simulate the Response or Request object and how you run all the script
code that an ASP file contains. To execute script code, you can either take advantage of the Microsoft
Script Control?a downloadable component (see http://msdn.microsoft.com/scripting/), or use the raw
Windows Script COM interfaces. For a primer, look at the Extreme C++ column in the August 1997 issue of
Microsoft Internet Developer. Since I'm developing an application in Visual Basic, using the Script
Control is the natural choice.
The Script Control
ScriptControl is an ActiveX?control without a user inte
