[jdom-interest] Using and extending JDOM

[Hallvard Trætteberg]

Hi all,

I've just recently begun using JDOM and have a couple of comments to the
current version (B7). But first I would like to say I've very pleased with
the package, it tastes and feels like Java and is very natural to work with.

There are three things I would like to comment on: factories, handling of
identifiers i.e. ID attributes and mutation listeners.

Factories: In the project I'm using to learn JDOM, I want to generate
instances of different subclasses of Document, dependent on the document
type. The natural solution was to make a factory that checked the document
type or root element, before selecting the appropriate Document subclass.
However, this information is not yet present when making the Document
instance, even though there are Document constructors that take the docType
and rootElement as arguments. For me it seems natural to delay calling the
factory's document method until this information is present, so at least the
document(docType) method could be used, but preferably the document(docType,
rootElement) method. In general, it seems useful to be able to choose the
factory after the docType and/or rootElement names have been identified,
e.g. a method on builder named getFactory(DocType docType, String
rootElement). Note that builder would have to have a default factory to make
the DocType instance.

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="..."> and <path
location="...">. In the absence of the DTD, it seems natural to implement
this logic in an object that has access to the docType declaration and/or
rootElement. I've implemented such an object for my specific document types,
and use it for building up links between attributes. This IdRules object
decides which attributes are IDs and IDREFS and links them together by
replacing the existing Attribute instances with instance of subclasses of
Attribute (IdAttribute and IdrefAttribute, which has an extra reference to
the corresponding IdAttribute), with the same names, namespaces and values.
Later, these links are used by the main application. The id mappings are
stored in the Document instance, so these can also be accessed through this
object. For me it seems natural to support this kind of ID handling in JDOM
i.e. 1) deciding which attributes are IDs and IDREFs based on the docType
and rootElement, and 2) using special Attribute instances to handle the
links. Ideally, this should all be handled during building, instead of in a
second pass as I do now.

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?

Hallvard Trætteberg, PhD student at IDI, NTNU
http://www.idi.ntnu.no/~hal, mailto:hal at idi.ntnu.no, phone:+47 7359 3443