Document Vs Component (Was Re: How to gnome/CORBA?)

[Philip Dawes <philipd parallax co uk>]

DISCLAIMER:
Before I go on, could I make it clear that I've never actually used
opendoc, and am just going on what I've read in opendoc books..


Owen Taylor wrote:
> 
> 
> I think we have to decide whether we want a component model
> or a document model. The CORBA component model, is in fact
> a component model, like JaveBeans. As far as I could see,
> it had very little relationship to OpenDoc, which is a
> document model.
> 
> roughly speaking:
> 
> Component Model
> ---------------
> 
> A component model specifies GUI entities. These are generally
> assembled into applications by a programmer, often via a "builder"
> tool. A component model will typically have abstractions
> supporting such tools, and for communicating between components,
> but specifies nothing about the contents of the components.
> 
> Examples: JavaBeans, VB/ActiveX controls
> 
> Document Model
> --------------
> 
> A document model assumes that information comes in the form of
> documents (such as printed pages, or web pages). These documents
> are composed of different types of information (parts) in
> a heirarchical manner. There is a distinction between the piece
> of information (part) and the entity used to edit it (part editor).
> 
> A document model will have specialized abstractions for displaying
> loading and saving documents, for setting menus, for editing
> the parts, etc.
> 
> Examples: OpenDoc, The original OLE.
> 

I think you've taken the word 'document' too literally here in your
synopsis. The original OLE was indeed just about embedding fancy
pictures and bits into 'paper' style documents, however opendoc is more
a system for letting the user build her application around the task that
she wants to do. The 'document' is just a metaphor for providing a
central focus for the task at hand, and provides a convenient basis for
saving all the state to do with that task.
The metaphor can be stretched as far as you want to take it.


There is indeed a distinction between 'part' - the 'state' and 'part
editor' the tool that can be used to change that state. However the
developer only writes part-editors (she does this by subclassing 'part'
in opendoc) which load, save, display and edit the part. When a
'document' (i.e. an old task) is loaded from storage, the part-editors
are matched with the 'parts' stored in the file. If there is a part in
the storage which opendoc cannot find a part-editor to handle, it
provides a default one which simply displays a grey box in the area
where the part originally was.

> There is obviously some overlap here. A document model could
> possibly be implemented using a component model, and might have
> components embedded within documents. (HTML forms, etc). But a
> document model is a much more sophisticated (and limited)
> concept.
> 

Why limited? 

I'll stick my neck out here an suggest that there is nothing that you
can do with a component model that can't be done with a document model.
A document model *is* a component model which also handles the uniform
saving of all the 'state' to do with a task. 

AFAIK it's just as valid to write a part editor which doesn't actually
save any state - you could write a system monitor part editor which
saves nothing. The opendoc system will save the fact that the system
monitor tool was part of that task and will attempt to re-start it when
you open that task again. 

I'm writing a short overview of how a document model works (going on
opendoc) for the gnome web page - hopefully I'll finish it tonight.

Cheers,

Phil.

P.S. Like I said earlier - I've never used opendoc and am just going on
what I have read - I could be totally wrong about all of this. I hope
I'm not because what I've read was really impressive.

-- 
_______________________________________________________________________
 Phil Dawes                               |   My opinions are my own
 WWW:    err.. temporarily non-existant   |   and nothing to do with
 Email:  philipd@parallax.co.uk           |      my employer.