Published: Wednesday, October 18, 2000
Understanding Windows Script Components
By David Power
Introduction
Back in May 2000, 4Guys resident ASP guru Scott Mitchell
contributed an article entitled Building Windows
Script Components. The article provided an overview of the uses of COM components
within ASP, a description of Windows Script Components (i.e. WSC's), their benefits
over compiled components and a detailed walk through of the WSC Wizard which can be
downloaded without charge from Microsoft.com. If you haven't read this article, I
highly recommend reading it now!
Today, we'll build upon the framework laid in this previous article by analyzing the advantages of WSC's a
little more closely and, later in the article, creating our own script component.... one you'll surely find
many uses for!
COM Objects - General
Most seasoned ASP veterans have used some form of COM component at some point in time. (For those new to
creating COM components, I highly recommend the following article: Writing
a COM Component with VisualBasic!)
The procedure for using a COM component is pretty straight forward:
1) Instantiate the component:
var objComp = new ActiveXObject("NameOf.Component"); // in JScript
|
or
Set objComp = Server.CreateObject("NameOf.Component") ' in VBScript
|
2) Set any necessary properties:
objComp.width = 600; // set the width to 600 pixels
objComp.color = "FF0000"; // set the color to red
|
3) Call the method you wish to execute:
objComp.draw(); // draw the chart
|
The beauty of WSC's is that they are in fact COM objects and as such they are instantiated and utilized in
a manner identical to objects which exist as compiled DLL's. Again, for information on creating WSCs, be sure
you do read Scott's
earlier article!
Advantages of WSC's Over Server-Side Includes
If you've done any degree of ASP coding, chances are, you've accumulated a handy toolbox of utility functions
which you use on a regular basis. Rather than copying the source code for a given function into every script
which requires it, you package your utilities up into a single file (perhaps called utilities.asp)
and #include it at the top of your ASP scripts in the following fashion:
<!-- #include file="includes/utilities.asp" -->
|
(For more information on server-side includes, be sure to read: The Low-Down on
#includes!) When used properly, server-side includes are an extremely useful tool. The
downside, of course, is that each and every line of code in an include file is parsed by the appropriate
language interpreter (i.e. JScript or VBScript) before the ASP script in which it is #included is
executed. As you can well imagine, #including a large utility file in an ASP script when only
one or two of its functions are required by the script is not the most efficient use of system resources.
In contrast, because they're only instantiated when their functionality is required, WSC's alleviate much of
the resource overhead required to parse a server-side include file.
A second advantage of WSC's over server-side includes is that because they are COM compliant, they can be
instantiated and used from virtually any COM compliant development environment such as Microsoft VisualBasic,
C++, Windows Script Host or the like. (Note: this is true provided the component does not call any of the
built-in ASP objects: Response, Request, Server, Session, or Application.) You can even create type libraries
for your WSC's which are extremely useful if you plan to use them in another language environment.
To suggest that WSC's can be considered an out-and-out replacement for server-side includes, however, would be
more than a little brash. Creating a component which formats an ADO recordset into an HTML table would be an
efficient use of this technology. In contrast, a server-side isNum() function (i.e. one which returns a
boolean value based on whether or not the passed argument is numeric) is far better suited to server-side
inclusion as the overhead involved in creating, instantiating and calling the methods of a component which
performed such a simple function would be a terribly inefficient use of resources.
Yet another advantage of WSC's is that the object-oriented features of COM objects quite often make coding
less cumbersome for the developer. For example, making a function as generic and re-usable as possible often
requires that it possess a large number of arguments. Each time the function is called, the programmer must
remember the proper number and order of the arguments. Even if a default value can be coded for a given
argument, it's normally necessary to pass a dummy variable (i.e. either a null, empty string, zero, etc.) in
the proper order for the function to render predictable results.
Component-izing a complex function obviates these inconveniences. Replacing function arguments with object properties
means that:
- Default values can be coded with great ease
- Properties can be assigned in any desired order
- If coded as read/write, property values can be modified by component code and later read back by the calling script
- One or more properties can be modified and the component's methods called again without starting from scratch
Now that we've compared WSCs to server-side includes, let's examine how WSCs compare to compiled components.
We'll tackle this in Part 2!
Read Part 2!
