Re: Should Document.cloneNode() work in Level 1?

Kirkpatrick, Alfie wrote:

> Don,
>
> I'm not sure I understand this debate about cloning or transferring.
> As I see it, the current spec doesn't say anything about transferring
> nodes without cloning, so presumably it can be left to implementations.
>
> The reason I wanted a targetDoc on cloneNode is so that we can
> mix implementations. So if I do an appendChild from one implementation
> to another, it can use cloneNode to get a clean copy in its own
> implementation. I now see that it can also be used to transfer nodes
> between documents too. For example (in pseudo code):

I agree.


> Node Element::appendChild(Node newChild)
> {
>     // Check implementation
>     NodeInternal customNode=newChild.QueryInterface(INodeInternal);
>     if ( (customNode == NULL) || (newChild.ownerDocument != ownerDocument) )
>     {
>          // Not my implementation/document
>          customNode=newChild.cloneNode(TRUE, ownerDocument);
>     }
>     // Add to my children
>     m_children.push_back(customNode);
>     // Here's where we use the custom interface
>     customNode.parentNode=this;
> }
>
> Does this make any sense at all in Java?

I do not think that the appendChild method of element should automatically
clone.


> Without a lot more work (ie. Level 2), I don't think we can get a
> transferNode
> which works between implementations/documents. However, if cloneNode is
> given a targetDoc parameter, implementations can decide whether to clone
> or not, and have a clear mechanism for doing so.

Probably.


> A performance boost might be to say that if the newChild is the same
> implementation, has a different ownerDocument but doesn't have a parent
> (perhaps after a removeChild), the custom interface could be used to modify
> the ownerDocument and the parentNode, and thus avoid cloning.

I strongly disagree.  This is far worse than simply adding transferNode.
cloneNode should always clone the node.  The type of complex behavior you
describe should never be a part of cloneNode, i.e. sometimes it clones and
sometimes it returns the original.  If you want transferNode, then call it
that.


> This raises a question. What happens to ownerDocument and parentNode
> after removeChild?

ownerDocument is a read-only attribute that always points to the document that
created it (or perhaps in the future, that it was transferred to).

When a child is removed from the parent, the parentNode attribute becomes null.

Was this what you were asking?

Ray Whitmer
ray@imall.com

Received on Wednesday, 9 September 1998 12:11:05 UTC