Dino Esposito

ASP and Windows Script Components

Download the code (5KB)

ne of the great innovations in Web development that has contributed to the evolution of Internet and intranet applications is ASP. ASP moved many tasks to the server, taking advantage of its sophisticated development resources and enabling the use of even thinner clients that need to understand only the simplest HTML.       On the other hand, ASP is just a mix of HTML and script code blocks that a preprocessor expands, sending the output back to the browser. This means that as soon as the size of your application exceeds a certain limit, ASP becomes insufficient to manage it. You might think of ASP not as a real programming language, rather as a special, professional glue you can use to put together relatively small objects. Just as you wouldn't use only glue to build a house, you might not want to use pure ASP code to assemble a whole Web application.       As a result, ASP lends itself very well to use as a sort of hosting environment for specialized components capable of interacting with the ASP object model and, subsequently, the browser. In other words, you write components to access data and prepare the parametric parts of your pages. Then you use the ASP mix of HTML and script blocks to put it all together. ASP programmers really need just two things: an integrated development environment (IDE) and tools to write COM components. IDEs like Visual InterDev® let you abstract the ASP project, presenting the various pages as specialized child elements of a unique parent container. Gone are the days when Notepad and ASP scripts were enough to create a Web project. Design-time Controls and COM Components       The first custom-designed server-side components were the ActiveX® design-time controls (DTCs). DTCs work like regular ActiveX controls, and are hosted by some of the IDEs you can use to produce ASP or HTML pages. DTCs are never downloaded to the client and they're completely invisible to the browser. They have no user interface except for the property pages that let you set the properties at design time. You'll find more information in the SDK Documentation area of the MSDN™ library (http://msdn.microsoft.com/library). Also, DTCs were discussed in the June and October 1997 issues of MIND.       A DTC is really nothing more than a macro that the host environment (such as Visual InterDev) uses to insert parametric text (like a table of records) on demand. You can create ASP or HTML pages using DTCs, but once you save the page there's no further interaction between the control and the page; now there's only text in the spot where you placed a DTC.       Recently, another generation of server-side, ASP-specific components have taken root. They are called COM components, and are nothing more than COM Automation objects. Basically, they leverage the idea behind DTCs, but with a significant difference: a COM component is an active part of the ASP page and can be seen as a runtime (as opposed to a design-time) control. As with DTCs, they expose methods and properties via COM Automation and are fully programmable. Unlike DTCs, COM components publish their output to the ASP transfer buffer and interact directly with the ASP machinery through the ASP object model. You don't need special tools to create ASP pages using COM components, and these components don't require special COM interfaces such as IActiveDesigner to interact with the host environment.       A COM component is a COM object that can access the ASP object model. This means that a COM component can read input parameters through the intrinsic Request object and send text back to the browser via Response. It can also manage state through the Session object and access the application's settings using Application.       Employing COM components has two widely recognized advantages. First, you end up with a layered application that has separate tiers for presentation, business logic, and data access. Second, you improve overall performance by relying on compiled components rather than interpreted pieces of script code that sooner or later become hard to read and extricate.       You can write COM components in any of the environments supported by Visual Studio® 6.0, including Visual Basic®, Visual C++®, and Visual J++®. If you're using Visual C++ 6.0, there's a ready-to-use ATL template (see Figure 1). With Visual Basic, you reference the ASP object model from asp.dll.

Figure 1: ATL Template in Visual C++ 6.0

