[jdom-interest] Events for JDOM

[Paul Libbrecht]

On Lundi, novembre 19, 2001, at 06:27 , Sébastien Pierre wrote:
> That's it. I have an application where I very often have to make small 
> modifications to an element content, in this case it is slow to create a 
> new list per modification and then call the setContent() method. Having a 
> mutable list would accelerate my application. BTW, was is this FilterList 
> ?


The problem that you can't use the whole power of the list returned by 
getContent and others (like getChildren) is sort of well known to JDOM 
developers, I think.
The problem is simple: such lists as the ones returned by getChildren() in 
all flavors are "PartialLists" that is they are a sublist of the content 
list. However, there is no such notion of real sublist in the collections 
API... hence there was PartialList. But the latter is too weak.

Browsing around the TODO.txt file, you find comments that FilterList 
should find its way through a major version... a "filterList" is simply a 
list with a matching object. The class is accessible from jdom-wip (?) CVS 
module.
The code present there implements all the good characters you would expect 
of a sub-list, including the ability to remove, add or replace, using a 
listIterator.

As I am really only using getContent currently (or just "reading" 
iterators for the others), it was enough to simply change the getContent 
method to really return the content list. There must be a reason why it 
did not. I could not find it.

>> Well... I'm currently trying to perform the implementation of these 
>> "Recipes"-like event. I have almost a kind of interface.
>
> I would be interested on some details about that :)

I hope to post this publically sooner or later...
Maybe this could find its way into the JDOM package or contrib...
Anyone intersted by prior perfectly incomplete source snapshots ??

>> In particular, in order to perform this removal, you need to go to the 
>> parent, iterate through the content and remove the element then.
>
> The disadvantage of having number in children is when you do the 
> modification on the parent you also have to iterate through the children 
> to update their number in the list, so you haven't gained anything in 
> this case.

Sure, that all depends on the actions you perform (e.g. building a 
document in the inversed sense would be real expensive). Using something 
like a "GapVector" (as in javax.swing.text) would probably be the best 
solution (but, grrrr, it's not in java 1.1!!).

If the list was a LinkedList, the element could point to the ListEntry  
which has a next and a previous (I think I'd prefer this solution but it 
may be more memory greedy).

Another formulation would be simply that... one can provide me with 
getNextSibbling() and getPreviousSibbling(). This, the listEntry() or the 
number access would be any of the solutions which would allow me to avoid 
this iteration through child-content to "find where the element to remove 
is".

Paul