Inside Taligent Technology - Embeddable components

Embeddable components

In the Taligent programming model, an embeddable component is an ensemble of framework code that constitutes a self-contained functional unit roughly equivalent to an application plus data. The Compound Document framework, which is one of the Desktop frameworks, supports the creation and integration within a single document of embeddable components with different capabilities: for example, a text component, a graphics component, and a spreadsheet component. The embeddable component is the key programming abstraction used in data-centered CommonPoint applications.

NOTE The term component is also used in the computer industry to describe any software entity, including objects such as buttons and menu items, that can be connected with other programmatic entities with the aid of visual programming tools. Taligent's approach to this broader category of component software is described in Chapter 5.

From a user's point of view, a component created with the Compound Document framework is similar in many respects to an OpenDoc "part" or OLE "server." It contains native data and possibly one or more other embeddable components. Users can create embeddable components explicitly by using stationery pads or tools and implicitly during paste or drag-and-drop operations. They can also embed any embeddable component within any other embeddable component.

A document is any freestanding embeddable component that isn't embedded within any other component; therefore, any embeddable component has the potential to be a document. Any degree of complexity is possible within a single document. A user can create a custom document that contains multiple components and multiple data types, such as text, graphics, video, and
sound, without having to open separate applications to create and edit each type. A document that contains more than one embedded component is a
compound document.

Figure 20 shows how a typical compound document might be organized. For an example of a real compound document, see page 50.

Enclosure and embedding

There are two ways a component can maintain its separate identity and still be contained by another component:

Enclosure occurs when one component contains another, which still exists as a completely separate object. A component represented as an enclosable icon is enclosed by another object. Typically, an object encloses other objects to organize them, as in a file folder.

Embedding occurs when one component is incorporated into another, but its unique behavior, such as editing and presentation, remains available via menus or global tools. A component represented as a frame is embedded within another component.

In some cases one component can completely absorb another:

Absorption takes place when one object is completely incorporated into another, so that it's no longer identifiable as a separate object. For example, absorption occurs when a text string object is dropped into a paragraph.

A component might change its representation when it's moved or copied from one location to another. The component's container determines what form the component should take. For example, dragging a frame from a document into a folder changes the frame to an icon.

The four questions

To create an embeddable component, a programmer writes an ensemble based on the Compound Document framework. Most of the new code required answers four basic questions:

Model. What is the structure of the data? For example, the data might be a text string, an array of numbers, graphics data, or a sound file.
Selections. What discrete pieces of the data can the user select? In a table, a user might want to select cells; in a bar chart, a user might want to select each bar; in text, a user might want to select a range of characters.
Commands. What operations can the user perform on the data? For example, after selecting a cell in a table, the user might want to edit its contents or change its format by choosing commands from a menu.
Presentation. How is the data to be presented? For example, if it's an array of numbers, it could be presented as a bar chart, pie chart, or table.

Chapter 7 explains the terms model, selections, commands, and presentation in detail. Just as other dynamic systems based on very simple rules can achieve complex behaviors, the four questions and the object designs that answer them facilitate the modeling of complex business functions and other real-world processes.