[jdom-interest] Re: jdom-interest digest, Vol 1 #188 - 6 msgs

[David W. Smiley]

> I think you're right there's another issue that the bar.addContent(bar)
> command could cause a corrupted tree if bar doesn't have a parent.  We
> have logic that an element with an existing parent can't be added to
> another element (you must remove it from its original parent first) but
> an element just hovering there could theoretically be added to itself,
> or to its grandchild or great-grandchild or even its child's child's
> child's child.  Eliminating the possibility of a loop would require a
> logic as part of every add that looked at the merge point and walks up
> the tree to the root making sure you never find yourself in the process.

Wouldn't the problem go away if we play by the following rules?:
(1) An element can find its document iff it is an ancestor of that
document.
(2) An element cannot be added to another document unless the element to
be added cannot find its document nor its parent.

To go about implementing these rules...
(1) clone/copy will return the copy such that it has no parent and
cannot find its document
(2) removing an element works like clone/copy except that it's the same
instance
(3) adding an element must check that the element has no parent and
cannot find its document
(4) the implementation of the element need not necessarily have the
reference to the document itself; just to a parent element.  By
traversing to parents until the parent is an instance of a document (or
rootElement == true depending on how this works), the element can be
considered bound to a document.

To maintain these rules, the list returned from getChildren() should be
smart to check for these constraints.

-- David Smiley