View figure.
The OpenDoc architecture is designed to be extended. Using built-in features, you can enhance the capabilities of and communications among your parts in a compound document, and you can even develop component software that goes well beyond the standard OpenDoc model of parts and compound documents.
The main point of departure for enhancing OpenDoc is the extension mechanism, a general method for adding programming interfaces to objects. Additional mechanisms are the focus-module and dispatch-module interfaces, which allow you to add new kinds of focus and new kinds of event handling to your part editors.
OpenDoc already includes instances of extensions: scripting support and settings extension. This section introduces the features of these extensions and summarizes how you can add other extensions for other purposes.
A major feature available with OpenDoc is the ability to make parts scriptable, allowing users to customize their applications to user-specific tasks. Working in a compound document environment, with scriptable parts, sophisticated users can use standard document-editing procedures to add application-like functionality to parts. Likewise, programmers can create complex client applications and present them in the form of compound documents. See "Direct Scripting".
The settings extension allows a part to display its properties and settings in a standard notebook.
The basic architecture of OpenDoc is primarily concerned with mediating the geometric interrelationships among parts, their sharing of user events, and their sharing of storage. Direct communication among parts for purposes other than frame negotiation is mostly beyond the basic intent of OpenDoc. If separate parts in a document (or across documents) need to share information, or if one part needs to manipulate the contents or behavior of another part, some extension to the capabilities of OpenDoc is needed.
OpenDoc allows you to add these kinds of capabilities to part editors through its extension mechanism. A part editor can create an associated extension object that implements an additional interface to that editor's parts. Other part editors can then access and call that interface.
The OpenDoc support for scripting is an example of an extension interface. Other extension interfaces can provide faster interaction and lower-level communication between parts. A word processor, for example, might construct an extension interface to give related part editors or other tools access to its text. A developer of a large application package might use extensions to provide greater integration among its components.
Figure 20 shows some possible examples of communication through OpenDoc extensions. It shows a text part and a graphics part that both communicate with a tool palette (a third part), so that the palette displays the appropriate tools for the currently active part, and communicates the user's tool selection back to the active part. A spelling checker provides its service to all parts in the document and accesses their text through their extensions. Furthermore, the text part and graphic part communicate directly through an extension mechanism; the text part updates the graphic part with the current figure number and caption it has assigned to the figure.
Figure 20. Parts Communicating through Extensions
In addition to the scripting extension, OpenDoc includes existing extensions and other kinds of enhancements that allow you to extend the OpenDoc Properties notebook, extend the capabilities of the OpenDoc document shell, or provide for additional kinds of user events or focuses. Use of the OpenDoc extension mechanism is discussed further in "Extending OpenDoc".