AppleEvent Object Model
Encyclopedia
The AppleEvent Object Model (AEOM) was a set of protocols built on top of AppleEvents by which applications running under Mac OS
could control each other's functions. 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 AEOM provided a syntactic layer under which any application could publish its internal objects, allowing those objects to be manipulated in a standardized way. 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" or "window" objects, or any other object that the application published.
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. An iterator was provided by parents to enumerate their children, or children of a certain class, allowing applications to address a set of elements. The system was generally similar to the Document Object Model
used in XML
, although with some differences in access patterns.
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 elements 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. 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.
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:
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 color 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 color property of the window named "New Drawing".
Since this sort of access pattern was typical, AppleScript made widespread use of the
or Pascal. All commands after the
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:
Even today, it is rare to find this kind of power in general-purpose scripting languages outside of SQL
.
Adding support for the AEOM in the "classic" Mac OS
was a difficult process. Application developers had to identify their objects and hand-write code to allow them to be addressed. This typically took the form of code for returning the "next" object of a particular type, allowing AppleScript to iterate over them. But since the OS did not contain an object model, this work was left entirely to the developers, many of whom did not implement it. Oddly, even Apple's own application framework
, MacApp
, did not offer such a model except for the GUI
objects it knew about, once again making the developer do most of the work of scripting the objects representing the data itself. Largely for these reasons, AppleScript support was not very widespread.
Apple did attempt to address this problem with the introduction of various object "suites", which represented standard objects and verbs that were expected to be supported by different types of applications. For instance, all applications were expected to support the "core suite", and any application editing text was expected to support the "text suite". By selecting a suitable set of suites, the developer could at least reduce the workload of planning how to expose their objects. Yet because these objects were generally not part of the system itself (with the exception of the severely limited TextEdit editor), the actual implementation was left to the developer.
Applications developed in Cocoa
, the system formerly known as OpenStep
, offer a rich object runtime that can be queried from any other application. This makes implementation of the AEOM considerably easier, dramatically reducing the amount of code needed in the average application. Additionally the majority of Cocoa applications are constructed primarily from Cocoa-standard objects, all of which were upgraded to offer fairly extensive scriptability. This extends not only to GUI objects as under MacApp, but also to data objects inside them, including text, tables and various list objects. A text file is used to map the internal "object-like" names onto human-readable
versions, and in most cases creating this is all that is needed to add fairly substantial scriptability to most programs.
While Cocoa applications are not AEOM based, and often use subtly different objects than Apple's originally defined standard objects, Cocoa apps are generally much more scriptable than their "classic" counterparts—in fact, it is uncommon to find a Cocoa application that is not scriptable to some degree.
Mac OS
Mac OS is a series of graphical user interface-based operating systems developed by Apple Inc. for their Macintosh line of computer systems. The Macintosh user experience is credited with popularizing the graphical user interface...
could control each other's functions. Applications that implemented some part of the AEOM were called scriptable because they could be controlled via AppleScript
AppleScript
AppleScript is a scripting language created by Apple Inc. and built into Macintosh operating systems since System 7. The term "AppleScript" may refer to the scripting system itself, or to particular scripts that are written in the AppleScript language....
. Unfortunately, scriptability support remained patchy and inconsistent throughout the history of classic Mac OS.
The AEOM provided a syntactic layer under which any application could publish its internal objects, allowing those objects to be manipulated in a standardized way. Unlike other similar-sounding concepts such as ToolTalk
ToolTalk
ToolTalk is an interapplication communications system developed by Sun Microsystems in order to allow applications to communicate with each other at runtime...
, 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" or "window" objects, or any other object that the application published.
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. An iterator was provided by parents to enumerate their children, or children of a certain class, allowing applications to address a set of elements. The system was generally similar to the Document Object Model
Document Object Model
The Document Object Model is a cross-platform and language-independent convention for representing and interacting with objects in HTML, XHTML and XML documents. Aspects of the DOM may be addressed and manipulated within the syntax of the programming language in use...
used in XML
XML
Extensible Markup Language is a set of rules for encoding documents in machine-readable form. It is defined in the XML 1.0 Specification produced by the W3C, and several other related specifications, all gratis open standards....
, although with some differences in access patterns.
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 elements 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. 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.
The entire AppleEvent architecture identifies things using four-byte OSType
OSType
OSType is the name of a four-byte sequence commonly used as an identifier in Mac OS. While the bytes can have any value, they usually display figures characterized in software programs such as those utilized in ASCII or Mac OS Roman character sets.OSType values are used to identify file data...
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
Resource fork
The resource fork is a construct of the Mac OS operating system used to store structured data in a file, alongside unstructured data stored within the data fork. A resource fork stores information in a specific form, such as icons, the shapes of windows, definitions of menus and their contents, and...
— 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 color of window "New Drawing" to background color 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 color 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 color property of the window named "New Drawing".
Since this sort of access pattern was typical, AppleScript made widespread use of the
tell statement, which switched the context to the named object in a fashion similar to the with statement found in Visual BasicVisual Basic
Visual Basic is the third-generation event-driven programming language and integrated development environment from Microsoft for its COM programming model...
or Pascal. All commands after the
tell to the corresponding end tell would be sent to the object named in the tell, instead of the default object, which was the current application.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
SQL
SQL is a programming language designed for managing data in relational database management systems ....
.
Adding support for the AEOM in the "classic" Mac OS
Mac OS
Mac OS is a series of graphical user interface-based operating systems developed by Apple Inc. for their Macintosh line of computer systems. The Macintosh user experience is credited with popularizing the graphical user interface...
was a difficult process. Application developers had to identify their objects and hand-write code to allow them to be addressed. This typically took the form of code for returning the "next" object of a particular type, allowing AppleScript to iterate over them. But since the OS did not contain an object model, this work was left entirely to the developers, many of whom did not implement it. Oddly, even Apple's own application framework
Application framework
In computer programming, an application framework consists of a software framework used by software developers to implement the standard structure of an application for a specific development environment ....
, MacApp
MacApp
MacApp was Apple Computer's primary object oriented application framework for the Mac OS for much of the 1990s. First released in 1985, it is arguably the first such system to be widely used, notably on a microcomputer platform...
, did not offer such a model except for the GUI
Gui
Gui or guee is a generic term to refer to grilled dishes in Korean cuisine. These most commonly have meat or fish as their primary ingredient, but may in some cases also comprise grilled vegetables or other vegetarian ingredients. The term derives from the verb, "gupda" in Korean, which literally...
objects it knew about, once again making the developer do most of the work of scripting the objects representing the data itself. Largely for these reasons, AppleScript support was not very widespread.
Apple did attempt to address this problem with the introduction of various object "suites", which represented standard objects and verbs that were expected to be supported by different types of applications. For instance, all applications were expected to support the "core suite", and any application editing text was expected to support the "text suite". By selecting a suitable set of suites, the developer could at least reduce the workload of planning how to expose their objects. Yet because these objects were generally not part of the system itself (with the exception of the severely limited TextEdit editor), the actual implementation was left to the developer.
Applications developed in Cocoa
Cocoa (API)
Cocoa is Apple's native object-oriented application programming interface for the Mac OS X operating system and—along with the Cocoa Touch extension for gesture recognition and animation—for applications for the iOS operating system, used on Apple devices such as the iPhone, the iPod Touch, and...
, the system formerly known as OpenStep
OpenStep
OpenStep was an object-oriented application programming interface specification for an object-oriented operating system that used a non-NeXTSTEP operating system as its core, principally developed by NeXT with Sun Microsystems. OPENSTEP was a specific implementation of the OpenStep API developed...
, offer a rich object runtime that can be queried from any other application. This makes implementation of the AEOM considerably easier, dramatically reducing the amount of code needed in the average application. Additionally the majority of Cocoa applications are constructed primarily from Cocoa-standard objects, all of which were upgraded to offer fairly extensive scriptability. This extends not only to GUI objects as under MacApp, but also to data objects inside them, including text, tables and various list objects. A text file is used to map the internal "object-like" names onto human-readable
Human-readable
A human-readable medium or human-readable format is a representation of data or information that can be naturally read by humans.In computing, human-readable data is often encoded as ASCII or Unicode text, rather than presented in a binary representation...
versions, and in most cases creating this is all that is needed to add fairly substantial scriptability to most programs.
While Cocoa applications are not AEOM based, and often use subtly different objects than Apple's originally defined standard objects, Cocoa apps are generally much more scriptable than their "classic" counterparts—in fact, it is uncommon to find a Cocoa application that is not scriptable to some degree.