[jdom-interest] Using and extending JDOM

[Alex Rosen]

Sorry for the late reply.

> 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.

There's a related issue that might help you. Jason has always felt that JDOM
should make it impossible for you to create a non-well-formed Document in
memory, where reasonably possible. This includes creating a Document without
a root Element. The current Document lets you pass in null for the root
Element, but only because the current SAXBuilder requires it. SAXBuilder
first creates the Document, and then adds to it whatever children it
encounters (DocType, root Element, PIs, Comments, etc).

I've never thought it was such a big deal to prevent you from creating a
non-well-formed Document, especially in this case, when it's often very
convenient to create an empty Document and then add stuff to it. (Like
SAXBuilder does.) But, if we still feel that's bad, then SAXBuilder should
be changed to create the Document last. It would save up the DocType, root
Element, and all the other Document children, and then when the parse was
finished, it would create the Document using JDOMFactory.document(Element,
DocType), and then add the other children.

This would coincidentally fix your problem as well. Want to volunteer?

[BTW, looking at Document.java, it looks like we need the attached fix. When
replacing one DocType with another, we should probably unset the departing
DocType's parent.]

> 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?

Check out the file TODO.txt in the CVS tree:

* Consider a listener interface so you could listen to doc changes.
  (Probably after 1.1 honestly; this can be done through manual subclasses
  already.)  Some pertinent messages on this topic:
  http://lists.denveronline.net/lists/jdom-interest/2000-July/001586.html
  http://lists.denveronline.net/lists/jdom-interest/2000-July/001587.html
  http://lists.denveronline.net/lists/jdom-interest/2000-July/001600.html

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Document.java.diff
Type: application/octet-stream
Size: 559 bytes
Desc: not available
Url : http://jdom.org/pipermail/jdom-interest/attachments/20011124/525108f0/Document.java.obj