If you want to give a very simple description of DHTML documents, then you might say that they are HTML pages that have both content and the code to change it. The content is what is commonly perceived as the page content: text, images, controls, applets, marquees, lines, scripts and so forth. In short, everything that has a visual counterpart on the screen and that you can see and realize the presence of.
Scriptlets conform to this idea extremely well. They have both content and a layer of additional code that satisfies the following requirements:
Inside the scriptlet's code we can distinguish two logically different types of script code. The first is the usual code used to respond to events: clicking, mouse moving, loading and the like. The second is the script code. This encompasses and encapsulates all this into a self-contained wrapper with just a few points of contact to the outside world.
A normal Web page hosts another Web page (the scriptlet) and refers to it through an <OBJECT> tag with a couple of special attributes. These attributes allow the browser to distinguish between scriptlets and ActiveX controls. In fact, both are inserted using the same tag: <OBJECT>.
From the container's point of view, scriptlets are just like any other component. They have a predefined site with a given width and height. Their entire output never exceeds that space. The container page is completely indifferent as to whether the constituent element is another HTML page or simply a table or an animated GIF.
From the browser standpoint, however, a scriptlet is a special object that needs special treatment. In practice, therefore, a scriptlet needs another instance of the Internet Explorer 4.0 viewer engine that parses the original HTML code, builds the Dynamic HTML object model and makes it available to the scriptlet's internal code. At least under Win32 a scriptlet is actually hosted through the same container object used to view any HTML page throughout Internet Explorer 4.0 (the scriptlet's host page included).
If you want to use a scriptlet in a Web page, it's quite likely that you will want to use it again later. So you need to assign it a name or an ID.
<HTML>
<BODY>
<OBJECT ID=MyScriptlet data=myScriptlet.htm type="text/x-scriptlet">
</OBJECT>
</BODY>
</HTML>By using such an ID, you can call it when needed. From now on, the scriptlet is completely and perhaps uniquely identified by this name. Using the usual object-oriented syntax, you can ask the scriptlet to execute some code, accordingly, to its public interface.
Before going on, let's take time out to clarify the previous statement about the possible uniqueness of an object's ID. There are no syntax contraindications if you identify more elements with the same ID throughout a Dynamic HTML page. In this case, of course, you can't pretend that code like the following works well.
<script language="VBScript">
Sub SetColorItemByID( sID )
set obj=document.all.item( sID ) ' obj now may be a collection!
obj.style.color = "yellow" ' use obj.item(i).style.color, instead.
End Sub
</script>
In fact, if you attempt to get all the items with a given ID, then you could obtain a bit of a collection as well! The DHTML all collection can be asked for all the items with a given ID. If this ID is unique, then you are returned a reference to that object. If there are multiple objects with that ID, however, you are returned the collection of the objects. Having a single object or a collection of objects is quite different, of course! Thus, you must handle it with different syntaxes. You could use:
obj.style.colorto refer a given style property of a single object, while you need to resort to:
obj.item(i).style.color to get the same over an object which belongs to a collection.
Having explained this, let's turn back to scriptlets. A scriptlet's public interface is the set of properties, methods and events it declares public and makes available to the callers.
This programming interface basically amounts to the only way to access the scriptlet's internals.
Any call that you make through the scriptlet's programming interface ends up calling an internal script procedure.