Frontier & The Object Model

Frontier's support of the Apple Event object model is fully integrated into the UserTalk language.

The object model is the style of interapplication communication promoted by Apple Computer and supported by AppleScript.

Theory of the object model

Common to object model applications are the following characteristics that determine how they can be scripted:

1. They use "object specifiers" to refer to their data;
2. They support a proposed set of standard "suites" of verbs;
3. They use a proposed set of standard terminology when talking about their verbs and data.

In the sections below, we discuss how Frontier taps into these common features to provide a great deal of power in controlling object model applications.

Object Specifier Paths

The most basic aspect of the object model are objects themselves. Objects are the things that an application operates on, typically its windows, documents, and the data within them.

Objects can contain other objects - windows can contain text, which might consist of paragraphs which in turn contain words and characters. This nesting of objects is known as an application's "containment hierarchy".

Objects fall into two basic categories: elements and properties. Elements are objects within a container that make up its data - words within a paragraph or cells within a spreadsheet. Properties are characteristics of an element that are singular and cannot be deleted - an object's font or color, or a window's name for example. You can change the value of a property, but you cannot delete it.

Each Apple Event suite defines a set of objects, their elements and properties, and the events (verbs) that can be applied to them. An application is free to expand on these definitions, or to support only a portion of them. For applications that support the object model, you should find an outline titled "objectHierarchy" in the application's glue table (at system.verbs.apps.[appName]) which lists objects with their elements and properties.

Object specifier paths are UserTalk expressions that refer to an object or set of objects in an application's containment hierarchy. These expressions look like Frontier object database paths, but specify a path into a target application's containment hierarchy, rather than the Frontier object database hierarchy. The key to differentiating between the two types of paths is that database paths always begin with a table name, while object specifier paths begin with a string4 value or another object specifier.

In an object specifier path, identifiers followed by an array reference (square brackets) specify an element, while identifiers not followed by an array reference specify a property. The expression within an array reference can be a number or a string, to specify objects by index or name. It can also be a comparative expression, to specify a "whose" clause - a set of objects that meet specific criteria. The "to" keyword can be used to specify a range of indices, or the range between two other objects. Finally, the array reference expression, or element specifier, can be a string4 to refer to an absolute or relative position.

Apple Events use string4 values to represent objects. Objects specifiers constructed with string4s are rather cryptic, so applications provide "user terms" which are more readable labels for objects. Frontier's objectModel table contains user terms for a standard set of objects, such as 'window', 'document', and 'paragraph'. This table also contains items that refer to a specific types of indexes such as 'last' or 'all'. When writing scripts you will always be able to construct object specifiers using only user terms and not sting4s.

Applications usually provide additional string4 values and coresponding user terms for objects specific to that application. For example Eudora provides string4s with user terms for objects like 'mailbox' and 'message'. By default, you will find these application specific values in the application's glue table, but there are times when they will be in a seperate sub-table (often named "eventInfo") to help keep the main glue table uncluttered. When this is done a third item in the "with" statement is need.

Examples

Here's an example of an object model statement in its simplest form:

with FileMaker
	show (record[1])

If you look in the FileMaker table, you'll see that there's a script named show, and a string4 named record. As Frontier is evaluating the expression, it builds an object specifier that indicates record 1. Calling the show verb causes that record to be displayed.

Here's a richer example:

with FileMaker
	show (record [cell ["Name"] contains "New"])

This expression walks thru FileMaker's containment hierchy, selecting all records whose cell "name" contains the sub-string "New".

In both of the previous examples, we only used terminology that's specific to FileMaker. Other terminology, that all object model applications support, is stored in the system.macintosh.ObjectModel table. In the following example we use the term "all" to specify all records, so we must include the objectModel table in the with statement:

with objectModel, FileMaker
	show (record [all])

Object Indexes

An index to an object may be a simple number as used in lists (such as window[1]), a name (window["messages"]), or it can be a more complex conditional statement as used in the second example. The index can also be one of several special types. The following list represents several valid forms:

• message[1 to 5] a range
• window[all] every object of a class
• record[cell["name]=="New"] matches a test, can use contains, !=, etc

Properties

The object specifier for a property does not use an index, however properties are always associated with element objects. Some properties are read only. You get and set properties much like you manipulate the values of variables.

with objectModel, Eudora, eventInfo
	local(messageStatus)
	messageStatus=message[5].status
	if messageStatus==read
		beep


with objectModel, Eudora, eventInfo
	message[1].body="Some random text"

Note the inclusion of the eventInfo table, since Eudora keeps object terms in this subtable.

Addressing Nested Objects

You can also use the with statement to have a set of statements apply to an object nested in an application's containment hierarchy:

with objectModel, MacWordProcessor, document [1].word [1 to 4]
	set (font, "Palatino")
	set (size, 14)

The string4 values "document", "word, "font" and "size" are defined in the objectModel table. The "set" verb refers to MacWordProcessor.set, and is applied to the font and size properties of words 1 thru 4 of the frontmost document.

The best way to learn the objectModel (and UserTalk in general) is to work through examples for specific applications and experiment.

Thanks

Thanks to Preston Holmes, pholmes@ucsd.edu, for converting this UserLand readme file into HTML.

---

© Copyright 1996-97 UserLand Software. This page was last built on 5/7/97; 1:41:26 PM. It was originally posted on 5/9/96; 12:14:48 PM. Internet service provided by Conxion.