Section 2.8. Automator

2.8. Automator

Automator is a utility application, new in Tiger, that allows the user to construct a script (called a workflow ) from a series of steps (called actions) in a graphical interface without knowing a programming language. The default actions are in /System/Library/Automator/; additional actions may be installed into /Library/Automator/ or ~/Library/Automator, or they may be included in an application's bundle, where Automator can see them directly. Workflows can be saved as files to be run by Automator, as applications to be run independently (rather like an AppleScript applet), or as plug-ins for use by various applications: for example, a workflow saved as a Finder plug-in becomes a Finder contextual menu item, and a workflow saved as a Script Menu plug-in becomes a menu item in the Script Menu.

The default actions include a Run AppleScript action , which lets the user incorporate AppleScript code directly into a workflow. Even more interesting, an Automator action can easily be written using AppleScript, and instructions for doing this appear in Chapter 27. An action is a useful way to distribute a piece of AppleScript code to users. You can't know, after all, exactly what a user would like to do with your code, and some users don't understand programming well enough to customize AppleScript code in a script editor themselves. An Automator action can help to solve these problems. An action can easily be positioned among other actions in a workflow that the user constructs in order to achieve a desired result. Furthermore, an action has a graphical interface, which lets the user set various parameters to the AppleScript code without coming into direct contact with that code.

Figure 2-9 shows a simple Automator workflow; it puts up a dialog asking the user to chooose a folder, and lists the pathnames of the items within that folder into a new TextEdit document. Notice the graphical interface that allows the first action to be customized so that the dialog asks for a folder, not a file. Notice also the dataflow paradigm that links the actions: each action produces an output, which functions as the input to the next action in the sequence. The second action produces a list of files and folders (as aliases), but the third action expects text; nevertheless the workflow succeeds because Automator coerces from one type to another as necessary (here, turning a list of aliases into POSIX pathnames separated by return characters).

Automator is in its infancy as of this writing, and it shows. The interface is extraordinarily clumsy: among other things, it's difficult to find the action you want, because the interface, in a misguided attempt to make this easier, causes the order in which

Figure 2-9. An Automator workflow

actions are listed to change constantly (and there's no way to see them simply listed in alphabetical order). There is no provision for branching or looping, so workflows are necessarily very simple. Worst of all, Automator suffers from a serious dearth of useful actions. This, however, is a shortcoming that you, the AppleScript programmer, are in a position to correct. For example, Figure 2-10 shows a workflow that gets the song currently playing in iTunes, retrieves its name, and shows that name as the iChat status message seen by online buddies. (This particular workflow isn't really needed, as iChat now has an option to show the currently playing song as its status message automatically.) Automator doesn't include an action to get an iTunes song's name, nor does it include any actions having to do with iChat. These omissions, however, are easily remedied: I wrote those actions myself, in about five minutes. After you've read Chapter 27, you'll be able to do the same.

Figure 2-10. An Automator workflow involving two homemade actions