Understanding Windows Script Components, Part 2

In Part 1 we looked at the advantages of WSC's over server-side includes. In this part we'll continue our examination of WSC advantages by comparing them to compiled components!

Advantages of WSC's Over Compiled Components
ASP developers who've done any custom component development are more than likely familiar with the rather annoying "feature" of IIS which necessitates stopping the web service before a registered component can be replaced and re-registered. If an ASP application is being run on a dedicated host, this is not usually a problem since the developer or webmaster typically has full control over all server resources and can stop and start the web service any time they wish.

But let's face it, many developers install their applications in a shared / virtual hosting environment. The reality is that many shared hosting providers will simply not install custom COM components on their servers. Those who will often do so reluctantly and even then require an evaluation / test period and charge a fee for registering the component. A big benefit of WSC's is that once one has been registered on the server, the code which comprises it can be modified at any time without the need to stop the web server and re-register it.

An even bigger benefit, one which many developers may be unaware of, is the fact that it's possible to instantiate a script component without registering it at all! The GetObject function can be used to create an instance of an unregistered script component in the following manner:

var objComp = GetObject("script:<path>NameOf.Component"); // in JScript

or

Set objComp = GetObject("script:<path>NameOf.Component") ' in VBScript

Note: <path> represents the full physical path of the component. In the ASP environment, it's best to use Server.MapPath() to determine this path without ambiguity. (For more information on Server.MapPath() be sure to read: Using Server.MapPath()!)

Being able to instantiate an unregistered component is somewhat of a breakthrough in the Windows world. It effectively means that a developer can create components and install them on a shared server without the involvement of support staff and without incurring fees of any kind. As you can imagine, this is a tremendous bonus.

Performance
It goes without saying that the performance of a script component will be somewhat inferior to that of a compiled COM object. Interpreted script simply can not be as efficient as compiled code. However, in many instances, the benefits of Windows Script Components generally outweigh any performance issues which might exist. If you happen to be developing for a shared environment for instance, just being able to use a custom component at all may be enough to overshadow any performance issues.

An Example
Now for the fun part! Let's create a component. As the focus of this article is to give you a solid understanding of Windows Script Components, their advantages and uses, we won't create anything too complex here. The component, which we'll call dpCoolBox.wsc, performs a simple yet useful function: it creates an HTML text box, complete with separate title and body text areas, which is fully configurable in terms of sizes, borders, colors, fonts and alignments.

The following is a sample of how the component would be used in an ASP script:

// instantiate without registration var strPath = Server.MapPath("dpCoolBox.wsc"); var objBox = GetObject("script:" + strPath); var body_text = ""; body_text += "Here's some sample text to show you how simple it is " + "to use the dpCoolBox script component. "; body_text += "Not all developers are aware that a script component " + "can be instantiated without registering it on the server. "; body_text += "This is a huge bonus if you plan to use custom components " + "in a shared web hosting environment. "; body_text += "That's all for now!"; // Set the various properties... objBox.boxWidth = 200; objBox.titleText = "This is the title"; objBox.bodyText = body_text; // create the box and write it to the screen Response.Write(objBox.create());

The resulting output of this script should appear in a browser as follows:

With the exception of the boxWidth, titleText and bodyText properties, which are explicitly set, the sample code uses the default colors, fonts, sizes and alignments.

Now that we've taken a basic look at the dpCoolBox WSC component, it's time that we look at the WSC's properties and methods in-depth. We'll do just this in Part 3!