Dr. GUI
November 10, 1997
Last week, Dr. GUI explained how to use Dynamic HTML to create user interfaces in applications—even applications that aren't Web-based. The good doctor spoke of how flexible Dynamic HTML is (you can change anything, even the text, on the fly), and how to manipulate a document by manipulating the object model—changing, adding, and deleting objects.
This week, Dr. GUI would like to continue by telling you about the various options that you have to take advantage of scripting. You can do this in your Dynamic HTML pages and in new Dynamic HTML objects called "scriptlets." You can even take advantage of scripting engines in your applications—an easy way to provide your users with a scripting language.
If you've used the Web much at all, you've run into Web pages that contain script. Script is used to validate your input, change the behavior of buttons and other HTML form controls, and to link HTML form controls, ActiveX controls, and Java applets. With the combination of ActiveX controls, Java applets, and script, Web pages can do quite a bit.
Before Dynamic HTML, though, scripting was quite limited: in general, you could not change the appearance or contents of the document once it was rendered. That means that it was not possible to do most mouse-over effects, let alone wholesale changes to the style and content of the page on the fly. Now that Dynamic HTML exposes an object model that allows you to change anything on the page, scripting is much more powerful than it was before.
Most of the script you've looked at (and perhaps written) has probably been client-side script. Client-side script is part of the HTML document—so it's downloaded into the client's browser. The client's browser interprets and executes the script. Note that the good doctor said "interprets"—the script is sent as source text, so the browser actually has to parse the source code before it can execute the script.
It's easy to find examples of client-side scripting—just note any Web page that says it requires VBScript, JavaScript, JScript, or ECMAScript. Once you're viewing such a page (go to http://www.microsoft.com/scripting/, then click on the Samples link), use the View Source command in your browser to view the HTML source for the page—including all of the script source code. As you all well know, you can learn a lot about programming by looking at other people's code.
Unfortunately, there is no way to hide the script source code—so you probably want to use some other technology, such as ActiveX controls, to hide your proprietary logic. (Every silver lining has its cloud, it seems.)
Check out http://www.microsoft.com/scripting/ for more information on client-side scripting. And note that since client-side script is embedded in the HTML page, you can use it even in applications that aren't Web-based (but which use Dynamic HTML, as discussed last week).
Even more common is server-side scripting. In server-side scripting, the server interprets and executes the script in the .ASP page (ASP stands for "Active Server Page") before it delivers the HTML page to the browser. Like client-side scripting, the script source code is coded in the ASP page. However, this code is never sent across the wire to the browser; instead, the server interprets and executes the code and sends the resulting stream to the browser.
Microsoft's Web sites use server-side scripting all over the place. Perhaps the coolest use of server-side scripting (not to mention database/Web integration) is sidewalk.com, at http://www.sidewalk.com/. But even the Microsoft home page (http://www.microsoft.com/) uses server-side scripting extensively.
One key advantage of server-side scripting is that you can deliver very customized pages without requiring any scripting intelligence on the client side. In fact, the server-side script can even deliver different custom pages to each user based on browser capabilities, user preferences, server-side includes of text, and current contents of a server-side database. It's even easy to build pages and/or sets of pages that contain repeating rows of database data. But server-side scripting doesn't make any sense unless you're delivering the pages from a Web server, such as Internet Information Server (for Windows NT Server) or Personal Web Server (for Windows NT Workstation and Windows 95).
Check out http://www.microsoft.com/iis/default.asp for more information on Active Server Pages and server-side scripting.
Dr. GUI's terminology has been quite generic in referring to scripting above. Of course, you well know that all script has to be coded in some specific scripting language. Scripting languages are a key area in HTML where Microsoft offers a true choice: whereas "the other browser" supports only one scripting language (JavaScript—and not the most up-to-date, standardized version at that), Internet Explorer's ActiveX Scripting supports both VBScript and JScript. In addition to supporting two scripting languages, Microsoft's scripting architecture is modular and open, so that other scripting languages can be used. Internet Explorer supports both scripting languages on all platforms where Internet Explorer runs, including Windows 3.1x, Macintosh, and UNIX. (Note that Internet Explorer 4.0 is in prerelease for all these platforms now—see the Microsoft Internet Explorer Web site [http://www.microsoft.com/ie/]).
Because both client-side and server-side scripting use ActiveX Scripting, all scripting languages are supported on both the client and server sides when you're using Microsoft client and server software. If you'd like to write your own scripting engine to work with any ActiveX Scripting Host (such as Internet Explorer and Internet Information Server), check out http://www.microsoft.com/msdn/sdk/inetsdk/help/compdev/engines/engines.htm#ch_script_engine.
VBScript is the simpler of the two scripting languages currently offered. It looks a lot like Visual Basic and it's about as easy-to-learn as Visual Basic. So it's the obvious choice for beginners to scripting.
The downside of VBScript is that it's not supported at all on the other browser—so HTML pages that use client-side VBScript are for Internet Explorer only. However, on the server side the limitations of down-level browsers don't matter—so VBScript is a great choice for server-side script no matter what browsers your users have.
Check out http://www.microsoft.com/vbscript/ for more information on VBScript.
First off, let's get these names right. JScript is the name for the Microsoft implementation of the scripting language that's also known as JavaScript and ECMAScript. As you probably know, JavaScript is not Java—its roots are much closer to C/C++ than to Java. However, for marketing reasons, Netscape chose the name JavaScript rather than LiveScript, which is what it had been called before.
ECMAScript is the new name for the scripting language that meets the ECMA-262 standard. (ECMA stands for the European Computer Manufacturers' Association.) The standard is based on JavaScript with additional input from both Netscape and Microsoft.
Microsoft's JScript 3.0 is the most up-to-date implementation of ECMAScript available—as of this writing, it's the only implementation that is 100% ECMA-262–compliant. It's the most advanced implementation available—and it has a few features, such as conditional compilations and some language extensions, that go beyond ECMA-262. These new features have been submitted to ECMA for consideration for a future version of the standard.
Writing your client-side script in ECMAScript/JScript is a good idea because if you're careful about how you write the script source code (and if you test a lot), you can probably get the same script to run under both Internet Explorer and down-level browsers. If you do this, you will want to make sure you don't use new features. JScript offers several features that VBScript doesn't yet offer, so it's the more powerful of the two. But it's a bit harder to learn than VBScript.
Check out http://www.microsoft.com/jscript/ for more information on JScript and ECMAScript.
Perhaps the most exciting component news for both Web and non-Web developers in Internet Explorer 4.0 is that Internet Explorer now supports what Microsoft calls "scriptlets."
A scriptlet is very simple: it's just a Web page that you can embed in another Web page—or, for that matter, in any Windows application that can host an ActiveX control. Scriptlets expose a public interface of methods, properties, and events just like any ActiveX control—the difference is that any Dynamic HTML programmer who can write script can also write scriptlets, and thereby participate in the creation of reusable components.
Only the variables, procedures, and functions that have "public_" prepended to their names can be accessed by the scriptlet's container. (In JScript, you can gather all of the interface declarations into one "public_description" section.) Events are thrown using a single onscriptletevent event that passes parameters to the container. And, of course, it's possible to have functions implement properties by prepending "public_get_" and "public_put_" to the function names.
Scriptlets are incredibly powerful for building components. These components can be used in Web pages, saving a lot of the cutting and pasting (or server-side includes) that Web programmers do today. Since scriptlets are cached by the browser, they give much better performance by reducing the download size and bandwidth requirements—once a scriptlet is downloaded, it stays in the user's cache, eliminating the need to download that functionality over and over. And because scriptlets use the power of Dynamic HTML, they tend to be considerably smaller than either ActiveX controls or Java applets.
But scriptlets aren't just for Web pages: under Windows, any scriptlet is considered an ActiveX control (just as Java Beans are ActiveX controls). That means that you can use scriptlets any place you could use any other ActiveX control—in Visual Basic, Visual J++, Visual C++, even in Microsoft Word and Microsoft Excel. Any application that can host an ActiveX control can host a scriptlet. What a great way to take advantage of the power of Dynamic HTML and scripting in your Windows applications, huh?
Check out http://www.microsoft.com/msdn/sdk/inetsdk/help/scriptlets/scrlt.htm for more information on scriptlets. And be sure to check out the scriptlet gallery at http://www.microsoft.com/sitebuilder/gallery/files/scriptlets/default.htm.
Dr. GUI has noticed that a number of you seem to have a psychological condition he calls "VBA Envy." The cause is looking at the wonderful capabilities in Word, Excel, PowerPoint, Access, and Visual Basic that VBA (Visual Basic for Applications) gives you.
Now, it is possible to license Visual Basic for Applications for your applications—and many companies do this. There are even companies that will help you integrate VBA into your application. For more information, check out http://www.microsoft.com/vba/.
But if your scripting needs are simpler, you may be better off simply making your application an ActiveX scripting host so that you can host VBScript, JScript, and any other ActiveX scripting engine. The very modular design of Internet Explorer comes to the rescue again—it's not only possible to write your own scripting engines, but you can also write your own scripting hosts!
It's not trivial to do this (you have to develop and expose an object model, for one thing—but you might have an object model already developed for automation purposes), but it's not the hardest programming task in the world, either. And it can give your application extremely powerful scripting capabilities with reasonable effort on your part.
The Windows Scripting Host uses this technique today to allow you to use any ActiveX scripting engine to automate Windows operations, either from the command line or from a Windows-based host. The Windows Scripting Host will be included in Windows 98 and in Windows NT 5.0.
Check out http://www.microsoft.com/msdn/sdk/inetsdk/help/compdev/scripting/hosts.htm#ch_script_host for more information on making your application a scripting host.
So, what should you do about scripting?
First, play around a bit with client-side scripting. It's a powerful tool to help you develop user interfaces in Dynamic HTML. And even if you decide to implement the scripting code in your application by directly manipulating the document object model instead, scripting is great for developing and testing prototypes.
Second, if you do Web-based applications, get familiar with server-side scripting and Active Server Pages. These technologies—especially when they generate Dynamic HTML pages for Internet Explorer 4.0—will really revolutionize the way you do Web programming. Visual InterDev (http://www.microsoft.com/vinterdev/) is a great tool for helping you write Active Server Pages—and it's a standard part of Visual Studio.
Third, check out scriptlets. Scriptlets are a great way to develop low-cost, small, powerful components you can use everywhere: in Web pages and in ActiveX control containers. They give you all the ease of development of a Web page combined with the power of Dynamic HTML and ActiveX. It's darn hard to find folks who can develop ActiveX controls in C++, so if you have some controls that could reasonably be implemented as scriptlets, that can be a big win in terms of getting your products to market faster.
Lastly, consider whether your application would benefit from having scripting capabilities—and if it would, whether implementing Visual Basic for Applications or just implementing the COM interfaces and object model necessary to be an ActiveX scripting host is the way to go.
And for more information, check out some of the great articles on the SiteBuilder Network, especially Bob Jervis's "Scriptlets: Reusable Objects for Web Authors" and the Internet Client SDK (http://www.microsoft.com/workshop/prog/inetsdk/). Don't forget the Microsoft Script Library at http://www.microsoft.com/scripting/ (then click on the Microsoft Script Library link), and be sure to take a look at Nancy Winnick Cluts's "All About Scripting," on the MSDN Library.