[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