您现在的位置： 
those topics next
month.
Figure 9 The Page Rendered in Internet Explorer
In Figure 9 you can see how Internet Explorer renders this page. Figure 10 shows that the offline parser
renders it the same way.
Figure 10 The Page Rendered in the ASP Browser
Let's go back to the page in Figure 8, which imports a Cascading Style Sheets (CSS) file: <link
rel="stylesheet" href="tablestyles.css">
The file name is not a URL and does not contain path information. This means that both IIS and the ASP
offline browser will look for it in the current folder, where the hosting ASP page resides. You can also
specify a fully qualified path name for the CSS and it will work fine as well. What happens if the page
contains hyperlinks? If the anchor tag points to an existing absolute URL, then everything will work
normally as the browsing engine simply navigates to the specified location. If the hyperlink refers to a
relative URL that does not contain the protocol and Web server name, such as <a href="seminars.htm">Click
here</a>
then two things happen. First, the browser attempts to locate the specified page in the current location.
If the page with the link is c:pagesfoo.asp, then seminars.htm is assumed to be in c:pages. An HTTP 404
error is returned if it isn't there.
Finding the page, however, doesn't mean that the browser knows how to handle it. The browser certainly
knows how to handle .css, .htm, .js, or .vbs files. But when the linked page has an ASP extension, the
scenario suddenly changes. <a href="seminars.asp">Click here</a>
The browser completes the name of the referenced file with the current path name. If you're clicking from
http://server/ pages/foo.asp then the browser attempts to navigate to http://server/pages/seminars.asp. In
an offline scenario, though, you're clicking from something like c:pagesfoo.asp, therefore the absolute
page will be c:pagesseminars.asp. If you try to type this path name in the address bar of Internet
Explorer, a dialog will promptly ask you whether you want to download the file or open it from its current
location. (A similar dialog box also appears with Netscape and other browsers.)
The key point is that the browser doesn't know how to cope with an ASP page without the help of an ASP-
enabled Web server. No browser includes a client-side runtime engine capable of parsing and expanding ASP
pages like I'm building here. Figure 11 explains the typical browser's schema for navigation. While the
schema has been drawn with Internet Explorer in mind, it is general enough to be extended to all browsers.
There are at least three ways a user can ask the browser to move to a URL: from the address bar, through
page links, or via scripting. In all cases, the request is queued to an internal module that prepares the
actual HTTP request for the Web server or manages to do otherwise for local files. When you ask the
browser to navigate to a local ASP page, there's nothing predefined this module can do. Win32?based
browsers usually look in the registry for the application registered to open ASP files. Often this
application is Visual InterDev.
Figure 11 Web Browser Navigation
To follow a link to an ASP page in a client-side ASP environment, you need a customized browser. The ASP
browser utilizes the WebBrowser control to display the page. The component traps all clicks on hyperlink
tags and processes them the usual way, through the Internet Explorer standard navigation module. You need
to prevent the standard browser's engine from getting involved when the user wants to follow a link to a
relative ASP page. The WebBrowser control raises an event, BeforeNavigate2, each time it is about to
navigate to another URL. This event accepts a Boolean return value that you can set to True if you want to
prevent the default operation from taking place. Figure 12 shows how to write the code that redirects any
link to a local ASP page. LocalNavigate is the same subroutine that gets called when you click on the Go
button. Figure 13 shows that the hyperlink works.
Figure 13 Redirecting to ASP in Action
Note that for completeness you should also implement your own history mechanism. The standard one won't
work because the browser doesn't know how to move back and forth between local ASP pages. To create a
custom history mechanism you can use a special system folder for persistence and a collection to keep
information in memory.
Conclusion
You can use the Microsoft ScriptControl to execute any VBScript or JScript code block, and to populate the
scripting context with custom objects. This way, you can emulate all the ASP intrinsic objects and add new
ones as well. A browser that can handle client-side ASP pages must behave in slightly different ways than
regular Web browsers. This is particularly true of hyperlinks, navigation, and forms. In this column, I
added client-side support only for the ASP's Response object. Next month, I'll cover the Request object
and form management. Stay tuned.
month.
Figure 9 The Page Rendered in Internet Explorer
In Figure 9 you can see how Internet Explorer renders this page. Figure 10 shows that the offline parser
renders it the same way.
Figure 10 The Page Rendered in the ASP Browser
Let's go back to the page in Figure 8, which imports a Cascading Style Sheets (CSS) file: <link
rel="stylesheet" href="tablestyles.css">
The file name is not a URL and does not contain path information. This means that both IIS and the ASP
offline browser will look for it in the current folder, where the hosting ASP page resides. You can also
specify a fully qualified path name for the CSS and it will work fine as well. What happens if the page
contains hyperlinks? If the anchor tag points to an existing absolute URL, then everything will work
normally as the browsing engine simply navigates to the specified location. If the hyperlink refers to a
relative URL that does not contain the protocol and Web server name, such as <a href="seminars.htm">Click
here</a>
then two things happen. First, the browser attempts to locate the specified page in the current location.
If the page with the link is c:pagesfoo.asp, then seminars.htm is assumed to be in c:pages. An HTTP 404
error is returned if it isn't there.
Finding the page, however, doesn't mean that the browser knows how to handle it. The browser certainly
knows how to handle .css, .htm, .js, or .vbs files. But when the linked page has an ASP extension, the
scenario suddenly changes. <a href="seminars.asp">Click here</a>
The browser completes the name of the referenced file with the current path name. If you're clicking from
http://server/ pages/foo.asp then the browser attempts to navigate to http://server/pages/seminars.asp. In
an offline scenario, though, you're clicking from something like c:pagesfoo.asp, therefore the absolute
page will be c:pagesseminars.asp. If you try to type this path name in the address bar of Internet
Explorer, a dialog will promptly ask you whether you want to download the file or open it from its current
location. (A similar dialog box also appears with Netscape and other browsers.)
The key point is that the browser doesn't know how to cope with an ASP page without the help of an ASP-
enabled Web server. No browser includes a client-side runtime engine capable of parsing and expanding ASP
pages like I'm building here. Figure 11 explains the typical browser's schema for navigation. While the
schema has been drawn with Internet Explorer in mind, it is general enough to be extended to all browsers.
There are at least three ways a user can ask the browser to move to a URL: from the address bar, through
page links, or via scripting. In all cases, the request is queued to an internal module that prepares the
actual HTTP request for the Web server or manages to do otherwise for local files. When you ask the
browser to navigate to a local ASP page, there's nothing predefined this module can do. Win32?based
browsers usually look in the registry for the application registered to open ASP files. Often this
application is Visual InterDev.
Figure 11 Web Browser Navigation
To follow a link to an ASP page in a client-side ASP environment, you need a customized browser. The ASP
browser utilizes the WebBrowser control to display the page. The component traps all clicks on hyperlink
tags and processes them the usual way, through the Internet Explorer standard navigation module. You need
to prevent the standard browser's engine from getting involved when the user wants to follow a link to a
relative ASP page. The WebBrowser control raises an event, BeforeNavigate2, each time it is about to
navigate to another URL. This event accepts a Boolean return value that you can set to True if you want to
prevent the default operation from taking place. Figure 12 shows how to write the code that redirects any
link to a local ASP page. LocalNavigate is the same subroutine that gets called when you click on the Go
button. Figure 13 shows that the hyperlink works.
Figure 13 Redirecting to ASP in Action
Note that for completeness you should also implement your own history mechanism. The standard one won't
work because the browser doesn't know how to move back and forth between local ASP pages. To create a
custom history mechanism you can use a special system folder for persistence and a collection to keep
information in memory.
Conclusion
You can use the Microsoft ScriptControl to execute any VBScript or JScript code block, and to populate the
scripting context with custom objects. This way, you can emulate all the ASP intrinsic objects and add new
ones as well. A browser that can handle client-side ASP pages must behave in slightly different ways than
regular Web browsers. This is particularly true of hyperlinks, navigation, and forms. In this column, I
added client-side support only for the ASP's Response object. Next month, I'll cover the Request object
and form management. Stay tuned.
