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

Understanding Windows Script Components, Part 2

By David Power


  • Read Part 1!

  • 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:

    dbCoolBox Screenshot

    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!

  • Read Part 3!


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


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