At this point you might be thinking that many ASP-based applications will eventually migrate toward a collection of interoperating objects that the ASP script code simply glues together. However, you don't want to just move all the code from an ASP application into a COM object. Writing a COM object is always a more difficult proposition because it requires more programming experience.       The point is, even if you're writing a COM component because you need to access the full Win32® API or you need the highest performance possible, chances are that you still have a lot of boilerplate script code waiting to be reorganized and, perhaps, componentized. COM Components in VBScript       There's a high probability that you'll need to accomplish the same task in several different ASP pages. The easiest way to solve this problem is an old favorite: cutting and pasting. Although this solution is inherently inelegant, it is far less maintainable than building a simple parametric component. For example, think of a set of validation routines or reusable procedures that manipulate arrays or dates. Putting all of them together in a reusable, object-oriented manner could significantly increase your productivity. But what if you have to write them in Visual Basic or Visual C++? I've seen lots of developers give up and resort to cut-and-paste or server-side includes (SSIs). Now, using Windows® Script Components (WSC), formerly known as server scriptlets or just scriptlets, you can write real COM objects with scripting code.       I've covered the basics of the scriptlets technology in previous columns (MIND, May 1998 and MSDN News, November/December 1998). So here I'll just discuss the most recent changes to the syntax used in WSC files. In addition, I'll focus on the script-based components you can write to work on ASP pages. Windows Script Component Basics       A WSC is a text file written to follow a specific XML schema. Each WSC file contains two main blocks of information: a descriptive section and a script section. The descriptive section defines the programming interface of the component. Here you specify the registration information (CLSID, progID, and version number) and the full set of exposed interfaces. By default, a WSC exposes the IDispatch interface for automation; the programmer is simply required to specify the prototype of the various methods, properties, and events. Figure 2 contains a bare-bones WSC component. The following is the script code to call it:

 Dim wsc
 Set wsc = CreateObject("HelloWorld.WSC")
 wsc.Text = "Hi all"
 wsc.Welcome

 <public>
     <method name="Execute">
         <parameter name="sqlCommand"/>
         <parameter name="maxRecords"/>
     </method>
    <property name="Connection" />
    <property name="ViewMode">
       <get internalname="get_ViewMode" />
       <put internalname="put_ViewMode" />
    </property>
    <event name="QueryDone">
       <parameter name="recordCount" />
    </event>
 <public>

   function get_ViewMode()
       get_ViewMode = ViewMode
   end function
 
   function put_ViewMode (newValue)
       ViewMode = newValue
   end function

 <property name="ViewMode">
    <get />
    <put />
 </property>

 <?xml version="1.0"?>
 <component>
 •••
 <script language="VBScript">
 <![CDATA[
 •••
 ]]>
 </script>
 </component>

 <script language="VBScript" src="procs.vbs" />

Other Tags

      Additional WSC components can be defined in the same WSC file. Each is wrapped in a <component> tag, but all the <component> tags must be enclosed in a <package> section. There are a few tags that apply only on a per-component basis, including <object>, <reference>, and <resource>. The <object> tag lets you share the same instance of a given object among various <script> blocks. For example, if you have distinct <script> sections and all of them need to access the ActiveX Data Objects (ADO) object model, you can create a global instance of the object and make it accessible through its ID.

 <object id="ado" progID="ADODB.Recordset" />

 <object id="ado" 
     progID="ADODB.Recordset" 
     reference="true" />

 <reference progID="ADODB.Recordset" />

 <resource id="errCantCreateConn"> 
 Unable to create the connection
 </resource> 
 <resource id="errWrongArgs"> 
 Wrong number or types of arguments
 </resource>

 <% 
 Response.Write getResource("errCantCreateConn") 
 %>

Figure 4: Generating a Standard Type Library for a WSC

However, while it's quite handy, this option doesn't provide everything you really need; all of the settings—from the name of the typelib file to the various descriptions—will default to generic strings. Figure 5 demonstrates a Windows Script Host (WSH) script that creates a more descriptive type library. You can replace the standard procedure with this one by changing a registry entry. Under the key

 HKEY_CLASSES_ROOT
   \scriptletfile
     \shell
       \Generate Typelib
         \command

 wscript "c:\windows\typelib.vbs" "%L"

Figure 6: Specifying Registration Information

Figure 7: Defining Supported Interfaces

