- From: Stephen R. Savitzky <steve@rsv.ricoh.com>
- Date: 03 Nov 1998 18:59:21 -0800
- To: www-dom@w3.org
Claude Zervas <claude@utlco.com> writes:
> Again, I think that in light of all the severe disagreements about
> NodeList 'liveness' and iterator behaviour there should be a branching of
> the spec for applications that are not designed for naive script writers
> and where performance is of foremost importance.
THANK YOU! THANK YOU! THANK YOU!
I was beginning to think I was the only one with this opinion.
> This 'server-or-whatever' DOM would have at least the following
> characteristics:
Call 'em "features", and make their presence or absence detectable using
DOMImplementation's hasFeature method.
> 1. NodeLists do not need to be 'live'
>
> 2. Node.Next/PreviousSibling attributes are deprecated or are simply
> convenience methods that may (or may not) be horribly slow.
firstChild and parentNode, too.
> 3. Iterators are introduced and provide behaviour that may
> be undefined if the tree is modified underneath them.
> I would also be ok with the idea that the iterators simply
> throw an exception if the tree is mutated.
Throwing an exception requires an O(log N) test somewhere.
I would like to see iterators with something like the following interface:
interface Iterator {
readonly attribute DOMString nodeName;
attribute DOMString nodeValue;
readonly attribute unsigned short nodeType;
readonly attribute Document ownerDocument;
boolean toParentNode();
boolean toFirstChild();
boolean toPreviousSibling();
boolean toNextSibling();
void insertBefore(in Iterator newSibling)
raises(DOMException);
void insertAfter(in Iterator newSibling)
raises(DOMException);
void replace(in Iterator replacement)
raises(DOMException);
void remove()
raises(DOMException);
void appendChild(in Iterator newChild)
raises(DOMException);
void prependChild(in Iterator newChild)
raises(DOMException);
boolean hasChildNodes();
boolean isReadOnly();
Node cloneNode(in boolean deep);
Iterator cloneIterator();
void close();
boolean toNamedChild(DOMString name);
Iterator iterateAttributes();
};
Note that this has essentially all the characteristics of Node except that
you can never get at the node itself (though you _can_ get at a _clone_ of
it) or its children. Such an iterator can be used, for example, to traverse
documents that are never entirely present in memory, or exist on a remote
server.
Note also that all the structure-modification interfaces also take
Iterator instead of Node. This lets you manipulate a document without
ever constructing a single Node -- you could make your parser be an
implementation of Iterator.
A practical DOM would, of course, have both Iterator and a NodeIterator or
TreeIterator that operates in the ``classical'' manner, with an accessible
current Node and taking Node operands for the editing operations. Probably
a variety of others (e.g. ReadOnlyIterator) as well.
> 4. EntityReferences are really references and no copying is done.
With a method, getReferencedEntity(), to do the obvious.
> It would also be nice to have a standard DOM factory for creating objects
> outside of the context of a document. This is very useful for creating
> partial documents that can be used in templates, etc. (I'm thinking HTML
> DOM here).
I agree.
--
Stephen R. Savitzky Chief Software Scientist, Ricoh Silicon Valley, Inc.,
<steve@rsv.ricoh.com> California Research Center
voice: 650.496.5710 fax: 650.854.8740 URL: http://rsv.ricoh.com/~steve/
home: <steve@starport.com> URL: http://www.starport.com/people/steve/
Received on Tuesday, 3 November 1998 21:54:04 UTC