Washington, September 15-18, 1999 – London, November 21-24, 1999

The Windows Script Component technology helps you write COM components with scripting languages to access the ASP objects and perform highly specialized but frequent tasks.

ASP Components with Scripting Languages

Dino Esposito

Writing COM components capable of providing run-time text to be inserted in ASP pages, was one of the first points addressed years ago, when ASP got introduced. Today, we have design-time ActiveX controls (DTC) on one end and ASP COM components on the other. Both are COM components but DTCs provide more flexibility and are visual, even if design-time, controls. ASP COM components, instead, are more direct and specialized. Usually, you don’t write DTCs for your own project (unless it's a very big project with several teams) but utilize those provided by the development tool you're using (say, Visual InterDev).

Instead, you can write COM components to make some specific features of your app easier to code and possibly reuse. For example, you encompass a sequence of actions (perform a query, get the results, process and format them to an HTML stream) into a single method call and a few parameters or properties.

So far you can write ASP components with COM and ATL and gain access to the ASP object model. Visual Studio 6.0 also provides a wizard to make it even easier. If you're familiar with C++ no problem, but what if you're not? The good news is that today you can write ASP components with scripting languages too. The key to this result is the Windows Script Components (WSC) technology that today appears to be more solid and consolidated than it was at its birth a couple of years ago.

This presentation will delve deep inside the WSC technology to demonstrate a COM component entirely written in VBScript and used by ASP pages just like any other COM object. Even if you aren’t an expert C++ or Visual Basic programmer, you can now get a better level of code reuse by writing COM components, instead of resorting to server-side includes. You can isolate tricky portions of code into a made-to-measure and easy-to-use component. I'll provide an example that works as a 'classic' DB-to-HTML converter that takes in a query string and outputs a HTML table of records.

Dino Esposito Dino (desposito@artis.net) is a trainer and consultant based in Rome, Italy. He specializes in Windows and scripting and authored Visual C++ Windows Shell Programming and Windows Scripting Host Programmer's Reference both from Wrox Press. Dino is also a contributing editor to Microsoft Internet Developer, MSJ and MSDN News. He's the cofounder of www.vb2themax.com, a VB-oriented Web site and works for Artis srl, a Rome-based consulting company active in the system integration area and Web-based architectures.

The Key Technology for ASP components

Windows Script Components (WSC) is the technology that makes it possible to create COM objects using a scripting language. An ASP component is nothing more than a WSC component that implements the interfaces to access ASP objects. To understand how to arrange ASP components, it's necessary to take a closer look at how WSC files are defined and how they work under the hood.

A WSC is a XML file that follows a precise syntax. The XML code is the glue that puts together at least two different types of information: the description of the component and its code. The description of a COM component includes the progid and/or the CLSID, a descriptive string, a version number, plus its programming interface with the list of methods, properties and possibly events.

To specify all this information you use two tags: <registration> and <public>. The former is meant to provide all the data to register and identify the component. The latter enumerates the methods and properties. It's by using an interface like this that you drive the behavior of the component and enable it to access ASP objects. Consequently, all ASP objects have a <public> section.

The World's Simplest WSC

The following listing shows a very simple WSC component. It exposes a single method called Welcome(). The method is declared in the <public> section and the body is a successive <script> block. The <registration> content is minimal but what shown next is what you really need to provide: a progid string.

<component>

<registration progid="HelloWorld.WSC"/>

<public>

  <method name="Welcome"/>

</public>

<script language="VBScript">

Function Welcome

  MsgBox "Hello, World"

End Function

</script>

</component>

This component is invoked as shown below:

Dim wsc

Set wsc = CreateObject("HelloWorld.WSC")

wsc.Welcome

A client application sees a WSC as it is a regular COM object, and actually a WSC component is a regular COM object. However, there are a few objections to answer I think:

Ø        A COM object is a binary file

Ø        A COM object has a precise binary layout

Ø        A COM object exposes interfaces

Ø        How can a client module distinguish between a binary and a script COM object?

Ø        Does this violate the purity of COM?

To all these questions (and more) there's just one answer. The script code you write through a WSC file is just code that gets interpreted by a binary module that exposes all the needed interfaces to callers. All the WSCs refer to the same binary file (scrobj.dll). The link between the progid and the script file is kept in an additional registry key called ScriptletURL. There's only one moment in which a WSC is seen as a different entity from, say, a C++ COM object: when the regsvr32.exe program registers it. This program if detects it's processing a WSC file it adds the ScriptletURL key in the proper registry subtree. This is the only difference.

A Layered Component

A WSC component can be seen following a 3-tiered schema: description, script code and the underlyling machinery that lets the callers issue calls to the object. The run-time engine implements natively a fixed number of interfaces that delimit what you can do, and what you can't do through WSC's. Through the use of WSC's we are able to use:

Ø        Automation

Ø        ASP

Ø        IE5 Behaviors

To expose an automation interface, just add a <public> tag and define the prototype you want for your methods, properties and events. After all, the <public> tag is a script-level wrapper for IDispatch and the outgoing interfaces for the called to sink events.

To access the ASP objects such as Session, Request and Response you need to require a special support. Obtain it through the <implements> tag:

<implements type="ASP" />

This tag complements <public> and they are not exclusive. An ASP component, in fact, must expose an externally callable set of functions. Furthermore, to make sure that the code of these functions can manage ASP objects and update the calling page, it must add an <implements> tag too.

To complete the discussion, an object that needs to work as an IE5 behavior and modify the run-time behavior of HTML tags must insert

<implements type="Behavior" />

In general, a behavior doesn’t need an automation interface (that is a <public> section) because it is called by Internet Explorer only and just through the Behavior-specific interfaces. However, sometimes a behavior also needs an automation interface.

Why ASP Components?

A real-world Internet project often grows in size over (a short) time up to several dozens of pages. It's clear that you simply can't keep up maintaining pages singularly. For one thing, you need an integrated development environment. Secondly, you should start reusing code across pages. One evergreen technique is based on server-side includes (SSI) (files that you include in your ASP pages making them functioning as if the code had been written at the top of the current page) For example:

<!-- #include file="c:\scripts\myLib.vbs" -->

<!-- #include virtual="/scripts/myLib.vbs" -->

You're telling the ASP parser to look also those files up for locating the functions invoked throughout the page. The module with the external functions is separated from the page that's using it, so it doesn’t pose any particular maintenance problem in case of bugs or just improvements. What you're importing, though, is just text. It could be pure text or HTML as well as VBScript or JScript functions enclosed in <% … %> blocks. In addition, SSI's get processed before the ASP parser looks at the page so there's no way to control them programmatically.

ASP components are a more modern and powerful way to make server-side includes in ASP pages. With ASP components not only do you solve the problem of writing reusable and object-based script code, but you also get real (even if not binary) COM objects that can be used in any other COM-aware environments such as the Windows Script Host.

The Power of Reusability

The most compelling use of ASP components is to isolate relatively small and frequently used pieces of code to be used across pages. For example, if you have several pages that process forms you might want to write a unique component, give it a pretty general prototype and use it wherever possible. Input validation, XML strings processing, database access, complex formatting procedures are all good candidates to become ASP components. Also any text that you use repeatedly in your ASP pages can be wrapped in a component's method. Don’t forget that the ultimate goal of an ASP component is to output text through the Response object. Thus, any text used with a high frequency is automatically a candidate to become an ASP component. On the other hand, don’t let it get out of control - you don't want to have a new component for each line of code!

Forget about C++ and Visual Basic?

Today if you want to write ASP components you should rely on C++ or Visual Basic. While Visual Basic is not that much different from VBScript and provides a far better performance, you still have to learn a brand new tool and a slightly different language. With C++ things are even worse, since C++ is a language that requires a solid and specific knowledge. It's true that Visual Studio 98 provides a great facility to write ASP components, but you need to know the ATL library in addition to the language.

Script-based ASP components definitely represent a solution for better ASP programming.

An Example of Script-based ASP Component

The component is capable of retrieving data from a query and return the records formatted in two possible ways: as a HTML table of records or as a treeview. The files are:

File	What's this	Description
Viewtable.asp	Main page of the demo	Lets you choose the view mode and run the query.
Table.asp	Page that invokes the WSC	Retrieves the view mode and instantiates the WSC
Db2Html.wsc	The WSC that does the job	Source of the WSC

The query uses the Northwind Access database through a DSN of NW.

---