| In Part II you learned the AppleScript language. It's essential to know this language if you're going to write AppleScript code; yet, ironically, the AppleScript language on its own won't get you very far. That's because AppleScript, all by itself, doesn't do very much; its real power and purpose lies in communicating with scriptable applications, which provide powers that AppleScript lacks. In order that you, the AppleScript programmer, may harness its powers, a scriptable application extends the vocabulary of the AppleScript language. For example, AppleScript can't make a new folder on your hard drive, but the Finder can; therefore the Finder extends AppleScript's vocabulary, supplementing it with terms such as make and folder so that you can use AppleScript to command it (the Finder) to make a folder. This extended vocabulary is called a scriptable application's terminology . A dictionary is the means by which a scriptable application or scripting addition lets the world know how it extends AppleScript's vocabulary. A dictionary has two audiencesAppleScript and the AppleScript programmer. Let's consider how each of these audiences uses a dictionary:
AppleScript AppleScript uses an application's dictionary at compile time to look up the terms that the programmer uses. In this way, AppleScript confirms that the terms really exist; as they don't exist within AppleScript itself, AppleScript cannot know without a dictionary that the programmer isn't just talking nonsense. At the same time, AppleScript uses the dictionary to resolve the terms into their corresponding Apple event form; otherwise, it wouldn't know what actual Apple event messages to send to the scriptable application at runtime. And it uses the dictionary when decompiling, to translate those Apple event terms back into English-like words for display to the programmer.
The AppleScript programmer The AppleScript programmer studies a human-readable display of a dictionary to learn what English-like terms, beyond those built into the AppleScript language itself, may be used when targeting a particular application, or in the presence of a particular scripting addition. Studying a dictionary to figure out how to use AppleScript to get an application to do your bidding is a major part of the typical AppleScript programming experience. Such study must often be combined with experimentation when the dictionary is insufficiently informative.
The dictionary mechanism pervades the life of the AppleScript programmer in several ways: The dictionary is used by AppleScript for resolution of terminology . Therefore you have to make certain that your script points AppleScript properly to any required dictionaries, and that it can find these dictionaries at key moments (compilation, decompilation, and runtime). The dictionaries of scriptable applications and scripting additions invade the available namespace. This invasion creates clashes between terminology used in one dictionary and another, or between one dictionary and the terms that you, the programmer, would like to use. The result is a high probability that something you'd like to say will be misinterpreted or forbidden. The dictionary is usually your only documentation on how to communicate with a given application. But a dictionary, in and of itself, by the very nature of its format, is almost certainly going to fulfill this function inadequately. To make matters worse, dictionaries are often badly written or downright misleading. You therefore face the paradox of being dependent upon the dictionary for information that may be insufficient, hard to understand, or wrong.
This chapter discusses all these aspects of dictionaries. See also Chapter 3 for the format in which a dictionary is stored and for the implications when a needed dictionary is missing. See "Target" in Chapter 11, and "Tell" and "Using Terms From" in Chapter 19, for details on how the target is determined, how messages are sent, and how AppleScript decides what application's dictionary it will use to resolve terminology. In Chapter 21 I'll talk more about what scripting additions and their dictionaries add to the mix, and in Chapter 27 we'll actually construct a small dictionary to make an application scriptable. Also, see Appendix A for an example of a real programmer struggling valiantly with a real dictionary. |
