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

[Owen Taylor <owt1 cornell edu>]

Philip Dawes <philipd@parallax.co.uk> writes:

> 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:

[...]

> > 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.

The metaphor can indeed be stretched, but there are several
fundemental differences between a document model and a generic
component model. The biggest one is that in a document
model, the heirarchy in the document is distinct from the GUI
heirarchy. That is, a frame in the document may have an associated
window (Facet), or it may not, and when a particular part is
activated for editing, it will generally adjust the GUI 
for editing that particular part. 

[...]

> > 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. 

The document model makes the distinction that the on screen layout
is distinct from the virtual geometry of the document. This adds
enough complexity that it wouldn't make much sense to add in
all the typical features of a Component model. Essentially a document
model is specialized for a particular task. 

It is not "limited" in the sense that it is not powerful, or that
it couldn't be used for almost any task. It is limited in the
sense that it does constrain the possible user interfaces that
can be built with it. 

There is no point in adding features for supporting GUI builders
in a document model, because the way a document is built is
that the user edits it. That is, there is no fundemental distinction
between viewing a document and creating it. (Except that in the
commercial world, the idea was that crippled read-only part editors
would be made available for viewing documents without 

I won't say that it is impossible to create an all-encompassing
framework that handles everything that a typical document model
(OpenDoc) does, and everything that a typical component model
does (JavaBeans) but I'm not sure it makes sense. OpenDoc certainly
isn't such a beast.

> 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. 

That is certainly possible - but such a monitor tool would have
to occupy some fixed portion of a "document".
 
> 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.

You might want to take a look at the detailed documentation at

  http://service.software.ibm.com/opendoc/doc/index.htm

It _is_ very impressive, but you'll find it is also quite specialized
to dealing with things that vaguely resemble a sheet of paper.
This is necessity.

Regards,
                                        Owen