RemoveNodes function - accepts XPath

[Hoss]

Hello.

Because IE and Mozilla have such completely different XML
implementations, I have created a class to handle general XML tasks,
such as iterating over nodes given an xpath, evaluating an xpath, ect.
It does all the branching for the different implementations within
itself. I am working on a new method for this class that will, given an
xpath, remove all nodes that match from the document. It works great in
IE, heres the IE code.

var nodeList = this.xdoc.selectNodes(xpath);
for(var x = 0; x < nodeList.length; x++)
{
nodeList[x].parentNode.removeChild(nodeList[x]);
}

However, Mozilla has a different way of doing things, and to evaluate
an xpath you have to specify if you want an iterator result, a snapshot
result, or a firstnode result type. Heres the problem:

If I return an iterator results type from the xpath, and then iterate
over the results, the iterator becomes invalid once I use the iterator
to modify the document tree . . . so that wont work.

If I return a snapshopt type from the xpath, and then loop over that,
each item is now disconnected from the document tree and modifying them
doesnt affect the document tree at all. So that doesnt work either.

Surely someone has tried this before ??? Heres my best efforts in
Firefox

var iterator = this.xdoc.evaluate(xpath, this.xdoc, null,
XPathResult.UNORDERED_NODE_ITERATOR_TYPE, null);
var theNode = iterator.iterateNext();
while(theNode)
{
theNode.parentNode.removeChild(theNode);
theNode = iterator.iterateNext();
}

 

[Bjoern Hoehrmann]

* Hoss wrote in comp.text.xml:

If I return a snapshopt type from the xpath, and then loop over that,
each item is now disconnected from the document tree and modifying them
doesnt affect the document tree at all. So that doesnt work either.

This sounds like a bug. What you can do then is to use an iterator,
collect all the nodes into a separate Array, and once iteration is
complete, iterate over the array and remove each node as you go. As
you modify the document only after you no longer need the iterator,
invalidating the iterator would be no problem for your application.

 

[Hoss]

Gosh .... how is it possible that I didnt think of that !? Thanks
Bjoern, works great.

 

[Martin Honnen]

If I return a snapshopt type from the xpath, and then loop over that,
each item is now disconnected from the document tree and modifying them
doesnt affect the document tree at all. So that doesnt work either.

Is that your reading of the W3C DOM Level 3 XPath note or your
experience with Mozilla?

Obviously if you want to remove nodes then they are disconnected once
you remove them. But if you remove one node from the list the snapshot
gives you then you can still work with the other nodes in the snapshot
to remove them.
Simple example is here:
<http://home.arcor.de/martin.honnen/xslt/test2006122801.html>
Works fine for me with Mozilla (tested with Gecko 1.7, 1.8.0, 1.8.1) and
with Opera 9.

 

[Hoss]

Yeah, this is from practical experience with Mozilla. And really, the
whole point of a snapshot is to have a nodelist that isnt connected to
the document tree from whence it came. That way if you wanted to take 5
minutes going through all the nodes your guaranteed that they will
exist in the snapshot the way that they existed in the document tree at
the time you ran your xpath. With an iterator, during that 5 minute
time-frame, some other process just might have mutated the document
tree; so of course your iterator has to then be invalidated.

Obviously if you want to remove nodes then they are disconnected once
you remove them. But if you remove one node from the list the snapshot
gives you then you can still work with the other nodes in the snapshot
to remove them.

Martin Honnen
http://JavaScript.FAQTs.com/

What I am saying is that once you SNAPSHOT - poof - the thing you have
is already a separate entity from the original document tree. That
means that if you discombobulate every node in the snapshot, the
original document tree remains intact. Thats the point of a snapshot,
but it also means you cant use one to modify a DOM, which is what I was
trying to do.

 

[Martin Honnen]

What I am saying is that once you SNAPSHOT - poof - the thing you have
is already a separate entity from the original document tree. That
means that if you discombobulate every node in the snapshot, the
original document tree remains intact. Thats the point of a snapshot,
but it also means you cant use one to modify a DOM, which is what I was
trying to do.

Why does that test case
<http://home.arcor.de/martin.honnen/xslt/test2006122801.html>
then remove the nodes from the original document tree?

 

[Joe Kesselman]

Also see the discussion of nodelist's quirks at at
http://www.w3.org/DOM/faq.html. (My personal opinion has always been
that nodelist was a design mistake, but I'm told there was a specific
member of the DOM Level 1 working group who insisted that their
customers would prefer a broken array-like behavior to learning about
tree behavior. The Traversal functions in DOM Level 2 are somewhat more
robust.)