To read the article online, visit http://www.4GuysFromRolla.com/webtech/101800-1.shtml

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!


  • Article Information
    Article Title: Understanding Windows Script Components
    Article Author: David Power
    Published Date: Wednesday, October 18, 2000
    Article URL: http://www.4GuysFromRolla.com/webtech/101800-1.shtml


    Copyright 2017 QuinStreet Inc. All Rights Reserved.
    Legal Notices, Licensing, Permissions, Privacy Policy.
    Advertise | Newsletters | E-mail Offers