Re: Alternative to the Live NodeIterator

At 01:21 PM 4/27/98 -0400, Andrew n marshall wrote: 
>>>>
  
It seems like the concept of a 'live' NodeIterator is a very heavy demand
to place upon DOM implementors.  In fact, I don't think a single DOM
implementation deals with this yet.  I'm assuming the reason for this type
of demand is to make up for the fact that authors cannot override the DOM
Nodes.
<<<<
The reason is so that iterators immediately pick up any changes to the
underlying tree.  For example, if a DOM script starts before a page is
fully loaded, and the script iterates over all H1 elements in the page, the
script will hit any H1 elements that were actually loaded after the script
started iterating. This was one reason we went to an "iterator" paradigm
rather than a "collections" paradigm, since the notion of "live
collections" could be difficult to implement.

>>>>

  
 It seems to require that a globale list of all NodeIterators be maintained
somewhere, each with a abstract description of the search criteria.  Every
time a node is added (or worse, an entire tree), it has to compared every
search criteria and additional processing may be require to determine
ordering.
  
I certainly hope not!  It has always been my assumption that each
NodeIterator knows where it points to in the tree (e.g., "after the Node at
address 0xbeef0666"), and when a call comes to re-position the iterator or
return its next or previous node, it would use the tree itself to
re-position it properly.  If the iterator has search criteria ("filters" is
the current DOM terminology), then the filter would be applied before
deciding which Node to return.

In any event, I'm pretty sure this can be implemented on a dynamic,
iterator-by-iterator basis rather than requiring any global state.

If I'm missing something here, please straighten me out, because I'm pretty
sure that the working group has not anticipated any implementation problems
here.

Mike Champion

Received on Monday, 27 April 1998 13:42:58 UTC