Re[2]: [lmi] Child documents

[Vadim Zeitlin]

[this is a return to a very old discussion but I really, really do intend
 to finish it this time so that we won't have to return to it again]

On Sun, 15 Mar 2009 19:25:03 +0000 Greg Chicares <address@hidden> wrote:

GC> Ted Neward's _Advanced OWL 5.0_, ISBN 1-884777-46-5, contains the only
GC> discussion I've ever seen of OWL's child document idea, which is where
GC> I originally got this lmi idea. He calls this "one of the most underused
GC> features in OWL". Comparing that to a full embedding concept (like ole
GC> or opendoc), he says "Compound documents in OWL are far more limiting.
GC> They simply group TDocument objects in a hierarchy, cascading operations
GC> on a parent document to, in turn, be called upon by each of the children,
GC> which implies that wxDocument::Save[As]() would save child documents
GC> (as the analogous OWL TDocument::Commit() indeed does).

 I haven't read the book (it's esoteric enough for even Google Books to not
index it) but this concept does make sense to me in the form described
above. However this is subordinate to Save[As]() working this way, i.e.
cascading from the parent document to children.

GC> Compared to that "far more limiting" concept, what lmi uses is still
GC> more limited, because it omits the Save[As]() part: all that remains is
GC> to "simply group TDocument [wxDocument] objects in a hierarchy" and to
GC> cascade only one operation, i.e., closing.

 I thought that this was indeed just a limitation and so it still made
sense. However now I'm less sure: if a child document can't be saved
independently of the main one (and, in any case, can't be opened
independently of it because the user never selects any parent document so
creating/opening child documents is always done programmatically anyhow),
what exactly can it be used for that just a view can't?

GC> Suppose you load a document in a word processor, and issue a print-
GC> preview command. A "view" is created. If you close the document,
GC> then the view presumably vanishes. If you change the document, then
GC> you can't reproduce exactly the same view. It's an ephemeral view
GC> that's thrown away if you don't print it immediately. That's the
GC> kind of thing I'm talking about.

 I didn't pay enough attention for this part when reading this message the
first (and subsequent...) time(s) but now I think that it is key to my gut
feeling of discomfort provoked by this child document concept: if it's so
similar to a view, why don't we just use views instead?


 When starting redoing the modifications to wxWidgets docview classes (the
first version of my changes was lost due to an unfortunate merge
accident...) I wanted to think of a simple representative example of this
new feature. The docview sample already can open (read-only) image
documents in addition to drawing and text ones and I thought that I could
have a child document of image document which would contain the image
metadata (very simple, as it's just an example, i.e. just size, number of
colours and so on). And it does indeed work like this: I now create an
ImageDetailsDocument when opening a new ImageDocument, initialize it with
the parent document image metadata, create a ImageDetailsView corresponding
to it and it works well. However there doesn't seem to be any advantage to
defining an ImageDetailsView directly associated with ImageDocument. It
will have to be created manually (wx framework only knows how to create a
single view by default) but the user-observable behaviour will be the same
as above (i.e. the view will still show the same information and will still
be closed when the document is) and it doesn't require defining another
document class nor maintaining the documents hierarchy so the code is
simpler. The only difference is that the details view will need to be
closed manually too, when the main view is closed. But this is simple to do
and we might also consider a view hierarchy (with the convention that child
views are closed when their parent is) -- this will still be simpler, both
in wx and in user code, than having the hierarchy at document level.


 I do hope I'm missing something here as the last thing I want to do after
spending time to do it again is to throw my work (again, too, even if this
time it would be done intentionally). But if there is no advantage to using
child documents compared to just views I can't really justify keeping it
neither. Can you help me by explaining what did I miss?

 This is the main question and the main reason for reviving this thread so
I won't address LMI-specific parts of your message (which is available in
full at http://lists.nongnu.org/archive/html/lmi/2009-03/msg00052.html).
I'll come to them later when we firmly decide whether we really need child
documents at all or if they can be replaced by custom views.

 Thanks in advance for any extra insights,
VZ