[jdom-interest] Helper methods [eg]

Elliotte Rusty Harold elharo at metalab.unc.edu
Thu Apr 19 06:04:09 PDT 2001

At 9:28 PM -0400 4/18/01, Rosen, Alex wrote:
>I would like to bring up the topic of adding helper methods to JDOM, so
>mulitiple users don't have to write common routines themselves. I envision
>these as static methods on one or more classes in a packaged named
>org.jdom.helpers or org.jdom.util. Some possible examples include:

I REALLY don't like this idea. As somebody who spends a lot of time 
documenting APIs, I tend to think that helper methods just muddy the 
water and confuse things, especially when they're in the same 
packages as the core. In general. I think that APIs should be as 
simple as reasonably possible. Helper methods should be added only 
when they're something that 90% of use cases are going to need and/or 
they save a lot of work when they are used. I don't think these meet 
either criterion. If you really want these, they're easy enough to 
add in a subclass in jdom-contrib without cluttering the core API.

>- Getters which would throw exceptions if the requested data is not available:
>getRequiredAttribute(), getRequiredChild()...

We already had this argument. Exceptions lost. I certainly don't want 
to provide one set of methods that returns null and another that 
throws the exceptions. That way lies confusion.

>- Getters and setters for datatypes, e.g. getIntAttributeValue(),
>setIntAttributeValue(), getIntText(), setIntText(), getIntChildText()...

Unnecessary clutter. And where does it stop? setFloatText()? 
setDoubleText()? setBigDecimalText()? setInputStreamText()? 

>- Modification methods which preserve formatting - an addChild() method which
>would add necessary indentation so the XML continued to look nice, and
>removeChild() which removed the remaining whitespace so there wasn't a big
>empty hole in the document.

No, trying to pretty print XML at this stage is actually modifying 
the logical structure of the document and is not infoset compatible. 
This option can be left for an outputter.

>- findChild(), which could find the child element with a specific attribute
>value, for example.

XSLT/XPath on 1.1 is how this will be done.

| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |

More information about the jdom-interest mailing list