The TreeWalker state [1] is dependent only on its currentNode and it
could be implemented totally independent of the underlying DOM
implementation. NodeIterator state however is dependent on a reference
node [2] which could change while the underlying tree changes which
makes the NodeIterator implementation dependent on the underlying DOM
implementation, or at least the DOM should have Mutation Events
support (relying on which could be not as efficient as using internal
state control).
As I can not wait for the concluding the NodeIterator implementation
support, I'm readdy to try something with TreeWalker (it is not so bad,
I know :)). So, let me ask first if it this the right mail list to
asking question related to TreeWalker ? If so, here we go (if no, point
me the one, please):
** I'm able to build a custom DOM tree from the original DOM tree using
the following peace of code :
/************** quoted filter method **************/
if (node.localName == "IMG") // for images
return nodeFilter.FILTER_ACCEPT;
else if (node.contentDocument )// for frames
return nodeFilter.FILTER_ACCEPT;
return nodeFilter.FILTER_SKIP;
/************** walking **************/
// walk the TreeWalker tree...
if(walker.firstChild()) {
do {
/* quoted */
addTree(walker, destNode);
} while(walker.nextSibling());
// don't forget to return the treewalker to it's previous state
// before exiting the function
while (walker.parentNode() != null);
}
But, should these steps create a new DOM tree from the original
(containing the "accepted" nodes only) ? Or will the filter be applyed
everytime that a walking-through is requested ? I mean, an "inline"
walking ...
ps: there is a lot of documentation available on the net, but all of
them are ambiguous at this point.
regards
Antonio Gomes
Nokia Technology Institute
_______________________________________________
mozilla-layout mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-layout
