[jdom-interest] Helper methods [eg]

[Elliotte Rusty Harold]

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()? 
setKitchenSinkText()?

>- 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/     |
+----------------------------------+---------------------------------+