[jdom-interest] JDOM JSR
philip.nelson at omniresources.com
philip.nelson at omniresources.com
Thu May 17 06:41:42 PDT 2001
> I would really like to know the design decisions for JDOM and their
> reasons. Its just because its seems to be contrary to all I
> have learned
> and have experienced.
That statement implies that the only way to do it is with interfaces and
factories??
> (Initially I asked for pointers to the
> discussion
> and suggested an entry in the FAQ. Later I found some similar
> questions
> and suggestions.)
These decisions were made a long time ago and *very* publically. There was
certainly dissent and a follow up discussion led to dom4j. The whole thing
is available in the list archives.
>
> I am just starting a new project and have to choose the tools/APIs. My
> current impression is, I should give dom4j a first try, because I
> understand their design decisions.
If you can't live without factories and interfaces, you probably won't be
happy with JDOM. Myself, I appreciate every day being able to say
Element el = new Element("name");
Later today I will send out the updated version of Ken Rune Hellend's
JDOMFactory code which will allow you to say:
//override toString for debugging
class superElement extends Element {
public String toString() {
return "a subclass" + super.toString();
}
}
SAXBuilder builder = new SAXBuilder();
//use an inner class to override the element factory with my
SuperElement
builder.setFactory(new DefaultJDOMFactory() {
public Element element(String name) {
return new superElement(name);
}
});
Document doc = builder.build(new FileReader("afile.xml"));
Viola, easy subclassing. This still doesn't make JDOM the perfect, most
flexible api. While experimenting with decorators, I would have liked an
interface for each of the base JDOM types so I wouldn't have had an orphaned
super class. However, in a year+ of using JDOM myself, and about the same
time answering questions for users, those use cases have been rare. On the
daily basis the concrete classes are exactly what I want. You will have
subclassing, decorating, implementation of new interfaces, ability to add a
vistor, all available to you easily. To me this is a good compromise.
More information about the jdom-interest
mailing list