Scriptlets
For background see the DaveNet piece, Scriptlets, 9/15/97.Basically scripting environments are being given the same status as Java in the web browser.
To us it means that Frontier's object database, native verb set, development tools, threaded runtime features can all be applied to web content on the client side.
It'll make smart scriptable sandboxes possible. We've been ready for this since last spring. We get a chance now to dig in this direction.
Samples
Microsoft provided two sample files:
In both cases, view source to see what's going on.
The remainder of this document is the contents of the Microsoft Word document describing Scriptlets, written by Bob Jervis, released on August 29, 1997.
What is a Scriptlet?-- Simple Concept with Global Reach
A scriptlet is a component for the Web. They are a standard feature of Internet Explorer 4.0. As designed, Scriptlets combine the benefits of component programming with Dynamic HTML and script. The consequences of this combination, however, transcend the Web.
Component Based Software
Components are now recognized as a key technology to improve the amount and quality of software. Microsoft Corporation has been a leader in providing comprehensive component technology as part of our Windows platform through Component Object Model (COM).
Components are units of software that are self-contained and designed to be used through simple interfaces. While most early components were designed to present some visual appearance to the end-user, components can consist of pure logic and may have no visual representation for the end-user whatsoever.
A programmer developing an application uses substantial design- time information about a component in order to understand how to customize it and use it in her program. Much of this information is not needed to actually run the resulting application at run time. Component architectures today therefore try to identify the information only needed at design time and organize the packaging of components so that this information does not need to be carried in the finished application.
Most component architectures today describe the component interfaces in terms of three concepts: properties, methods and events.
- Properties act like named memory values inside the component. They are the means for customizing the component at design time. Properties can also be used to inspect the state of a component or modify its behavior at run time.
- Methods are operations that a component can perform at run time in order to carry out useful work. Together with properties, methods are the means for a program to communicate information into a component.
- Events are notices to the outside application that a component transmits at run time to the outside application. These events are the primary means for communicating information out of a component.
Benefits of Components
Components isolate themselves from their surrounding program, except through the well-defined interfaces they expose. In this way, errors elsewhere in a program will not affect a component. Historically, the ability of an error to have unexpected consequences throughout a program haves made debugging difficult and expensive. By removing this source of errors, components simplify programming and reduce costs and risks.
Another substantial benefit of well-designed components is reuse. A component can be used in many programs without having to be modified. Intelligent use of properties to allow customization can avoid the trap of copying source code and making changes. As anyone knows who has dealt with the long term consequence of copying and modifying source code, maintenance costs and integration bugs become overwhelming.
Lastly, components can be combined that have been written in different programming languages (provided the underlying component architecture supports this). Microsoft's COM does exactly this, facilitating a market for reusable components that allow much richer applications to be constructed in much less time than ever before. One no longer must spend time converting code from one language to another just to get the functionality trapped in that code.
Components on the Web
With the introduction of scripting languages to the Web, the Internet has been transformed to a dynamic environment supporting sophisticated programming. Particularly with the introduction of Dynamic HTML in Internet Explorer 4.0, the Web is maturing into the user interface framework of choice not only for Web programmers but for any Windows application.
Scripting as supported in Netscape Navigator, for example, fails to provide the mechanisms needed to create true components. This omission severely limits the abilities of programmers to share their work and even costs them in higher numbers of bugs when they try to create large-scale applications employing script.
Scriptlets, a standard feature of Internet Explorer 4.0, fill the gap and make IE4 the target platform of choice for anyone building applications for the Web.
The Scriptlet Architecture
Scriptlets themselves are simply Web pages in which script has been written according to certain conventions. They are used by inserting an OBJECT tag into another Web page. The scriptlet is named by any standard URL. Internet Explorer 4.0 recognizes a scriptlet by marking the tag as using a MIME type of "text/x-scriptlet". Note that there is no CLSID in the OBJECT tag. For example:
<OBJECT width=200 height=123
TYPE="text/x-scriptlet" DATA="Calendar.htm">
</OBJECT>Internet Explorer 4.0 will support this MIME type on all platforms, whether Windows, Apple Macintosh or UNIX. Because of the open nature of the architecture, competing vendors will be able to implement this support as well. There is nothing in the nature of scriptlets that restricts users to Microsoft platforms.
The functionality of a scriptlet can be written in any scripting language (the IE 4 release team has tested scriptlets extensively with both JavaScript and VB Script) including but not limited to Microsoft Jscript and VBScript.
On other platforms, the implementation will have to be somewhat changed, but on the Win32 platform, the Scriptlet MIME type exploits new IE 4 features so that Scriptlets use a COM object to accomplish their work.
This COM object encapsulates the Trident HTML rendering engine and hides most of its functionality, (and in this way it is different from the Web Control object that exposes Trident to its users). Instead, the Scriptlet Component exposes the interface of the Web page scriptlet that is loaded into it.
This exposure is accomplished by loading the page into Trident and letting Trident run the page's script normally. Once completely loaded, the Scriptlet Component is ready to interact with its container. The container in the pure Web case is of course Internet Explorer, but any COM container, including a Visual Basic program or even Microsoft Word, can insert a scriptlet control just like any other ActiveX control.
The Scriptlet Component bridge layer then acts as a broker, passing requests for properties and methods into the scriptlet and passing events out of it. The bridge also performs certain basic housekeeping functions such as negotiating the size of the scriptlet between the Ccontainer and Trident.
Security Considerations
Scriptlets are as secure as Dynamic HTML and script itself. A scriptlet furthermore recognizes when it is placed in a secure container, such as Internet Explorer, and obeys the security policies of its container.
In general, to operate correctly, a scriptlet must be loaded from the same Web server as its container page. These are the same restrictions in force, for example, for Java applets, for example.
How to Write a Scriptlet -- Coding Conventions and Facilities
A Scriptlet can be either an HTML page or an Active Server Page (ASP). You can use any HTML authoring environment you like to create a Scriptlet, such as FrontPage or Visual InterDev. Of course, if your environment does not support scripting, you may have to manually insert the scripting code after first composing the HTML display elements within the environment.
Complete documentation on programming scriptlets will be distributed as part of the InetSDK for Internet Explorer 4.0. That documentation provides complete details on how to use these facilities. This summary introduction (which covers most of the features of scriptlets) will gives you a flavor of how scriptlets operate.
Exposing Simple Properties and Methods
A scriptlet exposes only those global variables, procedures and functions in a scriptlet that you want exposed to containers will be. All you must do is use a prefix ofpublic_ on any variable or function you want exposed. Any global variable with this prefix becomes a readable and writable property of the scriptlet. Any global function or subroutine with this prefix becomes a public method of the scriptlet. Of course, wWhen you refer to the property or method from outside the scriptlet, you do not include the prefix.
For example, you might declare the following in a scriptlet:
<sScript language=jscript>
public_property1 = "'Some text";';
function public_method1(param1, param2)
{
...
some code ...}
You would then refer to these in your container page script as:
Scriptlet1.property1 = "'Some different text";';
a = Scriptlet1.method1(2, "'Still more text");');
Events
Scriptlets can throw two kinds of events: onscriptletevent events and standard window events. The first kind of event can be thrown at any time inside the scriptlet. Standard window events such as mouse clicks cannot be initiated arbitrarily by a scriptlet, but can be thrown in certain circumstances described below.
Scriptlets are considerably more dynamic in nature than traditional programs on Windows. As a result, the development tools are not prepared to understand event types that are only known after the scriptlet has been loaded and parsed. For this reason, scriptlets communicate with their containers through a single type of event: onscriptletevent
One of these onscriptletevent event includes two parameters: a string name and an arbitrary parameter object. An event handler can select how to respond based on the string being passed. The object parameter can then include additional detail about the event itself.
The Sstandard window events supported in a scriptlet arecan only be thrown by propagating an event from an HTML component in the scriptlet. If you write an event handler within a scriptlet that catches, say, the mouse click event for some part of the page, you may 'bubble'propagate it through to the scriptlet's container. It then appears as a mouse click event from the scriptlet with the same event detail information that the scriptlet received.
Context Menus
You can easily create context menus for your scriptlets. These are popup menus that apppear over your component whenever an end-user right-clicks the mouse while the cursor is over the component. You can have one context menu defined for each scriptlet and can replace the menu at any time.
To create a context menu, first create an array of strings. Assign the strings in pairs to successive elements of the array. The first element of each pair is the label string that will appear in the context menu and the second element is the script function to call within the scriptlet when that menu item is selected. When you have initialized the array, call the function window.external.setContextMenu with the array as its only parameter. The next time a user right-clicks over your component, the context menu will appear.
An example of creating a context menu would be:
<script language='vbscript>
sub window_onload
dim a(6)
a(0) = 'Add &Hello'
a(1) = 'Hello'
a(2) = 'Add &Goodbye'
a(3) = 'Goodbye'
a(4) = '&About'
a(5) = 'About'
window.external.setContextMenu(a)
end sub
</script>
Advanced Features
Properties may behave in some ways like a memory location, but often this is not enough. If you have a color property on a component, you want the component to change color as soon as you set the property. Most components need to respond immediately to changes in at least some of their properties.
To support this, component architectures allow you to define functions that masquerade as the property. Scriptlets are no different. If you define a function with either the prefix public_get_ or public_put_ the function acts as if it were supporting a property. For example, the following code shows how functions can be used to implement a property:
<script language=jscript>
property1 = "'some text";';
property1GetCount = 0;
property1PutCount = 0;
function public_get_property1()
{
property1GetCount++; // Keeping track of how
// many times this is called.
return property1; // This is the real work
}
function public_put_property1(new_value)
{
property1PutCount++;
property1 = new_value;
refresh();
}
In this example, the functions simply record how many times each of them gets called (which doesn't get exposed but is presumably used elsewhere in the scriptlet), and after the new value is set in the put function, the component is refreshed in some way. You would now still refer to property1 in the container like any other property:
Scriptlet1.property1 = "'new text";';
a = Scriptlet1.property1;
In the first line above, the public_put_property1 function is called to store the string. In the second line, the public_get_property1 function is called to retrieve it.
If you are writing in JavaScript (and in the future in VBScript), you have the option of a second way to describe your scriptlet's interface. If you define an object with the name public_description in your scriptlet, then its members become the set of named properties and methods exposed to the outside world. The members do not get spelled with the public_ prefix is not used and if you have any global variables or functions with the prefix, they are ignored.
At present, VBScript does not allow you to create objects as Jscript does. In a future release, when VBScript adds support for creating objects, this capability will be available from VBScript as well.
It is largely a matter of style which mechanism you use to define a scriptlet's interface. However, using public_description allows you to succintly describe the scriptlet's public interface in one place, rather than scattering it throughout the scriptlet's code.