Microsurf
By Brian Johnson
Last month, we looked at installing a Web server on your machine to test your applets before deployment. This month, I want to focus on Active Server Pages (ASP), a feature available to users of Microsoft Internet Information Server (IIS) that allows more flexibility when serving your content.
ASP is a server-side scripting feature that can be installed with IIS or with Microsoft's Personal Web Server (PWS). You can get the latest version of these tools by downloading the Windows NT Option Pack from http://backoffice.microsoft.com/downtrial/default.asp. This download includes features that can be installed on Windows NT Server 4.0, Windows NT Workstation 4.0, and Windows 95. If you're using Windows 98, Personal Web Server should be included on your installation CD. If you don't want to upgrade to PWS 4.0 or IIS 4.0, you can download the Active Server Pages component from the site listed above. ASP is also included with Microsoft Visual InterDev.
Once you've installed PWS, you're ready to create scripts that run on your server and generate pages and Web content much like CGI scripts.
Creating an Active Server Page
An Active Server Page is a simple HTML text file that contains a little specialized scripting syntax. Let's start with a basic HTML page in Figure 1. The file is saved with an ASP extension to a directory on your Web server. When you run this file, the outcome is predictable. You get a simple Web page, as shown in Figure 1. To spice things up a little, let's add the VBScript shown in Figure 3. Figure 4 shows the results.
Figure 1: The basic page in Internet Explorer
Figure 2: The Active Server Page with added VBScript in Internet Explorer 4.0
Figure 3: The Active Server Page In Lynx
Figure 4: Netscape Navigator passes the test, but Lynx does not.
Seeing script like this in Internet Explorer probably isn't too exciting; you know you can script all you want to create cool interactive pages. However, let's view the same page in a browser that doesn't support VBScript (see Figure 5). Here you can see that the script is being run on the server and not in the browser.
Figure 5: Both Lynx and Internet Explorer 4.0 pass the test.
To get a further handle on what's happening, look at the displayed page's underlying HTML (see Figure 6). It might not be what you expect: Everything is there, but you don't see any scripting. The script generates the page, so it's invisible to a browser like Lynx.
<HTML><HEAD>
<TITLE>Visual J++ Informant</TITLE>
</HEAD>
<BODY>
<FONT Size=7>Browser Test</FONT><BR>
<HR COLOR=BLUE>
<% Set bt = Server.CreateObject("MSWC.BrowserType") %>
Browser: <%= bt.browser %><BR>
Version: <%= bt.version %><BR>
Tables: <%= bt.tables %> <BR>
The content displayed will be different depending on the
browser used:<BR><BR>
<% If (bt.tables = "True") Then %>
<TABLE BORDER>
<TR><TD>Item 1-1</TD>
<TD>Item 1-2</TD><TD>Item 1-3</TD></TR>
<TR><TD>Item 2-1</TD>
<TD>Item 2-2</TD><TD>Item 2-3</TD></TR>
<TR><TD>Item 3-1</TD>
<TD>Item 3-2</TD><TD>Item 3-3</TD></TR>
</TABLE>
<% Else %>
<BR>Sorry, as far as I can tell, your bowser doesn't
support tables.
<OL>
<li>Item 1-1</li>
<li>Item 1-2</li>
<li>Item 1-3</li>
<li>Item 2-1</li>
<li>Item 2-2</li>
<li>Item 2-3</li>
<li>Item 3-1</li>
<li>Item 3-2</li>
<li>Item 3-3</li>
</OL>
<% End If %>
</BODY></HTML>Figure 6: Checking capabilities using the BrowserType object
The basic difference between the VBScript you create for Internet Explorer and for ASP is the special tag used to enclose the script. It's opened with a left angle bracket (<) followed by a percent sign (%), with a percent sign and a right angle bracket (>) to close. The ASP example we created also uses the ASP output directive:
<% = i %>to display the value of i. The information inside these tags is run through the server; everything else is simply returned to the browser as normal.
I'm not going to get fancy here with posting to scripts through HTML forms; you'll find that in the ASP documentation. What I'd like to do is to show you how you can integrate a little bit of VBScript in an Active Server Page to make serving up the pages that contain your content a little more efficient.
Identify Your Client
There are a couple of different ways to determine whether the browser asking for your page is capable of running your Java applets. After you know what browser you're dealing with, you can modify your content to better serve the person viewing your page.
The first method for determining what a browser can do uses the HTTP_USER_AGENT variable from the ServerVariables collection (see Figure 7). The idea is to create a browser variable, then compare the returned string to browsers on which I've already tested my applet. In this example, the value returned is compared with the HTTP_USER_AGENT values for Microsoft Internet Explorer 4.0 running on Windows 98 and the English version of Netscape Navigator 4.04.
Figure 7: Newer broswers might not be in the browscap.ini file.
You can see the result in Figure 8. Netscape Navigator passes the test, but Lynx does not. Note: This tests only for an exact match; Internet Explorer 4.00 doesn't match, nor does IE 4.02. Running from Windows 95 or Windows NT doesn't match, either.
This doesn't take into account the various subversions of a browser. It also doesn't consider variables such as language. One option is to use a comparison operator to determine if the browser is compatible with a particular version of a browser. The code in Figure 9 does just that. In this case, the test is for Lynx/2.7. You can see in Figure 10 that both Internet Explorer 4.0 and Lynx 2.7 easily pass the test.
Once you know if a browser is up to the version that you need to display your content, you have a couple of choices to serve that content using ASP. First, you can use the #INCLUDE directive to guide the user to the proper page. For example, because Lynx is a character-based browser, you might want to direct the user to a simpler page. The syntax for the #INCLUDE server directive looks like this:
<--#INCLUDE File="filename.htm">If you don't want to create separate pages for each browser type, you can simply include the HTML code for each browser in the script. (I prefer this on smaller sites.) For simple pages, you generally need to simply strip out pictures and tables, keeping essentially the same content that you do for the higher-level browser. Keeping the content in one file saves a step and makes it easier to keep track of all your information.
Another option for determining what a browser can display is by creating a BrowserType object. This object returns the capabilities of a browser based on a file named browscap.ini. Figure 6 uses this object in code. This object can return information on whether a browser supports VBScript, JavaScript, background sounds, tables, and frames. Knowing whether the browser getting your information can display that information correctly can be crucial on sites where you have to make sure the information gets to the user. Figure 7 illustrates sending a table to a browser that supports it. Because Lynx is an unknown, the content is sent as a list.
Because this method is dependent on the browscap.ini file, this file needs to be kept up to date. You can see in Figure 12 that Lynx returns an unknown version and a negative about tables on a browscap.ini file doesn't include information about this browser. For the latest version of the browscap.ini file, check out cyScape at http://www.cyscape.com/asp/browscap/. They make a current version of browscap.ini available for free — and even inform you of updates.
Conclusion
In this article, I've given you enough information about Active Server Pages to make them useful without forcing you to use them to serve all the content on your site. You don't need to use ASP all the time. For those times you need to ensure your message makes it to your viewer, however, Active Server Pages can make life a lot simpler. As you start to learn more about ASP, I'm sure you'll find more and more to like. If you're using IIS to serve your Web pages, you'll find it a powerful tool to have on your workbench.
The files referenced in this article are available for download from the Informant Web site at http://www.informant.com/ji/jinewup.htm. File name: JI9806BJ.ZIP.
Brian Johnson is a freelance writer in Orlando, FL. His most recent book, Microsoft Image Composer for Dummies, will be published this spring by IDG Books Worldwide. You can reach him at brianjay@gate.net or visit his home page at http://www.gate.net/~brianjay.