| rdfs:comment
| - The AppleEvent Object Model (AEOM) was a set of protocols built on top of Apple Events by which applications running under Mac OS could control each other's functions. Unlike other similar-sounding concepts such as ToolTalk, there was a clear, orthogonal distinction between nouns and verbs; thus, instead of providing separate commands for "close document" and "close window", there was a single "close" verb which could take references to "document" and "window" objects, among others. For instance, consider the following AppleScript sequence controlling a fictional drawing application:
|
| abstract
| - The AppleEvent Object Model (AEOM) was a set of protocols built on top of Apple Events by which applications running under Mac OS could control each other's functions. Unlike other similar-sounding concepts such as ToolTalk, there was a clear, orthogonal distinction between nouns and verbs; thus, instead of providing separate commands for "close document" and "close window", there was a single "close" verb which could take references to "document" and "window" objects, among others. Applications that implemented some part of the AEOM were called scriptable, because they could be controlled via AppleScript. Unfortunately, scriptability support remained patchy and inconsistent throughout the history of classic Mac OS. The objects that an application made available through its AEOM support were arranged in a hierarchy. At the top was the application itself, referenced via a null object descriptor. Other objects were referenced by (recursively) specifying their parent object, together with other information identifying it as a child of that parent, all collected in an AERecord. Each object could have elements and properties; elements were other objects, which might be created or deleted, while properties could not be created or deleted but had values which might be interrogated or changed. For instance, the application might have one or more window objects representing windows showing the contents of currently-open documents. These windows might have properties such as their title, position and size. An application could define custom verbs for operating on its objects. But the AEOM also specified various standard verbs which (it was hoped) applications would implement in a consistent fashion, such as open, close, create element, delete, set data, and get data. Each verb was defined as an AppleEvent of a specific type and class, together with particular parameters of particular types that were expected to be present. For instance, the "get data" event was the standard means for obtaining the value of a property: it took essentially one parameter, which was an object descriptor identifying the property to be queried. The value of that property would be returned in the reply event. The "set data" event took two parameters, the object descriptor for the property to set and the new value for the property; the reply event was only expected to return a success status or failure error code. Note that the entire AppleEvent architecture identifies things using four-byte OSType codes, studiously avoiding actual words or phrases in English (or any other language). Instead, the correspondence between internal AppleEvent codes and external natural-language descriptions is specified through the 'aete' (AppleEvent Terminology Extension) resource -- the "extension" being to the standard terminology built into AppleScript itself. An application may provide multiple 'aete' resources for multiple languages, in keeping with the original multilingual design of AppleScript itself For instance, consider the following AppleScript sequence controlling a fictional drawing application: tell application "ScriptableDraw" set background colour of window "New Drawing" to background colour of window "Old Drawing" end tell This actually involves the sending of two AppleEvents to the target application (and the receipt of their corresponding replies): first, a get-data event is sent to retrieve the background colour property of the window identified by the name "Old Drawing"; then a set-data event is sent to apply the value returned as the background colour property of the window named "New Drawing". Object descriptors allowed the identification of objects in various ways. The most interesting one was using a where-clause (which translated into AppleScript terminology as a filter expression). For instance, the AppleScript 1.0 SDK shipped with the source code for an example application called the Scriptable Text Editor, which would respond to scripts such as tell application "Scriptable Text Editor" tell window "Example Document" set text style of every word whose length > 7 to bold end tell end tell Even today, it is rare to find this kind of power in general-purpose scripting languages outside of SQL.
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)