[jdom-interest] Optimized Lists

[Bradley S. Huffman]

Yep, in Element.setText, content.add(Text) needs to be a addContent(Text).

As for ContentList, I think you'll find a lot more gotcha's as you continue
experimenting. A few things to look at:

1. Maintain the contact that set-List style methods (i.e. setContent(),
   add( Collection), add( index, Collection), etc.) upon failure leave
   *both* lists unchanged.

2. Re-implement all of the methods in the List interface.  For example,
   currently you only re-implement remove(int) hoping that the other
   removes will use this re-implementation to do their work. Not
   safe at all.

3. As a sanity check, I think one should check that a child is the child
   of the parent before trying to remove it or change it's parentage
   to null, otherwise there is probably a logic error that the programmer
   would like to know about.

4. As for removing setParent from the Filters, I thought about this too,
   but maintaining sanity in the FilterList (especially for getChildren)
   led me to leave it in and make sure the side-effect is documented in
   the javadocs. And since it's not visible outside the package, and as
   long as it is sane and correct, it's not that big of deal.

5. Duplicate Attributes, single root element?

The Filters encapsulates the sanity checks and verifications for add
and removes in one location, the same way Verifier encapsulates most
common XML standard checks.  Now DocumentContentFilter, ElementContentFilter,
and ElementFilter could be merge into one Filter with setXXXX() methods.
But since they are not visible outside of the package this can be
done later and does not effect the user's view.

Granted having AttributeList (or Set?), ContentList, DocumentList sounds
good at first, and after thinking about it some more, I think as Alex
eluded too, the real stickler is getChildren() and you'll probably end up
with something like a Filter applied to ContentList (i.e. another incarnation
of FilterList?).  Even with getChildrenIterator you'll have most of the same
issues as FilterListIterator (that nasty remove method :). So instead of
three separate implementations of List to maintain, we may as well cleanup
FilterList and the filters where they need it and continue with them
for now.

But all this is/should be invisible to the user and IMHO it is more
important to make sure JDOM's behavior is sane, correct, and
maintainable. It is also more important to decide what should/shouldn't 
be in the API (the part the user sees).  Implementations will change.

Which I've done (ftp://a.cs.okstate.edu in pub/hip/jdom-new-filter.zip).

That wasn't meant to blow my own horn, it's just I've been pouring over
this code line by line for a while now and been bit by quite a few
gotcha's. But what's out there, I think is clean and correct in terms
of well-formed XML, does sane adds/removes, correct parenting, handles
duplicate attributes, handles nulls, and detaching root.  It correctly
does what is expected through both Element/Document methods and through
the List's returned by getContent/getChildern.  Now, there might be minor
bugs like setText (which I didn't catch either), or tweak here and there.
But again, if not there yet, I think it's close, very close.

If nothing else look at code (and javadocs) and maybe save yourself a few
gotcha's.  And if you or someone else comes up with a better way great, but
make sure it's correct and try to cover all bases.

Brad

[Man, someone pull that soapbox out from under me]