OpenDoc 201

by Rollin White

Earlier OpenDoc articles explained the "OpenDoc vision." If you haven't yet read OpenDoc 101 and 102 in earlier issues of OS/2 For You (or maybe you need to review), please do so now. Now that we've got the vision, it's time to move on to the substance.

This month we will look at the architecture of OpenDoc without getting too bogged down in language specific details. My hope is that nondevelopers will understand and enjoy this article just as much as gung ho programmers, even though it's somewhat technical.

OpenDoc is an object-oriented, language independent, programming model. In the OpenDoc model, components fall into two categories - containers and non-containers. If you recall, containers have the ability to embed other parts (potentially containers themselves).

Before we further explore the differences between containers and non-containers, let's look at some of the responsibilities of any OpenDoc part. At the very least, a part must respond to OpenDoc events. Perhaps we will explore specific events in the future, but for now, know that events are triggers from the outside world - other parts, OpenDoc itself, the operating system, or the user.

One of the important aspects of OpenDoc is the ability to embed documents. It is important to understand that OpenDoc literally embeds documents within each other. This relationship applies not only to the visual concept of embedding, but also to persistent storage. Documents embedded within each other are stored together.

You want me to put it where?

Beyond handling events, any useful part must be able to store its data. OpenDoc provides a mechanism called Bento (so named for the neatly compartmentalized Japanese "box lunch") to facilitate data storage. A rouge OpenDoc developer could store data using traditional file-based techniques, which would indeed work in an OpenDoc part. But there's a better way. Bento removes the wise OpenDoc developer from worrying about the details of file formats and other sticky file-based storage issues.

Bento is an extremely important concept. From the developer's perspective, it allows them to store arbitrary values associated with, or as part of their document. But much more important than arbitrary storage is that Bento is the way that embedded docu ments are stored within each other. Just like its name sake - a compartmentalized box, neatly packaging other components - Bento stores the individual embedded documents within each other, and ultimately on a disk. Again, like the real life version, Ben to allows that group of embedded documents to easily be carried away on a diskette or to e-mail.

Beyond this, Bento provides a hierarchical structure for storing data in a document. It automatically provides facilities for maintaining drafts. Bento supports arbitrary data types, allowing the developer to better model the data that's actually being represented. Finally, because file formats are always a thorn in the side of a developer porting an application, perhaps the most important benefit is that Bento is extremely portable.

So now - using Bento - our component can store its data, but it must also be able to display it. Pay close attention, this is going to become an extremely important issue as OpenDoc evolves. OpenDoc itself does not specify the mechanisms for interacting with the user interface, including drawing or rendering. Instead the developer is left to utilize the host operating system's GUI functions. But wait a minute, isn't OpenDoc portable? It is - remember, OpenDoc has nothing to do with the GUI.

IBM's answer to this obvious dilemma is OpenClass. Formerly known as the User Interface Class Libraries, IBM's OpenClass (IOC) is a set of C++ class libraries for developing applications, with particular emphasis on the user interface. IOC's base platfo rm has always been OS/2 with the goal to be portable across platforms. Currently there is IOC support on OS/2, Windows and AIX. Macintosh support has not surfaced yet. Theoretically, writing OpenDoc solely with OpenClass guarantees cross platform compa tability.

The only problem with IOC is that our component is now dependent on IBM for its cross platform capability. As long as IBM supports Windows, and does it well, this may not be a problem for most OpenDoc developers.

The other cross platform alternative is Apple's OpenDoc Development Framework (ODF). Described as MacApp for OpenDoc, ODF offers the same cross platform capabilities that IOC does. Conceptually, they are very similar. By choosing either IOC or ODF, you have made many decisions about how your component will be built and structured. ODF is currently available for Macintosh and Windows platforms.

Alternatively, we could focus the development on a particular operating environment. This gives us the opportunity to take better advantage of the operating system. The down side, obviously, is that we have to reimplement our components specifically for each environment - and in doing so we tend to lose the common base by creating components that should, but don't, quite act the same.

Back to Containers

Both containers and non-containers must provide all of the functionality previously discussed. But, containers must also provide support for document embedding, which breaks down into two types of work. The most complex is the visual aspect of document embedding. The container must manage the layout and visual representation of the documents embedded within it. It must also manage the layout such that none of the embedded documents interfere with each other's rendering.

Containers must also store the layout and visual location information so that the next time the document is opened, all of its pieces are in the right place. Again, Bento is the answer, providing the tools to more easily accomplish this.

As you can see, the differences between a container and non-container are not major. That is due, in part, to the fact that they both derive from the class ODPart. In fact, OpenDoc requires that all parts derive from ODPart. This class is an abstract base class (meaning that you can never create an object of type ODPart, you can only derive new types of parts from it) that requires 65 different methods or functions to be subclassed from it.

I'm ready to build, where's my tool belt?

At this point you should have a rough idea of how an OpenDoc part is structured. So how do we put one together? There are three basic approaches. We could modify one of the sample parts that are included with the OpenDoc portion of the Warp Toolkit. This is the easiest method, but least flexible. We could also write our own class definition, but it would require that we address all 65 of the methods implemented by ODPart. That doesn't sound like much fun to me.

Instead, the best technique is to use a new tool called PartMeister. This program will create OpenDoc template components, much the way AppWizard in Visual C++ does for MFC applications and Smart Templates does for Visual Builder.

An important feature of PartMeister is that it bases your parts off of either the BaseNonContainerPart or the BaseContainerPart. One of the key concepts in OpenDoc (or any OO environment) is subclassing from common parts. If everyone built their part as a child of ODPart, we would all implement simple but common functions differently. By deriving from one of the Base parts, we can let it implement the basics. Thus, each resulting part will have those simple functions in common, and the difference will be those functions that make our part unique.

Taking a quick look - basically, you feed PartMeister information, such as the name of your part, its class, and what part to derive from (container or noncontainer), and it cranks out a template component. The template doesn't do anything. But it is ab out 400 lines of "fill in the blank here" C++ code to implement an OpenDoc component. PartMeister also generates the necessary .IDL file and make file. All of which get you to a usable component a whole lot quicker than doing it from scratch.

Next Month

In the next article we will take a closer look at actually building an OpenDoc part. By then we'll have gone from the introductory concepts all the way through building (probably a simple) OpenDoc part. Unless I get feedback on specific areas of interest, next month's article will be the last in this series.

Editor's Note: At the time the newsletter went to press, the BaseNonContainer part was not yet available. Watch for it on Club OpenDoc.

Also in this series on OpenDoc for OS/2

OpenDoc 101, A Technology Frontier

OpenDoc 102

OpenDoc 202, Writing a Part using PartMeister

Copyright 1996 the Southern California OS/2 User Group. Reproduced with permission from the August 1996 edition of the group's newsletter, OS/2 For You.
All trademarks remain the property of their respective owners.