RE: Question about getNextSibling/getPre

David,

It sounds like we are coming from the same angle, except I'm not
sure there is a major problem at the moment. It's buried in the spec.
but it does say under the description of getParentNode:

  "Note: because in ECMAScript get/set method pairs are surfaced
   as properties, Parent would conflict with the pre-defined Parent
   property, so we use 'ParentNode' ..."

Is this an oversight or remnant of an earlier draft? I took it to mean   
that
there should be a parent property which can be queried or set. If there
isn't supposed to be a parent property, how can insertBefore work?

This seems to be the only major obstacle when mixing nodes using
different implementations.

I suppose with my original post I just wanted to check that this is
what's intended, in which case the performance hit on getNextSibling
is acceptable (as someone pointed out, the documentation can
warn against it).

Alfie.

 ----------
From:  david.peterson@iname.com
Sent:  10 March 1998 13:48
To:  Alfie Kirkpatrick; www-dom@w3.org; mcc@arbortext.com
Subject:  Re: Question about getNextSibling/getPre

 --------------------------------------------------------------------------  
 --
Hi Alfie,

> Mike,
>
> Thanks a lot for the reply. My point is really that DOM nodes
> may contain nodes from different implementors, correct? So,

This is something I raised a while back, and currently, the answer is no   
 -
that is, the current dom interfaces don't have enough methods for this to   
be
possible.  Eg there is no setParent() method for a Node, so you can't
genericly set the parent - you have to cast to an internal, proprietry   
class
to do that.

I'm in favour of being able to do that - for one thing, as an   
implementor,
you could take bits and pieces from different sources and put them   
together
easily for display or modification.  Also, with XML, there is no single
standard set of tags, so nothing like the HTML Level2 could be   
accomplished.
You could, however, have extensions of Node, etc for a specific
implementation, and the application builder could easily plug them into
his/her own implementation.

> I might take an existing DOM structure and insert my special
> MyGraphicNode in there, which is an object which supports
> the Node interface but possibly in a very different way. Also,
> if an implementation supports previous/next pointers or an
> "index in parent" value, how can the insert method on Node
> actually do this, without knowing the precise implementation
> of the Node being inserted and the nodes it already contains?

This is exacly it.  This sort of thing could be done on the
(server-side?/client-side) script side, too, with the actual   
implementation
of the inserted nodes being completely unknown.

Perhaps there should be an EditorNode interface that is used by the nodes
internally.  Only a couple of methods would be needed (eg setParent())   
and
they shouldn't be used outside the implementation of the Node itself.

David

Received on Tuesday, 10 March 1998 09:27:54 UTC