Lee Iverson wrote:
>
> A Node *itself* is placeless, in that it doesn't know where it is
> located in a hierarchy. The GroupingNode objects can have children,
> but the children themselves don't know that they are children of that
> particular node.
>
> The easy way to think of this is that in order to know *where* it is
> in a tree, a Node must be able to at least trace the sequence of its
> parents up to the root. In the model I've described that operation
> cannot be done by a Node, but instead requires a Path object, which is
> defined wrt. a particular Document. So, a Node has no identifiable
> parent, and thus no "place". This is not in any way in conflict with
> the fact that some Nodes have children.
>
> Since editing structure requires a definite context, that is all done
> with respect to Paths.
>
I keep going back and forth between thinking it make sense, and
getting confused. I think I need a picture. If we leave out the
text and attributes, and focus just on nodes and paths, what kind
of picture do we see?
I get that the separation of Path and Node makes sense. And the
Path encasulates a node. But if the node has a child, at what
point does the child have a path in the document?
Basically, if a node has a child, and that child is a node, that
doesn't produce a tree structure, but rather a single chain of
children. What purpose does that chain serve?
I see that the child of a node is not readonly. At the moment,
it looks like the Path is operating as a keeper of the sibling
list for a node, while a Node is a keeper of the (first?)
child in its sublist.
It looks like the basic division of nodes and lists. Except
that in this case the child of a node is a node (the head of
a list) rather than a list (aka Path).
Hmm. I think I get it. The key is the methods:
Path firstChild()
etc.
You construct a document by adding nodes to it. The nodes
can come from anywhere. As you traverse the document, the
path to the next node is always returned relative to the
path of the node you're traversing from.
Note:
I see that EditablePaths have insertBefore, insertAfter, and
remove operations. That's fine. But an "addChild" operation
is necessary, somewhere, to make it possible to build tree
structures, unless you intend to mutate a Node's child object
directly. (I don't think you want to.)
One other question:
I didn't see a GroupingNode class.
Did you mean ElementNode?
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:58 PDT