Understanding Windows Script Components, Part 2By David Power
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
can be used to create an instance of an unregistered script component in the following manner:
<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
Server.MapPath() be sure to read: Using
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.
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.
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:
The resulting output of this script should appear in a browser as follows:
With the exception of the
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!