 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Struts - A MVC web framework | | Tomcat - JSP/Servlet container | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | | JSP - A mailing list about Java Server Pages specification and reference | |
Struts & Hibernate
|
|
|
| | | Requested modifications: Common Node interface, factory methods | Requested modifications: Common Node interface, factory methods 2003-12-13 - By Phil Weighill-Smith
Back
We are using (an extended) JDOM as an observable model within an MVC
GUI. To make this work we have had to extend the various "node types" of
interest to us (currently just Element, Attribute, Text and CDATA) and
the JDOMFactory to allow us to register "property change"-style
listeners on these node types. We have also provided a supporting XPath
class that can generate the relative or absolute XPath for an
element/attribute/text/cdata within the JDOM (given a contextual node
for relative paths).
This task would have been very much easier to implement with some
type-safety if all the various "node types" implemented a common
interface rather than relying on Object as the common reference. (I've
spotted that Parent and Child interfaces have been added to the CVS head
version, so it might be that these interfaces would do the trick, but
I've not looked in enough detail to be sure).
Another aspect that would be useful to support is the creation of
ContentList and AttributeList containers using factory methods (and
making these classes implement an extended interface that is "public"
within the JDOM API). We could then modify the behaviour of these
classes by extension/interface implementation, if needed, within Element
without garbage generation. (There could be other changes needed in the
general case too, but that's beyond what we currently do).
In addition, in order to make node insertion and deletion "observable"
in an appropriate manner and without the need to override every method
that could affect an Element's content (tricky because of the way that
getContent() and getContent(Filter) work!) we have augmented the
setParent methods on Element, Attribute, Text and CDATA to fire change
events. However, because of how parentage is established in ContentList
and AttributeList before insertion or removal of the node in the list's
"data array", our event notifications are made before the node is
correctly added or removed from the DOM hierarchy which breaks our
notification model.
To work around this latter issue we have made the changes identified in
the attached patch files.
This is patched against 1.0 Beta 9.
It would be great if someone could provide feedback on these three
points, and even better if these patches could be applied to the
official code base!
Phil :n.
PS: If the JDOM itself provided property change listening it would be
fantastic! This can be achieved with a single additional null object
reference within each observable "node" when change listening isn't
being performed so isn't much of a memory footprint overhead!
--
Phil Weighill-Smith <phil.weighill-smith@(protected)>
Volantis Systems
Earn $52 per hosting referral at Lunarpages.
|
|
|