Figure 6 and 7 show the first two steps of the wizard, which let you specify registration information and define the supported interfaces (ASP code and behaviors) as well as the standard Automation interface. Figure 8 shows the source code of a sample COM component created by the WSC wizard. This sample is a simple component that validates the text entered into a textbox. It uses the Regular Expression object from VBScript 5.0 to do the job. Figure 9 shows an ASP page that utilizes the sample component.

Figure 9: Running the Sample Component

Admittedly, this example doesn't show the true power of WSC. In fact, the validation implemented here is nothing but a wrapper for the methods of the RegExp object. However, in a real-world scenario you might need to integrate the validation procedure with database access to check a user's password. Notice, however, that at this point you have a script component that acts like a real COM object and manipulates the ASP object model directly. The <implements> Tag       The key instruction to make the ASP object model accessible from within the WSC script code is:

 <implements type="ASP" id="ASP" />

Figure 10: Requesting an ASP Page

In the syntax of the <implements> tag, notice the presence of an ID attribute. It's optional and, as far as I know, it's ignored for COM components. The type attribute, on the other hand, is a sort of keyword. While the WSC runtime is parsing the code for a given WSC file, this attribute helps it identify the object it needs to load to provide the additional required functionality. Currently, only ASP and behaviors are supported.

 <implements type="Behavior" />

 set wsc = createScriptlet("one")

 var obj1, obj2;
 obj1 = new ActiveXObject("One.WSC");
 obj1.Tell();

 obj2 = new ActiveXObject("Two.WSC");
 obj2.Speak();

 <body>
 <%
     set page = Server.CreateObject("ScriptDtc.WSC")
     page.Title = "This is the title"
     page.SubTitle = "This is the subtitle"
     page.Footer = "(c) 1999"
     page.Sidebar = "Menu"
     page.Content = "<br>Welcome to this Web site!"
     page.DrawPage
 %>
 </body>

Figure 13: Running the WSC Page

It takes more work to create a component that is flexible enough to produce a large part of your pages, but you should now see the possibilities. WSCs are just what their name suggests: script components. You should be using them primarily to componentize your script code. A Word on Behaviors       Behaviors are a new technology introduced by Internet Explorer 5.0. While the recommended way of writing behaviors is through HTML Components (HTC), you can write behaviors through WSC as well. An HTC is really just a simplified version of a WSC. Rather than writing a COM component to validate the content of an input box, you can define a new behavior for the <INPUT> tag that takes a regular pattern into account. This improved <INPUT> tag will check whether it's compliant with the specified pattern. Of course, this approach requires Internet Explorer 5.0 as the client.       Once you define a behavior like the one in Figure 14, an HTML page may include an <INPUT> tag like this

 <input type=text 
     class="Valid" 
     Tip="Enter two words separated by a blank" 
     TipControl="TipText" 
     Mask="\w+ \w+">

 <style>
 .Valid {behavior:url(textbox.wsc)}
 </style>

Figure 15: A Login Page Using Behaviors

The Big Picture       Bear in mind that the WSC syntax has evolved quite rapidly in the past year to keep up with the evolution of Windows scripting. Some functions and tag names may have changed, so be sure to check the latest documentation on the Microsoft scripting site. I examined WSC mainly from the ASP point of view. However, you can also write reusable code the COM way using VBScript or JScript. You can take advantage of this in ASP applications as well as Internet Explorer 5.0-based modules or WSH procedures.       Another advantage of WSC is that—thanks to the language-neutrality of Windows Script (also known as ActiveX Scripting)—you have a powerful way to make your Perl or Rexx script COM-ready, making them reusable in all these environments. To take advantage of this power, make sure you install the WSC package properly. The runtime files come with Internet Explorer 5.0, WSH 2.0, and Windows 2000. Those are the only binaries you need on your machine. The documentation and the wizard must be downloaded separately from http://msdn.microsoft.com/scripting.

From the December 1999 issue of Microsoft Internet Developer