W3C home > Mailing lists > Public > www-dom@w3.org > July to September 1998

read-only parentNode -- revisited

From: Kirkpatrick, Alfie <akirkpatrick@ims-global.com>
Date: Mon, 7 Sep 1998 10:57:47 +0100
Message-Id: <199809071004.GAA11770@www10.w3.org>
To: "'www-dom@w3.org'" <www-dom@w3.org>
> After working with the previous DOM draft in the COM
> environment, I initiated a discussion under the thread,
> "Question about getNextSibling/getPreviousSibling".
> We discussed the possibility of mixing DOM nodes from
> different implementors in a single tree, and the
> implications on the interface, particularly being able
> to set the parent node via the interface.
> Reviewing this discussion, the outcome seemed to be that,
> "no, you cannot mix nodes from different implementations".
> However, I believe that with perhaps just one minor change,
> this can be enabled and I'd like to raise the issue again
> (with your permission and patience...)
> The key thing here is that after a COM object is created
> by the server (for example, in createElement), the system
> loses all "internal" knowledge of it. Because of this,
> when a node is passed into a method like insertBefore,
> it isn't safe to cast from the interface pointer to the
> "real" C++ object, and then call functions in the object.
> The only safe option is for the node to support a special
> "private" interface such as INodeInternal.
> Perhaps this is the way to go. It would certainly allow
> implementations to provide performance benefits, for
> example by maintaining child indexes for resolving calls
> like getNextSibling. It just seems a shame as I can
> envisage times when we will want to mix and match. For
> example, if I have an editor and want to insert content
> from a DOM repository directly.
> At the moment, the only change needed would be to make
> parentNode read/write. However, there may be others I
> haven't come across.
> This issue also raises another question. If I go with
> the INodeInternal approach, what should I do if a node
> is passed to insertBefore which supports INode but
> not INodeInternal (that is, a node from a different
> implementation).
A final thought: perhaps a compromise might be to add a document
context to the cloneNode method. For example:

	e.cloneNode(TRUE, mydoc)

That way, if an element didn't support INodeInternal, insertBefore could
clone the node in the new document context.

> Thanks, Alfie.
Received on Monday, 7 September 1998 06:03:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:04 UTC