When comparing scriptlets and ActiveX controls, the first, great, difference that strikes you is the languages you can use to develop them. ActiveX controls can be written in a variety of programming languages, including Visual Basic, C/C++, Delphi, and Visual J++. In addition, you can use specialized frameworks or class libraries such as MFC or ATL. Put another way, to develop ActiveX controls, you have a wide range of heterogeneous tools to rely on.
With scriptlets, things are slightly different. While you have the same facilities as regards languages, there aren't yet any powerful tools available for developing code. Of course, this is perfectly natural and comprehensible at the moment, since scriptlets are a new entry in the software components market.
To write your own scriptlets, you can use any scripting (not programming) languages that you know. From this point of view, therefore, scriptlets and ActiveX controls offer a similar degree of flexibility.
Furthermore, scriptlets aren't binary and don't require compiling and linking. Anyone can look at the underlying code without restrictions.
Designing a scriptlet is much the same process as designing a control. The interface they expose to the user is identical, as is the make up of properties, methods and events. So you concentrate on the functionality to provide and try to express it through a public interface. The nature and the structure of this programming interface is deliberately analogous.
To a Web developer, it isn't really significant whether the component he or she's using is an ActiveX control or a scriptlet.
ActiveX controls are far more complex and require the implementation of some basic functions to handle aspects like embedding, licensing, in-place activation, and so on. Often, however, many of these aspects are hidden by the frameworks and the classes a programmer might be using.
With scriptlets you don't necessarily have to see all this stuff. Writing a scriptlet is somewhat akin writing an ActiveX control with a high-level tool such as Visual Basic 5. What you really need to take care of is the set of properties and methods to be exposed.
Usually, a scriptlet has a user interface given by the elements listed in the
section. Visual Basic controls, instead, are commonly formed by constituent controls that lie in the <BODY>
object. The activity of the both the scriptlets and the Visual Basic-based ActiveX controls consists mostly in coordinating the functionality provided by the internal components.UserControl
One difference between controls and scriptlets comes in the notification of events. In both cases, the programmer calls a
function, but the results are different. All the custom events fired by scriptlets are routed to their respective recipients via a unique channel. That is, scriptlets always trigger the same event whose specific name is carried with the data associated with it. Ordinary ActiveX controls, instead, have a set of different events, each one with its own data. A user application that sinks scriptlets events should define a unique handler and distinguish between the various events with a multiple RaiseEvent
or a if
statement. Select Case
On the other hand, a program that needs to reply to an ActiveX control's notifications will define a number of different handlers.
As well as their internal structure, ActiveX controls have an external layer of code to provide identification, registration, and licensing. Nothing of the kind is supported by scriptlets. ActiveX controls are supposed to be uniquely identified throughout the whole world. Each control is identified with a 128-bit value, familiarly known as CLSID, which is guaranteed to be unique for a zillion of years to come. (Of course, CLSIDs are unique if, and only if, you have special routines and utilities to generate them!)
ActiveX controls need to be copied on to a computer and correctly registered. Again, the best way to do this is using proper functions or utilities, provided with all the development tools.
Scriptlets, instead, are identified by name and have no need of registry manipulation. If you want to uninstall a scriptlet from your computer, then just delete its file. (A scriptlet, in fact, can be made of more files, be they other nested scriptlets, GIF images, ActiveX controls or anything else you can include in a DHTML page.)
If you want it to work on your machine, then just make a copy. No further tasks are required.
This may be seen as an advantage as well as a disadvantage. It makes dealing with scriptlets a lot easier and quicker, but also limits their commercial application.
Compiled code offers, on average, better performance and doesn't require runtime interpreters. However, ActiveX controls are rarely slim. Let's consider a control developed with Visual Basic. Its apparent size is about 20 or 30 KB, so you could say it's a really small and light component. A Visual Basic control, however, to work properly requires the Visual Basic virtual machine—which is the file
with a size of over 1.3 MB! In most cases, this file is unnecessary, since it is a widespread module you can find in almost every msvbvm50.dll
directory as the result of previous downloads or other program installations. Windows\System
The same holds true for controls developed with MFC, whose shared library requires over 1 MB of memory and disk space. Sometimes you can specify to avoid calls to dynamic libraries, but encompassing the runtime modules considerably increases the size of the controls.
If you need the slimmest and fastest controls, then you should check out the Active Template Library (ATL) which enables you to create components of about 30 or 40 KB without additional heavy modules.
Scriptlets are composed of pure HTML source code and are much smaller than the corresponding ActiveX controls. The most complex and sophisticated of them can reach 30 KB like the aforementioned calendar scriptlet. More often, scriptlets occupy very few kilobytes. For example, the clock scriptlet that can be downloaded or run from our site (
) is about 5 KB.http://rapid.wrox.co.uk/books/138X