[ Go to July 1997 Table of Contents ]|
This month, let's explore the other side of programming Web applications. The Web server side, that is.
The biggest problem with using client-side tools like ActiveX controls, Java applets and scripting is they won't work on all browsers. I discovered that while testing the Internet Connection Tester Web application I wrote about in my last two columns.
The Internet Connection Tester I built tests the connection between the user's computer and a variety of Internet sites. It runs on the client, so I used client-side ActiveX controls and client-side scripting to make it. You can find it at http://www.winmag.com/people/mheller/pinger.htm. It works if you view it with Internet Explorer 3.0x running on Windows 95 or Windows NT on an Intel CPU. It won't work from the 16-bit America Online browser, a Macintosh, a UNIX box, a network computer or any of the RISC versions of Windows NT. If you run a special conversion, it may also work in Netscape Navigator with the NCompass ScriptActive plug-in installed. Otherwise, it won't even work from Netscape.
The Connection Tester isn't a critical line-of-business application. It's useful for people with the right client software, but hardly mandatory. Suppose, though, that I were writing an application to take subscriptions to WINDOWS Magazine? I can pretty much guarantee that the magazine's management wouldn't buy a line-of-business application that would only work properly for 20 percent of the people who tried using it, no matter how persuasively I argued the glories of ActiveX.
The only way I know to accomplish that is to do some programming on the Web server side. It could be done with Common Gateway Interface (CGI) programs or scripts, it could be done with Internet Server application programming interface (ISAPI) applications, and it could be done with server-side scripting. Over the last year I've delved into CGI and ISAPI several times in this column; this month I'd like to move on to Microsoft's Active Server Pages (ASP), a feature of Internet Information Server (IIS) 3.0.
ASP is intended to simplify server-side programming by adding support for server-side scripting and server-side objects. It is implemented as an ISAPI filter, which IIS applies to pages with the ASP extension. ASP pages can combine text, HTML tags and scripting commands.
In developing the Internet Connection Tester over the last couple of months, we saw that scripting with Component Object Model (COM) objects can be a viable way to develop client-side applications. ASP takes that same model and applies it to the server side.
Well, almost the same model. As always, there are twists. It's never enough to just translate the model-you have to expand and adapt it for the new environment. For one thing, ASP server-side scripting has to coexist with client-side scripting. The combination is handled in two ways: with a new RUNAT=SERVER attribute for the HTML
<SCRIPT>tag, and with the delimiters
Let's say I want to put the current viewing date on a Web page. A VBScript
This code will cause the browser to display:
That's assuming, of course, that you're browsing the page on July 4.
Maybe we should take a step back. How can we get the user into our ASP application to begin with? On IIS servers, the default document is typically set to
If you use only ASP applications, you can change the default document for the server to
This will cause most browsers to "pull"
When a client first views an ASP page in a directory, the server opens a session and fires a
The server looks for code to process these events, and their matching
ASP and forms
Like all Web pages, ASP pages can contain HTML forms. What's different is that ASP pages can also process form output. You can set the action of a form to be the page it's on or another page-whichever is more convenient and maintainable. If the form's method is
<% LastName = Request.Form("lname") %>
Most often, you'd like to add the parsed output of a form to a database. ASP includes a Database Access component, which uses ADO (ActiveX Data Objects). ADO works with any OLE DB or ODBC database and also takes advantage of ODBC 3.0 connection pooling. The implementation of ADO for OLE DB is the ADODB object.
ADO revolves around the Recordset object. You can create a fully functional, scrollable Recordset bound to an ODBC data source in just a few lines of VBScript code:
<% set rs = Server.CreateObject("ADODB.Recordset") rs.Open "SELECT * FROM authors", _ "DATABASE=pubs;UID=sa;DSN=Publishers",_ adOpenKeyset, adLockBatchOptimistic %>
Once you have an open Recordset, you can traverse its records with the
Recordsets work over connections to the database and rely on SQL database commands. In the sample above, the command is "
It's time for you to look at an example. If you already have ASP installed, try playing with the Adventure Works Catalog sample and viewing the ASP source for each page. You'll find the sample on your Active Server Pages Roadmap. If you don't have your own Web server installed, you can find Adventure Works at http://iisb.microsoft.com/AdvWorks/default.asp. If you have some version of IIS installed, you can download the IIS 3.0 update to ASP from http://www.microsoft.com/iis.
What are you waiting for?
Martin Heller writes about and does Windows programming from Andover, Mass. Contact Martin in the WINDOWS Magazine areas on America Online and CompuServe, or at the e-mail addresses here.
Windows Magazine, July 1997, page 263.