[jdom-interest] Re: accessing Element.getChildren() elements with a ListIterator

[Ed Morehouse]

For those who asked why the ListIterator didn't work:

The set(Object) method seems to have no effect at all.  I see from the Java2
docs that this is an optional method, so i'm guessing it's not implemented in
the default ListIterator for LinkedList.  If this is the case, then perhaps (as
Jason suggested) we need to override listIterator() in PartialList and then
write a PartialListIterator class that implements ListIterator and all of its
methods.

Since the current philosophy for accessing an Element's children seems to be
through the List interface, and the current implementation of that List is a
LinkedList, it seems relatively important to have a way to do sequential access
and modification to child elements without having to start at the first index
and walk our way down what may in some cases be a very long chain each time we
want the next child.

That said, i'm not yet very familiar with the jdom source tree so if i'm missing
something, someone please do set me straight.  So...what do people think, do we
need a PartialListIterator, should PartialList be implemented using a different
AbstractList (a Vector, perhaps), or am i misunderstanding the situation and
need to be set straight?

-Ed


earlier I wrote:
> 
> I am also somewhat new around here and somewhat confused by the way to access an
> Element's children.
> 
> I have a case where I want to recurse my way through an Element tree, examine
> each node, test for a given condition, and possibly replace the Element at that
> node with a different one, based on the results of the test.
> 
> The following code fragment seems to work for me:
> 
>   protected Element processElementTree(Element element)
>     throws Exception
>   {
>     if (element.getName().equals("reference"))
>     {
>       // we need to dereference this element:
>       element = dereference(element);
>     }
>     else if (element.getChildren().size() > 0)
>     {
>       // this element has children so we need to recurse:
>       List children = element.getChildren();
>       for (int i = 0; i < children.size(); i++)
>       {
>         children.set(i, processElementTree((Element)children.get(i)));
>       }
>     }
>     else
>     {
>       // this element is a leaf node and is not a reference
>       // so leave it alone
>     }
>     return element;
>   }
> 
> However, I see that org.jdom.PartialList extends java.util.LinkedList, which
> means that accessing later elements grows increasingly expensive.  Thus, I would
> like to use a ListIterator to access the children, which should provide
> sequential access at constant cost:
> 
>   protected Element processElementTree(Element element)
>     throws Exception
>   {
>     if (element.getName().equals("reference"))
>     {
>       // we need to dereference this element:
>       element = dereference(element);
>     }
>     else if (element.getChildren().size() > 0)
>     {
>       // this element has children so we need to recurse:
>       ListIterator childIterator = element.getChildren().listIterator();
>       while (childIterator.hasNext())
>       {
>         Element child = (Element)childIterator.next();
>         childIterator.set(processElementTree(child));
>       }
>     }
>     else
>     {
>       // this element is a leaf node and is not a reference
>       // so leave it alone
>     }
>     return element;
>   }
> 
> I suppose i could do a toArray() on the List or something, but I thought that
> the reason for the List in the first place was so that you could do List style
> things to it.
> 
> Could someone please explain why the ListIterator approach doesn't work; if the
> fact that it doesn't work is a design decision, the basis for that decision; and
> if there are elegant alternative ways of doing this that I am missing, what
> those might be.

                                  ------------
 
 - The happiest of people aren't the ones 
   who always have the best of everything;
   they are the ones who always make the best 
   of everything they have.

                                           Ed Morehouse
                                           Software Engineer/Evil Genius
                                           The Motley Fool