2.2 Scripting Environment

The term scripting environment is meant to denote a small class of applications dedicated primarily to letting the user edit and run scripts in some language other than AppleScript, while secondarily providing a way to enter and run AppleScript code.

In the pre-Mac OS X world, a good example of such a program was HyperCard. HyperCard's main purpose was to allow the user to construct an interface and to associate scripts with the elements of this interface; for example, one could write a script to be run when a button was clicked. These scripts were usually in HyperCard's own internal scripting language, HyperTalk; but each script had a popup menu allowing it, alternatively, to use other available languages such as AppleScript. This was very handy because it meant you could use HyperTalk for the things HyperTalk was good at (such as driving the HyperCard interface) and AppleScript for the things AppleScript was good at (such as driving other scriptable applications).

A similar program is UserLand Frontier. Frontier also has a much less expensive "little brother," Radio UserLand; for our purposes the two programs are interchangeable. Frontier is meant to store and run scripts in UserLand's own scripting language, UserTalk; but a Frontier script can use other available languages, including AppleScript.

(The reason HyperCard and Frontier can "see" and incorporate AppleScript is that these are OSA-savvy applications: they can see and incorporate any OSA language, and AppleScript is an OSA language. Section 4.2 explains what this means.)

Figure 2-5 shows some AppleScript code being run in Radio UserLand. The AppleScript code is in the middle window, the one whose language popup (at the bottom of the window) is set to AppleScript. You should ignore the triangles at the left of each line, which are a feature of Frontier's outline-based script editing environment. In Figure 2-5, the UserTalk code in the bottom window calls the AppleScript code in the middle window and displays the result in the top window. The purpose of this arrangement is to show you how UserTalk and AppleScript can interact transparently in Frontier.

Figure 2-5. Radio UserLand

There isn't usually much need for this interaction, however, because UserTalk all by itself can drive scriptable applications through Apple events, just as AppleScript can. To prove this, Figure 2-6 demonstrates UserTalk obtaining the same information from the Finder (the name of every mounted volume) without any AppleScript at all. The UserTalk code generates and sends to the Finder the very same Apple event that AppleScript would generate and send; the Finder's experience is identical regardless of whether the user employs AppleScript or UserTalk to communicate with it.

Figure 2-6. How Radio UserLand expresses Apple events natively