AppleScript_ The Definitive Guide - Matt Neuburg [46]
There are two additional modes (or levels, or aspects) whereby an application can be scriptable:
Recordable
An application is recordable if it can generate AppleScript code when the user performs ordinary actions in its graphical user interface. This ability can be useful for helping the programmer learn to script the application. There is no way to find out whether and to what extent an application is recordable, other than by trying to record it.
Attachable
The term attachable is somewhat ambiguously defined. Strictly, an attachable application is one that allows the user to customize, by means of a script, what happens when the application receives an Apple event. But it may also be said that an application that allows the user to customize any of its event responses through a script is attachable.
Recordability
As an example of a recordable application, let's take BBEdit. In a script editor application such as Script Editor or Script Debugger, make a new script window, and choose Script → Record (or press the Record button). In BBEdit, press ⌘-N to make a new window. Back in the script editor application, choose Script → Stop (or press the Stop button). In the the script window, the following compiled script has appeared:
tell application "BBEdit"
activate
make new text document
end tell
BBEdit has recorded the actions you performed; you switched to it and made a new window, and BBEdit has provided the AppleScript code you would have to execute in order to cause the same actions to occur through a script. Obviously, this can be a good way to learn how to script an application. A scriptable application, in effect, has two interfaces: a graphical user interface and the scripting interface. But it isn't always obvious how they intersect. What would I have to say to BBEdit using AppleScript to get the same effect that I see when I press ⌘-N? Recording that action answers that question. Unfortunately, very few applications are recordable (far fewer on Mac OS X than in previous systems).
Recording is implemented partly by AppleScript and partly by the scriptable application. Pressing the Record button in a script editor application signals to AppleScript that it should start watching for recordable events. When it sees a recordable event, AppleScript decompiles it and sends the decompiled text to the script editor application, which displays the text.
But precisely what constitutes a recordable event? The answer turns out to be surprisingly simple: it's any Apple event that an application sends to itself. In fact, an application is allowed to send itself a "fake" Apple event just so that if recording happens to be turned on, this Apple event will be detected and treated as the AppleScript equivalent for whatever else is occurring in the application.
The developers of an application can elegantly implement both scriptability and recordability by factoring the application as they develop it. A factored application is one that responds to events in the graphical user interface by sending itself Apple events. So, in BBEdit when you press ⌘-N (or choose File → New), BBEdit does not simply obey by creating a new text window; rather, it sends itself the Apple event that commands a new text window to be created. BBEdit then receives this Apple event—and that is what causes it to create a new window. Under this factored architecture, it makes no difference whether a user presses ⌘-N or a script says "make new text document"; BBEdit ultimately receives the same Apple event in either case, without knowing or caring whether it came from its own graphical user interface or from a script. Picture a factored application as being scriptable at a deep level, with the user interface