For those of you out there who have been working with the Web and are comfortable with its basics, skip down to the next section. I want to try to explain Web development to those who are just getting used to this new paradigm.
Basically, Web development is done in two forms. First, programs such as Front Page and others handle the presentation of information. They generate the backgrounds, buttons, and visual aspects of the Web page. All of this coding is stored in the form of HTM and other files on a Web server (usually managed by IIS). While there are ways for a "normal" Visual Basic Win32 program to access IIS-based applications, I'll focus (at least initially) on Visual Basic Script (VBScript) applications. Active Server Pages and other HTML pages you create can be coded in combinations of HTML and one of the scripting languages. I'm partial to VBScript, but the browser community does not universally support it. However, it's always supported under IIS, so that's where I'll execute my Web-based code.
The next form of development, seen in most substantial systems, executes code that runs on the central server—IIS. Interestingly enough, this is not typically binary compiled code (although it can be, if you use Web Classes), but interpreted Visual Basic or Java Script. This is not even "compiled" Visual Basic "P" code, but raw source that's stored in ASPs, loaded, interpreted, and executed on the fly.
VBScript is more like MBASIC 80 than Visual Basic—it's considerably less sophisticated. For example, using VBScript, you can't create ADO or other COM objects ahead of time, as you can in "regular" Visual Basic code. While an ASP can reference COM objects, even ADO COM objects, these have to be created in Visual Basic or another language that supports a binary compiler (so you can build the DLLs). To access ADO or any other COM object from a VBScript program, you have to use the CreateObject method to construct these objects at runtime. In addition, VBScript also works entirely with Variant variables (which may in turn contain strings, numbers, arrays, objects, etc.). This means that all VBScript COM references are "late" bound.
There's also a new set of restrictions, and many of these limitations derail a variety of the things we do to improve performance:
One of the most limiting aspects of VBScript code is the error handler, or the lack of one. Yes, you can turn on error handling, but only to skip over any code that causes errors and ignore the error—On Error Resume Next. Most Web pages I've seen use this technique. This means that you'll have to add code to deal with the errors after each line of VBScript code that could potentially cause an error.
However, IIS5 (on Windows 2000) implements new technology that alleviates this problem by enabling you to configure an exception ASP page. This page is called whenever your script encounters an unhandled error. This means you can implement a "central error handler" based on this code.
The default exception page passed by IIS (%WinDir%\Help\iisHelp\ common\500-100.asp) can be modified to handle your particular site's error issues. If you need a better user interface, better logging, or simply better error management, you can configure IIS and tell it which page it should go to on a Website, directory, or page-wide scope. This page has access to the ASPError object, which has properties that tell you all you want to know about the error. For example, was it a script syntax error or a runtime error? What page caused the error and what line and what description was passed?
The use of these exception pages may also alleviate problems associated with inadequate error handling and debugging information, as outlined later in the chapter. While the default error page doesn't show the error Description (for some obscure reason), you can edit it and insert the following in Line 65:
<h3><%= objASPError.Description %></h3>
This change will let you see the description of the error above all the rest of the information.
You'll also find that it won't be easy to send back error messages when things go wrong in the ASP. You don't want to let IIS or VBScript display an error page, so you'll want to trap the errors and deal with them. However, if you expect to send back an XML response, it can't have Response.Write "informational" messages embedded within. So, when your ASP expects to send back XML-formatted data and an error occurs, you'll have to resolve these errors yourself (on the ASP) or use a couple of other techniques that I'll illustrate as we go on.
ASP code is a strange mix of executable (Visual Basic or Java) script source code intermixed with HTML commands. This threw me at first, because I did not get the gist of the "shift" characters that tell the compiler to compile some text and pass the rest to the browser to perform some function. Because of this, you'll sometimes find HTML interspersed with script code, using special tags to indicate the shifts in and out of the compiled code. However, most of my ASP pages that return XML don't try to send non-XML-formatted HTML back to the browser—not unless there's trouble.
The tags used to switch in and out of VBScript code in an ASP page are "<%" and "%>". Anything inside these beginning and ending tags is considered script code to be compiled and executed when the page is loaded. You can switch in and out of "code" anytime you want. Anything outside of the code brackets is sent to the browser as raw text or HTML commands.
Because all browsers support HTML, this provides a universal way to communicate to the browser from an ASP page running VBScript on the server. As the spring of 2001 gets closer, we'll see how Visual Basic 7.0 provides a way to create Visual Basicbinary executables and extrude HTML (and XML) to pass content back to the client.
The browser expects you to pass "tags" that describe specific regions of the Web page. These tags are bracketed in less-than (<) and greater-than (>) symbols. For example, a tag used to capture user input in a text box would look like this:
Name wanted: <INPUT TYPE= "TEXT" NAME="txtName" VALUE= "Default" >
The tag here begins with the "<" symbol followed by the tag name—"INPUT" in this case. The tag ends with the ">" symbol. Between the "<" and ">" symbols are attributes, which are synonymous with properties. In this case, the TYPE, NAME, and VALUE attributes are specified to tell the browser how to treat this INPUT area and how to reference it from elsewhere on this page or on other pages we launch. The string "Name wanted:" appears on the Web page in front of the INPUT text box. Anything not embedded in the HTML tags appears on the page as text.
There are many ways to run the code in your ASP. One common way is to simply reference it from an ordinary Web page. This could be manifested as a URL tag that points to the ASP file on the server. You can also use the Form tag and the Action attribute to do the same thing (as shown in the following code). The Form tag names a specific ASP file on the Web server, just as you would point to a remote file. In this case, I used the "Post" technique to pass an argument (the name wanted) to the ASP. This technique prevents parameters passed to the ASP from appearing on the URL invoking the ASP.
The code shown here is a simple (really simple) Web page used to capture a couple of parameters from a browser and to launch an ASP. See PostExample1.HTML in the sample Web (ADOBP) on the companion CD for the entire source.
<html> <meta NAME="GENERATOR" Content="Microsoft Visual Studio 6.0"> <FONT SIZE="4" FACE="ARIAL, HELVETICA"> <B>ADO Examples and Best Practices Example 1</B></FONT><BR> Passing arguments between an HTML form and an ASP<BR> using the Post method<BR> <body>
This next line is the FORM tag that references the SimpleASP.ASP page in a specific directory on the Web server. I'll discuss the operation of this tag a little later in this chapter.
<FORM action=..\asp\SimpleASP.asp method=post>
The next few lines display two INPUT boxes (basically browser-based TextBox controls) to capture keystrokes from the user. The NAME attribute for each control is used to identify the controls to the ASP. The VALUE attribute contains an initial (default) value that's passed if the user does not type anything into the control. The attributes of these controls are passed as members of the Request object's FORM property so they can be referenced by name on the ASP.
Name: <INPUT NAME="txtName" VALUE="Vau%" > <BR><BR> Max Rows:<INPUT NAME="txtMaxRows" VALUE=50 style="HEIGHT: 25px; WIDTH: 31px" maxlength=2 dataformatas=Numeric><BR><BR> <INPUT type="submit" value="Submit Query"> </FORM> </body> </html>
A little later in this chapter, I'll discuss the server-side ASP code. In that code, I extract the arguments captured by the Web page code shown above by examining the Request object's Form property. We'll get to the server-side code in a minute.
The Web page built with the HTML described above is shown in Figure 9-1:
Figure 9-1: Capturing parameters from a Web page and invoking an ASP
Because the queries we run in the ASP usually need parameters, you'll have to collect parameters using Input tags (or some other HTML tag) or expect the parameters to be concatenated to the URL used to launch the Web page. For example, if you want to select a set of authors from the Biblio test database whose last name begins with a specified string, you could prompt the user with the previous code. Note the Input tag with its Type set to "submit" (shown again here). This constructs the command button that launches the ASP when clicked by the user.
<INPUT type="submit" value="Submit Query" >
At this point, the current page is pushed down in the stack, as it were. The user can navigate back to it, but the ASP typically generates the next page the user sees. However, if the ASP code takes too long to complete, the user is likely to either go elsewhere (give up) or click the Submit button again. If they click again, IIS launches yet another copy of the ASP and restarts the process—which only aggravates a bad situation. There's really no way to prevent this (as you can in Visual Basic).
The Form tag in the earlier code (shown again below) tells the browser to construct a Form object. When the Submit button is clicked, the browser passes the Form object to the ASP named in the Form Action attribute. The Form tag also specifies the method to be used to pass any captured INPUT values to the target page.
<FORM action=..\asp\SimpleASP.asp method=post>
In this case, we specified that the browser is to use the Post technique to pass the arguments in the structure behind the scenes to the ASP. This way the arguments do not appear in the URL. This prevents someone from simply editing the URL in the browser to change the parameters (which is possible if you set the Method attribute to Get).
A URL simply points to the "virtual" filename on the remote IIS server. It might point to an HTM, ASP, or other page recognized by the browser.
If you set the Form object's Method attribute to Get (as opposed to Post) to pass parameters from your Web page to the ASP, the browser tacks the arguments to the end of the URL, separated with "?" characters. The end of each parameter is marked with a percent sign (%) as shown below (although it's not always used).
If you set the Form object's Method attribute to Get, the ASP can reference the individual arguments through the QueryString collection, as shown next:
Dim txtName txtName = Form.QueryString("txtName")
The ASP or Internet paradigm illustrates a fundamental difference between writing interactive Visual Basic client/server applications and Web-based applications. In Visual Basic, we construct presentation controls that are basically static. That is, they are filled by code running on the client. In the VBScript ASP programming model, the client makes a data request and subsequently paints the contents of the result set in these static display controls. Generally, Visual Basic client/server developers don't construct a new form with data-generated controls for each query (but we could).
In Web-based development using ASPs, it seems that the new pages (or at least regions of the page) are reconstructed almost from scratch on each query. However, as I illustrate later in this chapter, we can call the same IIS-based server-side ASP code from "traditional" Visual Basic programs—and fairly easily.
For more information on the specifics of Visual Basic Scripting Edition coding, see http://msdn.microsoft.com/isapi/msdnlib.idc?theURL=/library/partbook/egvb6/programmingwithvbscript.htm.
3270: When I started working on mainframes in the 1970s, the 3270 was used as an "intelligent" terminal to display data passed from a mainframe. It used a rudimentary data display and editing language not unlike really basic HTML.
OSFA: One size fits all.