[jdom-interest] Listeners

[Phil Weighill-Smith]

We do something very similar to this using a pattern based on the
standard JavaBean property change listener mechanism. We found that we
had to:


      * specialize all the JDOM "node" types that we use in our
        documents (Document, Element, Attribute, Text and CDATA)
      * have our own specialist JDOMFactory to create our node types
      * make sure that those methods that explicitly create these JDOM
        classes in these node types are overridden to create our ones
      * add the same listener management and fireEvent code to each
        specialization (instead of property names we have a type safe
        enumeration that identifies the type of change, e.g. name
        change, creation, deletion, attribute value change etc.). NB: we
        used a standard interface for the listener management aspects,
        see below.
      * make sure that we augment the various methods in the JDOM
        classes that modify the DOM in ways we are interested in
        (mapping to our type of change enumeration) to call fireEvent in
        the appropriate places.


The main difference (other than not having property names) between this
an the property change listener model is that a notification propagates
up the hierarchy, so for example, assuming a document exists with a root
element thus:

JDOMFactory factory = new OurFactory();
Document d = factory.document();
Element e = factory.element();
document.setRootElement(e);

A call to add an attribute "a" to the element:

e.setAttribute("a", "value");

would notify a listener on "e" of the creation of the attribute "a",
then notify a listener on "e"'s parent of the creation of the attribute
and so on up the hierarchy to the document itself.

NB: We specifically changed the behaviour of Element.setAttribute to
update the attribute if it already exists rather than always creating
the attribute (which is what JDOM does - at least in 0.9 which is what
we use).

Adding listeners clearly requires casting the JDOM nodes to something we
can access - we made all our specialist node types implement a common
interface that provides the listener management.

Because we have our own factory it is possible to use the normal JDOM
builder to build a JDOM with instances our classes.

Anyway, this isn't a simple 1 day job, so only do it if you really need
to!

Good luck!

Phil :n.

On Tue, 2004-07-06 at 14:06, Daniel Perry wrote:

> I've been searching through the mailing lists for info on adding Listeners
> to monitor changes in documents, etc.
> 
> So far i've figureed out that these listeners dont exist, and every
> proposal/idea that i've come accross in the lists are concerned with events
> at the element level.
> 
> I am trying to work out how to do it at the document level.
> 
> I'm using jdom to work with config files and data files. In a current
> project i need to save these files when they are changed.  I would rather
> somthing at a core level does this through a listener rather than call a
> method after changing anything.
> 
> ie at the moment i am doing:
> 
> _someElement.setText("newValue");
> // somehow get a reference to an xmlHandler class that is responsible for
> this document, then...
> xmlHandler.save();
> 
> I would rather do:
> 
> _someElement.setText("newValue");
> 
> and have the Document the element belongs to fire off an event through a
> listener.
> 
> Does anyone have any suggestions on how i can do this?
> 
> As far as i can see, i would have to extend element and add a reference to
> it's document.  I would have to also override any methods that change
> content to fire off an event through the document.  I would have to extend
> document to add the listener methods.  I would then have extend saxbuilder
> and make it use these new types.
> 
> Is there an easier way to do this?
> 
> Thanks,
> 
> Daniel.
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Phil Weighill-Smith <phil.weighill-smith at volantis.com>
Volantis Systems
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20040706/2452a527/attachment.htm