AppleScript_ The Definitive Guide - Matt Neuburg [179]
Script Debugger is more helpful. The listing for a class in Script Debugger can include its inherited attributes. Thus you are shown all of a class's properties in one place. Another nice feature of Script Debugger is that it graphs each of an application's inheritance hierarchies (Figure 20-5). (Script Editor can display classes organized by inheritance in its browser, but it shows only the single hierarchy starting with the item class, if there is one.)
Figure 20-5. Script Debugger's display of the Finder's class inheritance hierarchies
Elements (as well as properties) are inherited by subclasses, but most application developers do not bother to take advantage of this in constructing the dictionary. For example, in the Finder the elements of the folder class are exactly the same as the elements of the container class; yet the dictionary explicitly repeats them in both classes—it does not, as it does for properties, include them only in the container class, even though this would be perfectly sufficient, as the folder class would inherit them.
Properties and Elements
A class can have two kinds of attribute: properties and elements (compare "Properties and Elements" in Chapter 11). A class's properties and elements are part of that class's listing in the dictionary.
A property in the dictionary involves two four-letter codes—one for the property's name and one for its value type (see "Value Types," earlier in this chapter). If a property name is the same as the name of a property defined by AppleScript, they should have the same four-letter code. For example, in the Finder the item class's name property has the four-letter code 'pnam' and a value type 'utxt' (Unicode text); the code 'pnam' matches the code for the name property defined by AppleScript itself. A property can be specified as read-only ; this is displayed in Script Editor as "[r/o]", and in Script Debugger as "get" (as opposed to "get/set").
An element in the dictionary is the four-letter code of a class (see "Classes," earlier). Thus an element name in the dictionary display is a class name. The dictionary can also provide the forms of element specifier that may be used to access this element; in the Tiger Script Editor this information is stripped from the dictionary display, but Script Debugger includes it (contrast Figure 20-2 with Figure 20-3). An element can also be specified as read-only; this is much rarer than a read-only property. Script Debugger marks such an element as "get" (as opposed to "get/make/delete," the default).
The complete schema of a scriptable application's properties and elements constitutes its object model (see "Attributes" in Chapter 11). The object model is what makes it possible to refer to any actual object within the application. In theory, all actual objects should be connected as a kind of tree, which should be navigable in its entirety starting at a single point—namely, the application itself, the only thing to which you have a reference when you start targeting that application—and it should be possible to deduce this tree correctly from the dictionary. The tree should start at the application class. For this reason, the application class is usually the first thing you'll turn to when you begin your study of an application's dictionary.
In real life, things are not so simple, for various reasons. Objects can be mutually linked as elements of one another; class inheritance can muck up the tree; there can be more than one tree, with orphaned classes; there can be shortcuts, sometimes undocumented, that jump through levels of the tree implicitly; and the dictionary can simply lie ("Defects in the Object Model," later in this chapter). Nevertheless, the object model is one of your basic keys to successful scripting of an application,