Inside Macintosh: Programmer's Guide to MacApp / Part 1 - MacApp Theory and Architecture

Chapter 6 - Scripting

Overview

The Macintosh Operating System provides the capability of using high-level events to communicate between applications, to control applications, to allow users to automate tasks, and even to allow sophisticated users to modify an application's behavior. This capability is based on the Open Scripting Architecture and the use of Apple events.

To help explain the scripting support MacApp supplies, the following sections describe basic scripting terminology and examine the levels of scripting support an application may provide. For a more detailed description of scripting, refer to Inside Macintosh: Interapplication Communication.

Scripting Terminology

Apple Computer has defined the Open Scripting Architecture (OSA)--a standard mechanism that allows users to control multiple applications with scripts written in a variety of scripting languages. Each scripting language has a corresponding scripting component. The AppleScript component implements AppleScript, the standard user scripting language defined by Apple Computer. By default, MacApp uses the AppleScript scripting component.

An Apple event is a high-level event that conforms to the Apple Event Interprocess Messaging Protocol. The Apple Event Manager uses the Event Manager to send Apple events between applications on the same computer or between applications on remote computers. An application is called a server when it responds to Apple events sent by another application. The sending application is referred to as the client.

The Apple event object model defines a standard interface that allows an application to be controlled from other applications and to be scriptable using standard, human-language terminology. A script is a collection of data that, when executed by the appropriate program, causes a corresponding action or series of actions.

An Apple event object is a distinct item (such as a word, paragraph, shape, window, or style format), in an application or its documents, that can be specified by an object specifier record in an Apple event. The Apple Event Manager allows applications to construct and interpret object specifier records by means of a standard classification system for Apple event objects. The Object Support Library (OSL) is a component of the Apple Event Manager; applications use the OSL to create and resolve object specifier records.

The Apple Event Registry: Standard Suites defines the standard suites of Apple events, which are groups of related events that are usually implemented together. The standard suites include the following:

• The Required suite consists of the four Apple events that the operating system sends to applications. These events are Open Application, Open Documents, Print Documents, and Quit Application. To support System 7 and later system versions, your application must support these events. MacApp provides support for the Required suite.
• The Core suite consists of the basic Apple events nearly all applications use to communicate, including Get Data, Set Data, Move, Delete, and Save. The Core suite also includes the four required Apple events. MacApp supports part of the Core suite and provides a framework for your application to support the rest.
• A functional-area suite consists of a group of Apple events that support related operations. Functional-area suites include the Database suite, the Mail suite, the Telephony suite, and the Text suite. You can use the MacApp scripting framework to implement support for the suites that are appropriate to your application.

An Apple event terminology extension resource, of type 'aete', provides information to a scripting component about the Apple events an application supports and about the human-language terminology associated with those events.

Factoring an application (see page 143) is a two-part process that involves

• separating code that controls the user interface from code that responds to user actions
• breaking functions into discrete operations that can be implemented as separate tasks

There are three well-defined levels of scripting support an application can provide:

• A scriptable application is capable of responding to Apple events sent to it by a scripting component. All applications should be scriptable to the extent of supporting the four required Apple events listed above. A scriptable application may also respond to Apple events it sends to itself.
• A recordable application responds to user actions by sending Apple events to itself. When the Apple events are sent, the Apple Event Manager may record them into a script.
• An attachable application is capable of attaching scripts to the application's data or objects to modify the basic behavior of the application.

  An embedded script is built into the application at the development stage. An attached script is one that can be added or modified without rebuilding the application.

Most applications should be scriptable and recordable. Consider making your application attachable if it will need to be very flexible or customizable.

Scripting and recording are closely related. A scriptable application can respond to Apple events sent to it from any source. A recordable application handles an Apple event that it sends to itself the same as if it were sent from an external source--by performing the operation requested by the user. This implies that recordable applications must be scriptable.

Note

To help support scripting in your application, MacApp provides a mechanism for creating command objects that can both perform an operation and supply an Apple event that describes that operation. For more information, see "Command Objects and Apple Events," beginning on page 120.

MacApp predispatches Apple events to attached scripts before dispatching them to the application's scriptable objects. For more information, see "Dispatching Apple Events," beginning on page 150.

Deciding What Level of Scripting to Support

During the design of your application, you determine what level of scripting support the application will provide. Here are some of the basic questions you need to answer:

• Which Apple events will your application support?
• Will your application define its own suite of Apple events?
• Will the application be recordable?
• Will you use embedded scripts to perform application operations? Will you allow attached scripts to control application functions?

Required and Core Event Suites

Every application should support the four Apple events in the Required suite, since these events may be sent to the application by the operating system. Many applications support additional events from the Core suite to specify operations such as getting and setting data, moving and deleting objects, and counting objects of a particular type. MacApp automates support for the Required suite and supplies substantial support for the Core suite as well.

Area Suites

Depending on its function, your application may also want to support Apple events from other suites, such as the Database, Mail, and Text suites. For more information on Apple event suites, see "Identify the Custom Apple Event," beginning on page 361.

Factoring

Factoring your application plays a key role in providing scripting support. If you thoroughly separate user interface code from code that responds to user actions, and if you perform operations as individual tasks, it will be much easier to use Apple events to initiate and record actions. It will also be easier to use scripts to manipulate your application in a powerful and comprehensive way. Factoring can be a useful design goal for cross-platform development, even if your application has minimal scripting support.

MacApp itself is factored through the use of command objects. When a user manipulates the user interface to perform a task, MacApp creates a command object to perform the specified operation. A command can send an Apple event that describes its command operation, making it easy to record the operation or to allow an attached script to respond to the Apple event.

Advantages and Disadvantages of Adding Scripting Support

There are a number of reasons to factor your application and support scripting for various Apple events:

• A factored application can be much easier to modify and debug.
• You must support the required Apple events to be compatible with newer versions of the Macintosh Operating System.
• An application that supports a wide variety of Apple events can interact more effectively with other applications.
• Program testing can be automated and users can automate repetitive tasks.

The use of embedded scripts (those built in at the program development stage) and attached scripts (those that can be added or modified after the application is built) can offer additional advantages:

• It should often be possible to modify and test an embedded script more easily than to modify and test the equivalent function written in C++ code.
• New or enhanced features can be delivered simply by distributing new scripts.
• Power users can customize program behavior.

But there are also costs associated with writing a fully factored program that supports a large number of Apple events and uses embedded or attached scripts:

• Factoring can add to the time required to develop the application.
• Functions implemented by scripts are likely to be slower than similar functions implemented in C++ code.
• Scripting support adds some complexity to an application and can be difficult to debug, especially when you're at the beginning of the learning curve.
• Allowing users to modify program behavior with scripts is definitely a two-edged sword. Consider the problem of providing technical support for a user who has modified or completely replaced scripts that provide the basic functions of your application.