[jdom-interest] Re: Events for JDOM

[Paul Libbrecht]

Hi,

I also got recently also interested to events for JDOM.
Events I could see around are javax.swing.event.DocumentEvent and W3C's 
DOM ones.
I'm a bit surprised by DOM again (it feels and looks like a browser)...
Simply, I consider it "way an overkill" that any mutations made on a any 
JDOM node would fire events by themselves.

What I mean is that the JDOM API is sufficiently simple currently so that 
the code is readable. Inserting the need to fire an event for any mutation 
would make a huge code pollution which I really really don't like.

Why not act the other way around ? If you want your mutations to fire 
events, build your event yourself with classes that can perform the 
mutation. You can then send that same event everywhere a listener would 
exist (adding listening for each node, bubbling and capturing policies 
would not be a killer probably, this should really be a small optional 
piece which should have almost no impact on memory if one doesn't want it)
.

Among the advantages of such a strategy would be that your events could be 
undoable or redoable (they could be queued)  This together with XPath 
(that will come one day for JDOM), could allow, later, to maintain two 
mirrored instances. One would then use more abstract events which would be,
  precisely, built using XPath references instead of pointers to objects.

This would, at least, keep the simple usage of JDOM simple.


I think there has been a discussion about making events for JDOM in July, 
among others, Philip Nelson was planning such a development. Has anyone 
gone further, I haven't seen anything close to this in the cvs repository.

Paul




On Mardi, novembre 13, 2001, at 07:57 , Hallvard Trætteberg wrote:
>
> Mutation listeners: The DOM standard defines a particular way of defining
> listeners that are notified when the tree structure changes, e.g. elements
> and attributes are added or removed. In my application, which uses the 
> JDOM
> tree as its main structure (due to its flexibility and ease of streaming)
> ,
> it would be very useful to be able to listen to changes. In the DOM
> standard, a specific way of propagating events down (capturing) and up
> (bubbling) the tree is described. I'm not sure this is what JDOM should
> adopt, a more lightweight approach should perhaps be considered. E.g. its
> useful to be able to quickly check whether a particular event is listened
> for, to avoid generating unnecessary event objects. Is something like this
> planned?
>


By the way, you also mention another addition to JDOM, the handling of ids.
..

> Handling of IDs: ID and IDREF attributes are used to link elements to each
> other, across subtrees. Most documents I've seen use naming conventions to
> convey whether they're IDs or IDREFs, e.g. <location id="...">

I have only one answer... this will have to be solved once the 
identity-crisis of XML community for IDs is solved... see, for example, 
http://www.ibiblio.org/xml recent news.