Page 2 of 6
In this section, you will find no reference to scripting support. Remember, this is done deliberately in order to demonstrate that you can add scripting support to an application designed without any prior consideration for scripting.
The application has a frame containing a drawing surface and a menu bar. The menu bar has options for clearing the drawing surface and switching between various shape modes. The drawing surface provides a simple mouse interface; a new shape object is inserted into the drawing area that is bounded points at which mouse is pressed and released. It is not the most intuitive user interface, but a more advanced UI would have shifted the focus away from the main goal of this article -- to demonstrate the incorporation of the scripting facility.
SlateApp, the application's main class, sets up a JFrame with a menu bar and slate components in it. SlateAppMenuBar, the menu bar for the application, extends JMenuBar, adding a few simple menus for clearing the drawing surface and switching between modes to draw various shapes.
(Source code for these first versions of the SlateApp.java and SlateAppMenuBar.java classes is available to download.)
This completes the first step. Now we have an application with no scripting support. This application lets users create simple pictures by drawing rectangles, ovals, and lines via a mouse interface. It also allows the whole drawing surface to be erased. While this application is useful for simple drawings, it is not adequate for creating complex drawings.
Increasing interest in Java's "write once, run anywhere" promise has made it the language of choice for many new scripting-language interpreters. Most of these interpreters allow interaction with Java objects by the scripts. If we embed such interpreters in our Java application, scripts can interact with the application's objects. Thus, to enable scripting support for Java applications, we need to embed the interpreter so that it either runs in same virtual machine as the application, or can interact with the application's objects in some other fashion. We also need to make the application's objects available to the interpreter.
Scripting languages vary widely in their capabilities and suitability for particular tasks. In addition, users frequently prefer one scripting language over another -- many times due to nontechnical reasons. As such, applications should not force users to learn a new scripting language; rather, they should support multiple languages. This enables users to write their scripts in any of the supported languages, which results in higher user satisfaction. Keep in mind, though, that while such support for multiple language is a desirable goal, it is also desirable that such support should require a minimal per-language development effort. A well-designed scripting framework can help achieve both of these goals.
For the purpose of this article, I have chosen to provide support for four popular languages: JavaScript (ECMAScript), Python, Tcl, and Scheme. JavaScript, with its Java-like flavor, is popular for dynamic Web page creation. It also supports some object-oriented features, which makes interacting with Java more natural. Python is another popular object-oriented scripting language that is easy to learn. Tcl is a scripting language designed specifically to provide scripting extensions to applications. Scheme, a compact and elegant dialect of LISP, supports functional programming concepts.
slate, scripting, version1, version2, and version3. The README.txt provided in the top-level directory includes instructions for running the precompiled applications and explains the role
of each package