[gdome]NodeList...

[Paolo Casarini <casarini CS UniBO IT>]

The first way to make live the Nodelist (as implemented now) is to create
a list of active nodelist in Document or in DomImplementation object and  
add to all functions that change something in the libxml tree a call to a
function that rebuild all the active nodelist.

The second way is to change the Nodelist implementation in a way that it's 
similar to a "lazy" implementation.
I explain now the behavior for a tagged Element Nodelist (all the other
situations are similar).
When I ask for a Nodelist (getElementByTagName) I create a structure with
a GdomeNode *root that point to the root of the subtree interested and a
GdomeDOMString *name that save the tagName wanted.
Now, I don't make any other structure and when I call item(int n) or
length methods of the Nodelist I make a preorder traversal on the libxml
tree to retreive the data.
With this kind of implementation the Nodelist is simply a view on the
libxml tree.

Computational cost aspects:
The item and length cost are O(n) in both cases, but n in the second way
is greater than in the first because in the first way we discard the node
that aren't XML_ELEMENT_NODE and haven't the right tag in the creation of
the Nodelist. 
The creation of the nodelist for the first way is O(n), for the second way
is O(cost).
To keep live all our nodelist in the first way we have a cost of
O(k*n) where k is equal to the number of nodelist alive in the moment,
while in the second way we have to do nothing.

If we want that Nodelist are live the second way seems to be the
better. We can make some non standard mothod to iterate on elements that
works in O(cost). Perhaps next() and reset() methods that work on a
pointer in the subtree.

I've already implemented the second way and works fine! I commit it soon.

Thanx
Paolo
--
Paolo Casarini - casarini cs unibo it