[jdom-interest] Re: JDOM events

[philip.nelson at omniresources.com]

> Could you please point out the kind of problems you encountered
> trying to build a event system ?

hadn't done it yet, that's why this thread is interesting ;-)

> 
> At the moment I have 'only' two problems:
> 1. FilterList
>     FilterList is final so I can't subclass it, and the 
> Filter interface
>     is to narrow to fire events.

the perfect argument for a decorator.  In this case it would be more work
than a wrapper though but the end result is in your subclass:

public List getContent() {
	return new ListenableList(super.getContent());
}
	
> 2. Design decision: Do bubbling ???
>     The decision is: Having a hierarchic or a delegation type 
> event system.
>     Have both ? There are pros and cons on both types.
>     At the moment I have implemeneted delegation type events.
>     A listener has to register itself at each element, 
> attribute, etc. to
>     get notified of changes of THIS object. The listener will NOT be
>     notified of any changes in child or parent objects.
>     But there are some use cases where a hierarchic type would rock.
>     Example:
>         You have table style data:
>             <data>
>                 <row .../>
>                 <row .../>
>                 <row .../>
>             </data>
>         Let' say 1000 rows, 50 columns.
>         Now I want to show this data in a JTable via a TableModel.
>         That means I have to navigate through 50000 objects and
>         call addJDOMListener. There are some optimizations possible,
>         but it's simply ugly.

putting 50000 elements in a table model probably has more problems than just
adding listeners and so far I have just tried to avoid the situation
entirely.  Here are some ideas that could help whether wrappers, decorators
or jdom subclasses are used  as they all have similar issues with this
problem.

- add the listeners in your customized JDOMFactory.  If you already know the
elements that will go with particular listeners, you can skip the xpath
business altogether and select specific listeners to go with specific nodes.

- only add listeners to elements currently being displayed and refresh the
model and nodes with listeners as items come into view. This could be hard!
It is also appropriate in working with large data sets and many ui controls
work this way with databases, at least in as much the full set of data is
not retrieved until needed.

- add a methods that will allow you to walk up the tree until you finds an
element with a listener and call that.  You may be able to further qualify
the walk up with specific attributes on certain nodes in your case because
the document is specific to your app.  So each node by default has a
"DelegatedListener" instance which can be replaced by a real "Delegatable"
listener.  The real listener would have to have a way to be called from
outside the node.  The delegated listener is called whenever the node is
changed.

These are ideas are for discussion only and your mileage may vary :-)

>     Registring at an element with xpath would be nice.
>     Something like: data.addJDOMListener(listener, "./row/*").
>     I have also implemented that stuff, but the performance 
> is terrible
>     poor, <snip>

>     I tried to integrate this into the werken.xpath package, 
> but it never
>     worked stable.

Behind the scenes it would still have to do the first part.  And it will
never be fast on large documents unless it has some way to index the search.
String comparisons are costly.  The Werken xpath library is undergoing a
complete rewrite, by the way.

>> With 
> this sort of
> > binding you have other problems as well: validation, 
> threads come to mind.
> 
> Why you dont have this problems with wrappers ?
> The problems are not that obvios, but they are still there.
> 
You can put validation code in the wrappers, call it from a wrapper in a
application specific class and then update the actual element.  With
threads, *if* you can share the reference to the wrapper, you can simply
syncronize your own customized methods.  If not, then the wrappers can
syncronize on the element/attribute instance so long as *all* your code does
it that way.  In the element/attribute you can't arbitrarily syncronize the
existing methods in a subclass and would have to add new ones anyway.

Really, I just think the architecture is cleaner this way as both of these
things could be solved in subclasses.