[jdom-interest] Optimized Lists

[Alex Rosen]

Overall, I think this is a fine idea. Some observations:

- Look at the checks in the current ElementContentFilter - you also need to
check that the item doesn't already have a parent, etc.

- You'd probably want a DocumentContentList for Document too.

- Since most of the code is identical, I certainly think this warrants a
commonn abstract base class.

- This has all the same problems that FilterList currently has, when one
item in a list has a problem in addAll(), etc. E.g. imagine the 3rd item is
not of the proper type (or already has a parent, or whatever). The list will
then be in an inconsistent state. Look in the current FilterList
implementation for "XXX" to see where it has this problem. (I forget if Brad
wrote a patch that fixes this, that hasn't been incorporated.)

So I guess all the current Filters would go away except for
ElementContentFilter. And we could get rid of Filter.matchesAll(), since
Filter would now only be used to actually filter lists (i.e. when matches()
might actually return false). I'm curious to see how the gatekeeping
function of your new lists and FilterList would co-exist in the
getChildren() case.

Jools or Brad, does this interfere with your ideas for Filter?

> 3. Change all the parent assignement, in Element, Filter class
> Rq: why does the can...() in the Filter classes also do the
> job of changing the parent? I think these function just have
> to check if it is enabled, but no do the actual action.

I agree, I always thought they should be two separate methods. This is
cleaner, and it means that the inconsistent state problems mentioned above,
at the expense of iterating through the addAll() list twice (once to check,
and once to commit). (The other way is to catch the problem after the fact,
and undo the changes made before the invalid item was found.)

Alex