read-only parentNode -- revisited

> 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