AppleScripting EGO
Volume Number: 13
Issue Number: 5
Column Tag: develop
According to Script: An External Editing Apple
Event Protocol
by Cal Simone
In recent years, Macintosh developers have begun to move away from large, monolithic
programs in favor of a more modular approach to software, producing leaner, more
efficient applications that don't try to do everything. An effective way to accomplish
this is through external editing, in which one application uses Apple events to call
upon another application for editing services. External editing allows your application
to take advantage of editors implemented as Apple event-based server applications,
which I discussed in develop Issue 29 that can be found at
http://17.126.23.20/dev/toc.shtml.
In this column, I'll be exploring the advantages of implementing external editing and
the basics of making it work, and I'll also present a good starting point for a general
external editing implementation. At this time, there is no generally applicable
external editing suite that's part of the Apple Event Registry. However, there is a suite
in fairly wide use that's designed specifically for external editing of graphic objects in
word processing documents (discussed later), and the more general external editing
suite presented here is largely derived from it.
Types of Apple Event Usage
First let's look at the types of Apple event usage to see how external editing fits in. In
general, there are three ways Apple events can be used:
• Direct program-to-program communication between two applications - One or
both applications have intimate knowledge of the other's Apple event protocol. Either
or both of the applications can be the client or the server. This usage has largely faded
from practice.
• Service modules - A client application calls upon the services of another
application as though that application were embedded in the client. An example is the
relationship between a word processor and a spell checker. External editing falls in
this category.
• Scripting - Lots of scriptable applications are hanging out, saying "I'm
available" and "This is what I do." The scripting language is the client, and it doesn't
have to determine which parts of the Apple event protocol of the scriptable
applications are necessary to control them; that's the scripter's responsibility.
Advantages of External Editing
There are several advantages to implementing external editing:
• Developers can effectively extend the capabilities of their applications by
leveraging off of applications from other vendors, so it's not necessary to implement
an editor for each data type supported by your application.
• Since each developer has a smaller code base to manage, applications will have
fewer bugs.
• Users can pick and choose the combination of tools they like from different
vendors, benefiting from the advantages that a stand-alone editor designed for
specialized usage can offer, while retaining access to all the features of the client
application.
• Users can use one environment for editing the same kind of data, regardless of
which applications they work in, enjoying a consistent experience.
If the above sound familiar, that's because these same advantages are central to
OpenDoc's philosophy. In the non-OpenDoc world, you can achieve much the same effect
by implementing external editing.
Note that in this discussion, client means the application requesting the edit (not the
actual user), and editor means the server application. Any application implementing
the Apple event object model and the Core suite can easily take advantage of external
editing as a client, since most of the work is done by the server.
An Eventful History
The work done in the Word Services Apple event suite paved the way for a consistent
services protocol. However, the details of that suite are somewhat specific to
spell-checking and similar service modules, where the client and server interact
more intimately. A modified version of the EGO (Edit Graphic Object) protocol is
better suited to external editing's needs. The main difference between EGO and the
external editing protocol that I describe here is that external editing relies less on
custom Apple events and parameters than on existing events defined in the Apple Event
Registry, in particular the Core suite, and can therefore be quicker to implement.
In EGO, the user double-clicks on an object in a client application, a server
application appears with the object in an editing window, the user edits the object and
dismisses the window, and the edited version appears in place in the client's window.
EGO was originally developed so that mathematical equations in word processing
documents could be edited in a full-featured equation editor. However, it was designed
for more general use as an external editing mechanism for graphics embedded in text
documents. The first shipping implementation in 1991 was used to link Expressionist
to Microsoft Word. EGO and extended versions of EGO have been implemented in word
processors, such as WordPerfect, Nisus, and FullWrite, as well as other types of
applications, such as Theorist, SigmaPlot, and Chem3D. (See
http://www.well.com/~bonadio/aba/ego.html for more details on EGO.)
Although not a part of the Apple Event Registry, the external editing protocol that I
describe here, and a version that included extensions applicable to script editing, are
based on EGO concepts and were developed in 1993. These ideas were shaped in
discussions between Allan Bonadio, founder of Prescience, Michael Rubenstein of
CambridgeSoft, Lee Buck of Software Designs Unlimited, and myself, and were
reviewed by others. In 1995, a portion of the scripting version was implemented in
FaceSpan and Scripter to allow editing and debugging of scripts in a stand-alone script
editor. Currently shipping versions of third-party stand-alone script editors include
some form of the protocol, with extensions or variations.
Please note that to make the external editing protocol useful for as wide a range of data,
clients, and editors as possible, I haven't included the parts of EGO or its variations
that are specific to editing particular data types. I'm going to concentrate here on
general-case scenarios and the Apple event protocols - the operations that can form
the basis for external editing. This is not a complete treatment of external editing by
any means; in particular, I'll mostly steer away from user interface issues and
discussions of error handling, both of which are important issues that need to be
addressed in any complete external editing suite. The goal of this column is to serve as
a catalyst to speed the creation and adoption of such a suite.
To be Modal or Non-Modal?
The external editing protocol was designed to allow both modal and non-modal editing.
In modal editing, the client application requests the services of the editor and waits for
the user to finish editing. The editor returns the edited item to the client, and the
client resumes operation. This modal editing situation prevents the user from working
in the client application during the editing session. I highly discourage anyone from
going this (user-unfriendly) route. The freedom, ease, and elegance of non-modal
editing far outweigh any superficial advantages of modal editing. Modal editing is not
recommended and won't be discussed further here.
In the less rigid world of non-modal editing, the client application requests the
services of the editor and allows the user to edit asynchronously. During the editing