Re: Implementing NodeList

Joe,

>NodeList is a very powerful concept -- but if I'm reading the Draft
>correctly, it's so powerful that none of the obvious implementations seem
>to be adequate. It has two characteristics that I haven't yet figured out
>how to offer simultaneously without rather painful amounts of overhead:

Unless you think a big pain in the butt is a very powerful concept, I guess
we disagree.  It makes a lot of sense for scripting crowd however.

>a) It's "live". As I read it, that means that not only are the listed nodes
>individually live (which is trivial), but that the NodeList itself is
>updated when nodes that it would have found are created and destroyed.

Correct.

>b) It's an ordered list. I'm reading that to imply the same order that the
>nodes are found in the document -- or, viewed from another angle: if I
>request a NodeList, add a node, and request another NodeList, all nodes in
>both lists have to have the same indices. (If not, life becomes MUCH
>simpler by eliminating the need to determine the proper insertion point
>within the NodeList.)

Again correct..

>Does anyone have a good efficient architecture for this (and if so, would
>you be willing to share any hints)? Or does the fact that the document
>explicitly doesn't "define or constrain" imply that the spec's authors are
>having as much trouble finding an elegant solution as I am?
>
>Many thanks in advance! I have the distinct feeling that when I see the
>reply, I'm going to pound my head on the table ... but I hope it'll be
>because I missed something obvious.

The solution is quite simple for the needs of the DOM Core API:  Let the
Node itself be the NodeList so its live and updated as the node changes.
Spiritual explanation is that 'Live' implies 'Being' (?!?).  The problem of
synchronizing multiple instances of NodeList is best solved by having only
instance.

DOM HTML API is somewhat more complicated but not overly so.  Let the list
of objects (i.e. forms) implement NodeList directly and arrange
insertBefore, appendChild, removeChild, etc to update the appropriate list.

The real implementation problem is the apparent conflict between index-based
enumeration and getXXXSibling-based enumeration.  There is no simple
solution to this if you want to perform both types of enumeration fast.
Current implementation of Free-DOM
(http://www.docuverse.com/personal/freedom/index.html) favors index-based
enumeration.  Next version of Free-DOM will have some optimization to
increase the speed of getXXXSibling methods for most situations (two weeks
from now).

Have fun,

Don Park
CTO/Docuverse

Received on Sunday, 26 July 1998 21:16:41 UTC