[jdom-interest] Adding a DocumentListener interface

[John Pearcey]

I'm working on a project that also requires notification of changes. So far,
I've inherited from whatever DOM implementation I've been using and got the
code to build an instance of my class instead of the supplied one. With the
DOMBuilder class, I had to write my own adapter. It should be a simple
addition to add a class name of the type of document to build in all the
adapters. Basically, I'm demanding that all changes go through the DOM ( or
JDOM ) and I'll over-ride the mutator methods to send events as well as call
the super class. It works OK.

I'm tying to use the SAXBuilder in this way but no luck so far.


>
>I am also working on this project with Ken. We were thinking about writing
a set of
>wrapper subclasses for the document/elements, but we were unsure of how to
go about
>coercing the parser to create Element wrapper subclasses (in lieu of normal
>Elements) without changing the JDOM code. Is there something that we're not
seeing?
>
>---- Original Message ----
>
>I have a need for this functionality too, but only when users are
>interactively creating and modifying documents. The rest of the time when
>I'm parsing and processing XML documents, these features are unnecessary.
My
>approach and recommendation is to write a set of wrapper classes. The GUI
>works with XML documents using the wrapper classes as proxies for the JDOM
>classes, and the rest of the system uses the lightweight, efficient JDOM
>classes themselves.
>
>Keep JDOM simple, don't add a feature that's only going to be of benefit to
>a subset of applications.
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourho
st.com