[jdom-interest] Moving Subtrees using JDOM

Jason Hunter jhunter at acm.org
Sat Feb 23 22:13:14 PST 2002


Noam Tamim wrote:
> 
> --- Elliotte Rusty Harold <elharo at metalab.unc.edu> wrote:
> > >So how about adding the suggested elt.addContent(List) that will iterate
> > Either way, this is tricky. For instance, what if something in the
> > list doesn't need to be detached?
> 
> Well, after looking into it, this is what I came up with:
> a. While iterating over a getContent() List, you shouldn't try to
> detach() anything - the iterator's fail-safe policy will cause it
> to throw a ConcurentModificationExcepion;
> b. detach() is, as I understand it, merely a convenience method
> that calls parent.remove(this) on the node; so if I iterate over
> a live list, I don't even need it - I can simply use itr.remove().
> c. Since I don't need detach() anymore, I don't need to do any
> casting.

Excellent point!

> Therefore, a utility method that gets a live FilterList will look
> something like this one:
> public static void moveContent(List content, Element to) {
>   Iterator i=content.iterator();
>   List list=to.getContent();
>   while (i.hasNext()) {
>     Object o=i.next();
>     i.remove();
>     list.add(o);
>   }
> }

Good looking code.

> The remaining problem is handling document fragments that are not
> stored in one List (and may have different parents). It is not really
> a problem - it can be solved quite easily in fact - the problem is
> that one method can't deal with both cases. A method that, unlike
> the above moveContent(), is given a random list of nodes, must cast
> and call detach() on every item in it - but the detach must NOT be
> from the same list (see point a above).

Ah, filters will soon come to the rescue...

moveContent(elt.getContent(someFilterOnSubtree), to);

-jh-



More information about the jdom-interest mailing list