[jdom-interest] Ideas for API changes

Jason Hunter jhunter at collab.net
Sat Apr 28 15:43:56 PDT 2001

Noam Tamim wrote:
> Hi.
> I'd like to suggest some changes to the JDOM API. The first two are more
> significant, the others are just a matter of convenience:
> * Make the classes Attribute, CDATA, Comment, DocType, Document, Element,
> Entity, ProcessingInstruction implement a common interface "Item":

We've been through this before, only in previous iterations the common
interface was called Node.  

Here's my challenge to you:  Figure out the interface of Item.  Keep in
mind that any method declared should be useful across all classes
implementing the interface.  And keep in mind the interface should be
useful for more than just being a common base interface.  Object is good
enough at being a common base; there would need to be extra value.

> * Change overloaded versions of Element.addContent(..) to a single
> addContent(Item) method.

Hmm...  Is Document an Item?  If so you'd now allow Element to have
Document as a child.  Is Element an Item?  If so and you had
Document.addContent(item) you'd now allow more than one element to be
added to a Document.  Sure, you could throw a runtime exception if
adding a Document to an Element, but isn't it better to have a compile
time exception as we have now?

> * Supply every Item with a "serializedForm" constructor, i.e.
> Element elt=new Element("<locale language=\"English\" country=\"US\"/>");
> will create a new Element "locale" with the Attributes "language" and
> "country".
> Since the regular constructor already takes a String parameter, maybe it's
> better to make it a static constructing method.

If parsers had the ability to support this, it'd be an option.  They
don't though, and I presume it's because XML snippets aren't generally
parseable out of context.

> * Change addContent() to add().

Interesting.  Funny no one suggested this before.

> * Add two static methods to Attribute, to convert a Map of String:String
> to a List of Attributes and vice-versa. Can be handy.

I'd think that belongs outside the JDOM core.

> * Add a new "JDOMUtils" class that will include some convenience methods
> like the above.

Yep.  If anyone else thinks it useful, you might want to write something
for org.jdom.contrib.utils.


More information about the jdom-interest mailing list