To start off let's consider a bare-bone scriptlet with just one method and compare its implementations as a DHTML and a Server Scriptlet. In this way we can observe the differences at source code level. Suppose we call it Time and assign a method called GetCurrentTime that returns just the current time.
Writing it as a DHTML scriptlet is really rather easy. The file is dhtime.htm.
<html>
<body>
<script language=JScript>
public_description = new Time;
var public_description = new Time;
var mTime = "";
function Time() {
this.GetCurrentTime = GetCurrentTime;
}
function GetCurrentTime() {
mTime = new Date;
return mTime.getHours() + ":" + mTime.getMinutes();
}
</script>
</body>
</html>
We can test this document by using the following page tstdtime.htm.
<html>
<body>
Click on the page to test the Time DHTML Scriptlet.<hr>
<script language=Javascript for="document" event="onclick">
alert( obj.GetCurrentTime() );
</script>
<object id="obj" data="dhtime.htm" style="display:none"
type="text/x-scriptlet">
</object>
</body>
</html>Of course a DHTML scriptlet can have a user interface but in this case we don't actually need one, so we hide the scriptlet. All works well and by clicking on the page we get the current time expressed in hours and minutes.
Let's now see if we can write a Server Scriptlet with the same degree of functionality. The file is called sstime.sct. A Server Scriptlet is, in fact, text file with an .sct extension.
<scriptlet>
<Registration
Description="Time"
ProgID="Time.Scriptlet"
Version="1.00"
ClassID="{51eb18c0-98a7-11d1-83d1-f46705c10000}"
>
</Registration>
<implements id=Automation type=Automation>
<method name=GetCurrentTime>
</method>
</implements>
<script language=JScript>
var mTime = "";
function GetCurrentTime() {
mTime = new Date;
return mTime.getHours() + ":" + mTime.getMinutes();
}
</script>
</scriptlet>
The only aspect they have in common is the <SCRIPT> tag. We will discuss thoroughly the structure of a Server Scriptlet file in an upcoming section. For now, let's limit ourselves to noting the HTML-like syntax and a bunch of new tags such as implements, Registration, scriptlet and method.
If you're at least a tiny bit familiar with COM modules, you won't find it hard to recognize in the above listing all the information that features a COM server, such as an ActiveX control. If you don't know anything about COM servers, then consider that such a module exposes its functionality implementing a certain number of interfaces. An interface may be seen as a table of functions with a given name. The tag implements is where this Server Scriptlet lets us know which interface is actually being implemented.
Unfortunately, this first beta only supports the automation interface so we can't do a different example. However, if you're planning to develop Server Scriptlets it's quite likely that you're also thinking about using them with HTML pages or Visual Basic forms. If so what you need, in most cases, is just the automation interface.
The Registration tag defines all the key information that will allow you to identify a COM object. Once we have the CLSID (that is a number that uniquely identifies a COM object—we'll see more about how to get a CLSID soon), we can set up a regular <OBJECT> tag as shown in the following file. The page tststim1.htm is a valid test page for our Server Scriptlet. Here we're treating it as an ActiveX control.
<html>
<body>
Click on the page to test the Time Server Scriptlet.<hr>
<script language=Javascript for="document" event="onclick">
alert( obj.GetCurrentTime() );
</script>
<object id=obj classid="clsid:51eb18c0-98a7-11d1-83d1-f46705c10000"
style="display:none">
</object>
</body>
</html>Of course, the CLSID is the same as the one encountered in the previous listing for the Server Scriptlet. We use this number instead of the file name to identify the component. The association between this code and the actual file name is stored in the Windows registry during the registration process. More on this later.
If we run this page, we get a message (see the figure) that reminds us that using ActiveX controls might well be dangerous.
We can either choose to initialize it, or not make it available to the scripts. If we choose Yes then all the scripts contained in the page will execute properly and the current time will be displayed with a click.
In the above example, we were using our scriptlet as if it was an ActiveX control (remember that an ActiveX control is also a COM object). In fact, Internet Explorer 4.0 verifies whether it is safe for scripting and then alerts us. An ActiveX control may cause harm when used through scripting. Given this, the author sometimes "marks" his control as safe for scripting, that is, the author asserts that invoking the control's methods will never result in any kind of damage for the host system. Usually this is done through the implementation of a specific COM interface or by adding specific keys to the registry. However, as explained before, the beta we have at the moment only supports the automation interface and, therefore, we can't add support for a specific COM interface. This feature is supposed to appear in future versions of the package.
Earlier, we said that a Server Scriptlet and a DHTML Scriptlet cannot be interchanged in all cases. In fact, if we try to call the Server Scriptlet defined above specifying the scriptlet's MIME type and the data attribute, all we get is a run-time error. Let's look at the following file, which is tststim2.htm.
<html>
<body>
Click on the page to test the Time Server Scriptlet.<hr>
<script language=Javascript for="document" event="onclick">
alert( obj.GetCurrentTime() );
</script>
<object id=obj data="sstime.sct" style="display:none"
type="text/x-scriptlet">
</object>
</body>
</html>Running this page and clicking anywhere on it causes the following message.
The line;
alert( obj.GetCurrentTime() );is invalid and refers to a method that the object doesn't expose. Nevertheless, the file is exactly the same as before. The problem is with the following code:
<object id=obj data="sstime.sct" style="display:none"
type="text/x-scriptlet">
</object>
In this we're telling IE4 that sstime.sct is a DHTML Scriptlet. This means that IE4 will recognize, as public members, all the functions that have the public_ prefix, or those exposed through an object called public_description. We covered this in Chapter 3. The Server Scriptlet, instead, has no public_description variable. Nothing, however, prevents us from defining such a variable. The presence of a public_description object won't affect the behavior of the Server Scriptlet when we use it as a real COM object. So let's change the Server Scriptlet code this way:
<scriptlet>
<Registration
Description="Time"
ProgID="Time.Scriptlet"
Version="1.00"
ClassID="{51eb18c0-98a7-11d1-83d1-f46705c10000}"
>
</Registration>
<implements id=Automation type=Automation>
<method name=GetCurrentTime>
</method>
</implements>
<script language=JScript>
var mTime = "";
var public_description = new Time;
function Time() {
this.GetCurrentTime = GetCurrentTime;
}
function GetCurrentTime() {
mTime = new Date;
return mTime.getHours() + ":" + mTime.getMinutes();
}
</script>
</scriptlet>
This new component is called sstime1.sct. Now it is interchangeable and can be used as both an ActiveX Control and a DHTML Scriptlet.
For the moment, a Server Scriptlet cannot have any user interface elements and cannot call message box functions. All that it can do is perform background operations and calculations. From this point of view, a Server Scriptlet could be usefully employed in middle-tier business logic units or used in the accessing of databases. This is fundamentally different from DHTML Scriptlets. DHTML Scriptlets, by contrast, are heavily based on the DHTML object model and are Web pages with a graphical content to display.
If you add a line like
alert( "This is a message" );
to a Server Scriptlet, it will be ignored or an error will be displayed. In the same way, you can't include a body or a <HTML> tag. A Server Scriptlet can only be made of script.
Writing a DHTML Scriptlet and a Server Scriptlet means writing two different files, whose only common code might well be just the public_description object. But again, defining a public_description object for a Server Scriptlet is optional. However, if one is present it does also make the Server Scriptlet usable as a DHTML Scriptlet.
The differences don't end here. A Server Scriptlet uses a different way to expose its properties and methods and needs to be registered before using. The registration step ensures that IE4 will be capable of retrieving the actual file name starting from the CLSID. Furthermore, the registration also ensures that a host environment like Visual Basic can create such an object through its name (that is, its ProgID).
After this quick tour of the differences between Server Scriptlets and DHTML scriptlets, we're ready to go into more depth, analyzing in detail the structure of Server Scriptlet files, how they work behind the curtain, and finally how to host them in real-world applications.
To start experimenting, however, you need the tools. So let's see where and how you can get the Server Scriptlet Package.