By Rick Dobson, Ph.D.
Scriptlets let developers build controls out of Web pages. Developers can use these controls to populate other Web pages, as well as forms in Win32 applications, such as Excel and Word. Because scriptlets rely on Web pages for their control technology, they can deliver all the benefits of HTML and Dynamic HTML (DHTML). Scriptlets provide a particularly rich environment for sharing static and dynamic Web pages based on Access tables and queries. With a little VBScript, developers can also let users locally manipulate a copy of an Access table or query.
This article introduces the basics of designing and applying scriptlets, and clarifies scriptlet architecture. Samples purposefully use VBScript, rather than JScript, so you can see how similar VBScript is to VBA. You'll also learn how to add a scriptlet to a Web page. Beyond that, you'll gain exposure to selected advanced issues, such as exposing methods and properties, passing events, and using scriptlets in Win32 applications. Three samples (available for download; see end of article for details) will provide models for building custom scriptlet applications.
An Introduction to Scriptlets
Scriptlets always rely on at least two files. One of these files is the Web page that comprises the scriptlet. The second is frequently another Web page, which acts as a host for the scriptlet. You will typically be able to directly manipulate the scriptlet file from whatever position it occupies on its host.
Office developers should consider scriptlets for displaying data. Scriptlets permit the display of a table or other information resource from a trusted source. This allows a custom application to reveal data published from an Access database that another user or organization controls. Scriptlets also lend themselves to user-interface applications. In this case, the ability of scriptlets to control responses to clicks, mouse-overs, and other events makes them a valuable resource. Their data binding ability allows users to view and interact with data. Their multi-media versatility (filters, transitions, DirectAnimation, etc.) is another factor that makes scriptlets eminently suitable for user-interface controls. Because all these capabilities can touch on the skills of Office and VBA developers, scriptlets represent an excellent bridge for Office developers to cross as they start delivering services via the Web.
A scriptlet is an object that encapsulates content for reuse. This is the essence of a control. You can embed the scriptlet controls on a Web page or a Win32 form. Use the <OBJECT> tag to incorporate it into a Web page. A new MIME type specifically accommodates scriptlets. Microsoft supports this new MIME type on Windows, Macintosh, and UNIX platforms through Internet Explorer 4 (IE4). With the Microsoft Scriptlet Control that ships with IE4, developers can use scriptlets as ActiveX controls. Scriptlets expose COM interfaces in Win32 environments such as VB, Office 97, and Delphi. These capabilities are significant for Office 97 developers because scriptlets enable them to build custom controls without having to rely on C++ (or even VB) developers. All it takes is a basic understanding of VBScript, which is very similar to VBA, and a working knowledge of the DHTML Document Object Model.
Scriptlet controls can programmatically expose properties and methods to their hosts. Therefore, developers can build controls on host pages and forms that report the properties and change the behavior of scriptlet controls. You can tap the power of scriptlets without having them expose methods or properties, because users can interface directly with the controls on a scriptlet object when it sits on a host page. Scriptlets can also pass standard and custom events to a host page. This feature allows scriptlets and their host to synchronize their behavior. Developers have the option of processing events originating within scriptlets at the scriptlet, host, or both levels. Learn more about the details of exposing scriptlets and passing events in a two-part scriptlet series in the April and May 1998 issues of Microsoft Visual J++ Informant, from Informant Communications Group.
Inserting a Scriptlet on a Web Page
One of the easiest ways for an Office developer to get started with scriptlets is to use them to host static or dynamic datasheets from the Access 97 Publish to the Web Wizard. This allows a developer to expose specific, limited information from an Access database to users who may not have security privileges to open the database. At a very basic level, users can look up contact information for an approved list of vendors. The host application can provide a format for displaying the datasheet that's richer than an HTML or ASP file, because developers can include instructions or dynamic controls on the page hosting the scriptlet.
When there's an explicit need to publish data at fixed intervals (e.g. a monthly sales report), static datasheets from an Access database are a suitable HTML object for a scriptlet. For other applications, such as employee lists, users will want datasheets to reflect the latest additions and deletions. This kind of situation benefits from a dynamic datasheet. Either type of datasheet works in the following sample.
FIGURE 1 shows the first sample scriptlet. It shows a basic HTML table (white insert) on an aqua page. When you want to draw attention to your scriptlet, consider using different background colors on your scriptlet and its host page. Otherwise, use the same background to make them appear to blend into one another. The HTML table came directly from the static publication of the Northwind Shippers table with the Publish to the Web Wizard.
FIGURE 2 shows the HTML code in the host page. There is no VBScript code in this case because the scriptlet publishes a static HTML page. Notice that there is an <OBJECT> block between an <H1> block at the beginning, and an <b> block at the end of the <BODY> section. The object TYPE and DATA attributes are essential. The TYPE setting text/x-scriptlet denotes the object as a scriptlet. The DATA setting points the object to a source file for the object (in this case, a static HTML file generated with the Access 97 Publish to the Web Wizard). Scriptlets work equally well with dynamic datasheets based on ASP files. Notice that the host page can insert text before and after the scriptlet containing the table. The <H1> block denotes some preliminary remarks before the scriptlet and the <b> block inserts additional comments after the scriptlet.
Developers will often find it necessary to adjust the size of the scriptlet window on the host application so that it displays the whole table. The WIDTH and HEIGHT object settings allow the designation of the scriptlet window size in pixels on the host page.
When the table is larger than can reasonably fit on the page, you can create a scriptlet window with scrollbars. Developers have the option of setting the scriptlet SCROLLBAR parameter at design time, or at run time. The following object settings illustrate how to add a scrollbar at design time to the example in FIGURE 1. Notice the SCROLLBAR setting in the last line before the closing </OBJECT> tag. When you set the SCROLLBAR parameter at design time, it becomes necessary to remove the DATA attribute setting from the <OBJECT> tag and replace it with a <PARAM> tag that points to the source file for the scriptlet.
<OBJECT TYPE="text/x-scriptlet" HEIGHT=140 WIDTH=270 >
<PARAM NAME="url" VALUE="Shippers_1.html">
<PARAM NAME="scrollbar" VALUE="true">
</OBJECT>
Working Locally with Access Data
One of the major attractions of DHTML is data binding. This feature lets users interact with data from Access and other sources much more rapidly than with traditional Web/database technologies. The trick that makes this speed boost achievable is a local data cache, or data source object (DSO), that resides on browser workstations. Scriptlets that take advantage of this feature can prepackage Access data for fast, flexible processing over the Internet. Even within an office, this approach offers an important advantage because workstations without Access — or those that can't run Access, e.g. because they use Macintosh or UNIX operating systems — can still use Access data.
Proprietary IE4 HTML extensions enable developers to tap the DSO and incorporate its contents into a Web page. DSOs can provide special functions, such as sorting and filtering, with respect to their local cache. There are several off-the-shelf varieties of DSOs. At least one DSO that ships with IE4 permits the updating of remote data sources from its local cache.
Five DSOs ship with IE4: Tabular Data Control (TDC), Remote Data Service (RDS), JDBC applet, XML, and MSHTML. Each offers advantages that optimize them for different situations. In addition, advanced developers can build their own DSOs through the OLE DB or OLE DB Simple Provider APIs.
The TDC is simple to use and highly compatible with Access. This is because you can easily build a server-side file for it to link to with the TransferText action or method. Use this command in a macro or procedure to create a text file on the Web server with the contents of a table or a query that you want users to be able to link to. Then, create Web pages that point the TDC to the file. The TDC will download a copy of the text file locally and make it available for local processing via its methods.
The RDS control is more sophisticated because it allows a user to update a remote data source, such as an Access database, from a local cache. This process obviates the need for server-side scripting because it creates a connection to the remote data source from the local cache. This DSO requires Internet Information Server, version 3.0 or higher. In addition, RDS requires the specification of search criteria through SQL. Both the TDC and RDS are client-side ActiveX controls, but the RDS also has a server-side component.
The JDBC applet allows users who cannot conveniently reference an ActiveX control (e.g. Netscape browser users) to gain the core benefits of the technology from a client-side Java applet. This DSO interfaces directly with remote data sources, so there is no need to write out a text file. With the JDBC applet, users can also update the contents of a local cache, but not directly update a remote data source (as with the RDS). The JDBC applet is available for download from http://www.microsoft.com/gallery/files/datasrc/.
The XML DSO is also available as a Java applet. You can use this control for classical tabular data like the other DSOs, but what makes it unique is its ability to process complex, hierarchical data in XML format. Reserve it especially for situations that work with nested data, such as order details within orders.
Developers can also create HTML pages that serve as data sources. Simply designate an object element that points to the page with the data. The HTML page with the data must have ID attribute settings for any element containing data. These settings must indicate the field names to which their contents apply.
FIGURE 3 shows a sample application of the TDC in a scriptlet. The scriptlet appears as the white insert on the contrasting aqua host page. Instructions before the scriptlet describe its purpose and function. The scriptlet contains five buttons: Three demonstrate TDC filtering capabilities, and the remaining two highlight sorting functions. Clicking the last button in the top row shows only one record, instead of the three that initially appear in FIGURE 3. This record is the only one with a Shipper ID greater than 2. Clicking the Restore All Shippers button filters the table to show all records with a Shipper ID greater than 0. Because the initial ID is 1, this reveals all records. The Sort by Company button allows a user to rearrange the table records so they appear alphabetically by shipper name. The Sort by Shipper ID button will return them to their native order.
FIGURE 4 shows the host page DHTML underlying the display in FIGURE 3. In spite of the fact that the scriptlet in FIGURE 3 offers significantly more functionality than the scriptlet in FIGURE 1, the host file is no more complicated. All you need is an <OBJECT> tag that references the scriptlet source file. Do this with the DATA attribute for maximum ease of use. You must also specify the text/x-scriptlet MIME type. This setting allows IE4 to recognize the object as a scriptlet. Finally, you want to set the WIDTH and HEIGHT attributes so that they display the table and its controls. Scriptlets do not automatically add scrollbars if the scriptlet window is not large enough to display the Web page contents.
FIGURE 5 presents the DHTML for the scriptlet. This is where all the action takes place. The <HEAD> section contains three blocks. The <TITLE> block simply names the page when a browser views it. The <OBJECT> tag block references the TDC control. One easy way to get this on your Web page is to copy it from another source, such as the Internet Client SDK site (http://www.microsoft.com/msdn/sdk/inetsdk/help/dhtml/content/databind/datasources.htm#ch_databind_tdc_intro). After copying the <OBJECT> tag, modify it so the version in your Web page points to your custom data source (shipperscsv.txt2 for the sample). If your Web page includes any scripts that modify the data in the data cache, you will want to assign a name to the object. The sample does this with the value of mydata for the ID attribute.
Recall that you can create the file that the TDC references on the Web server with the Access TransferText action or method. Either approach generates a delimited text copy of a table or query. This copy starts by default with a row of column headings, which is why the UseHeader setting is True. You will want these headings to designate your field names. The third block in the <HEAD> section includes scripts. The commentary for the button controls discusses these scripts.
The <BODY> section contains a table and five buttons. The table is an HTML element that references the mydata DSO with special HTML extensions. The DATASRC attribute references the TDC DSO by its ID setting. Syntax conventions require a pound-sign character ( # ) before the DSO ID. Use the DATAFLD attribute inside a <DIV> block to reference individual fields. This <DIV> block should be in a <TD> block within the HTML table. HTML delimits table cells inside of <TD> blocks. When you reference the special data binding extension attributes, the table knows to repeat for each row of data in the local cache. Another HTML extension lets you specify a page size of rows to show at one time. This allows users to navigate through subsets of rows — just as they can move through individual records with a form display.
The five buttons reference the VBScript procedures in the <HEAD> section for manipulating the data in the local cache. The DHTML code accomplishes this with classic event procedure naming practice. Give each HTML input button a NAME attribute. Then, create Sub procedures for each button. Name the procedures with the button name and the suffix _onclick. Whenever a user clicks a button, the page automatically invokes the corresponding Sub procedure.
The design of the Sub procedures in the <HEAD> section is very basic. First, they set a property. This is either the filter or the sort criterion. Second, they invoke the reset method for the DSO. This applies the method to the DSO with the new property setting. It is this second step that updates the display of the HTML table in the scriptlet.
Dynamic Pictures
One of the coolest features of DHTML is how it handles transitions. Developers can choose one of 23 transitions to migrate from one image to the next. Each transition corresponds to a number from 0 through 22. The transition number of 23 offers a random selection from the total suite of transitions. These transitions mimic PowerPoint slide transitions with names such as Box in, Vertical blinds, and Checkerboard across.
To invoke a transition, specify a transition number, a duration, and a new image source. The transition takes the old image and replaces it with the new one over the specified interval. FIGURE 6 shows a transition in action. When the host page loads, it shows the scriptlet with a company logo and two buttons over a heading (see the left panel in FIGURE 6). Clicking either button causes a transition from the company logo to a picture of one of two company principals. The middle screen shot reveals the Checkerboard across transition in midstream. The right panel displays the completed transition. Clicking the other button replaces the current image with the new image for that button.
The host page models the two previous ones. This page points to a DHTML page with the objects and scripts to make the transition work. It also sizes the scriptlet window on the host page to show the image, buttons, and instructions. Because it follows exactly the pattern of the previous two host files, I don't present it here.
The scriptlet file code appears in FIGURE 7. The <BODY> section includes four major HTML elements: the image, heading, and two buttons. The <IMAGE> tag specifies the initial source as cablogoc1.gif. This is the company logo. This <IMAGE> tag also contains an inline STYLE setting. The STYLE setting specifies the transition type and duration. The transition settings apply to the <IMAGE> tag. The two buttons both invoke the doTrans procedure in the <HEAD> section. The only difference is that one button passes RickD.gif, while the other button passes virginia.gif. These .GIF files correspond to pictures of the two principals.
The doTrans procedure implements the transition. It takes just three lines of VBScript to make the transition work on a page. First, invoke the Apply method for the transition filter on the image. Second, specify a new Source property for the image element. This is the new picture. Third, invoke the Play method. This launches the transition from the current image to the new one.
Conclusion
Scriptlets deliver at least four major benefits to Office 97 developers. First, you can extend the reach of your Access databases by packaging them for use beyond Windows computers, such as those running Macintosh and UNIX operating systems. This is possible because IE4 runs under these operating systems, and scriptlets technology is available to all versions of IE4. Second, Office developers gain access to all the DHTML capabilities, including data binding, multimedia effects, as well as dynamic style, content, and position. Third, you can encapsulate your code for easy reuse by you and other developers. Fourth, the fact that you can code scriptlets with VBScript, a VBA look-alike, makes it simple for Office developers to transition to scriptlet development.
There is a lot more to scriptlets than any one article can cover. However, this presents a basic starter kit that can get you developing with them right now. The samples present three typical ways of applying scriptlets. You can apply any of them simply by swapping out the sample data or image files with those for your business. Anyone with average Office development skills and some Web exposure should be able to use these samples.
Learn more about the DHTML feature set in general, and scriptlets in particular, from the Internet Client SDK (http://www.microsoft.com/msdn/sdk/inetsdk/help/default.htm). This site will give you great exposure to development techniques with lots of samples to back up the general principles. Visit the CAB site (http://www.cabinc.win.net/) for a white paper and a presentation on DHTML. This site also has several collections of DHTML and scriptlet samples. Finally, as I mentioned earlier, look at Microsoft Visual J++ Informant (April and May, 1998) for two informative articles on how to build scriptlets, expose methods and properties, and propagate events from scriptlets to their hosts.
Download source code for this article here.
Rick Dobson, Ph.D., is president of CAB, Inc., a database, Office and Web consultancy. His byline appears in many publications, including Byte, NetGuide, and Visual Basic Developer. He is also a contributing editor to Microsoft Interactive Developer.