[jdom-interest] getChildTextNormalize()

[philip.nelson at omniresources.com]

> > JDOM used to work this way, and after *quite* a bit of 
> discussion, we
> > changed it. There are many of APIs that return null to 
> indicate that the
> > item doesn't exist (that is the meaning of null, after 
> all). E.g. the Map
> > interface in Java collections. The discussion was in June 
> and July 2000
> > (wow, that was a long time ago...) if you want to take a look.

good points snipped....

> If there's a long history to this, I assume I will not move 
> any hearts or
> minds here. But I thought to give it a shot before this becomes set in
> stone as part of the standard Java APIs....

Nothing has changed to make the prior discussion about this invalid.  NPE
was chosen by a partial consensus of active developers and committers and
the vote went the NPE route.  I don't want to change it now and I don't
think the other committers do either.  All of the issues brought up this
time around were brought up then so it wasn't that we just didn't think
about these things.


Pandora's box is truly opened!  The more fruitful part of this discussion is
to discuss the best api between functionality in Element vs a helper class.
More accurately in my point of view, what methods to put in the helper
class.  In Kent Johnson's list of ideas, somehow mine was not included,
though I'm sure that was an oversite. ;-)

In english the goal is to provide easy access to the text in normal, trimmed
and normalized fashion for an element or a child one level down.  This must
be accomplished in such a way so the for the most common cases, a developer
can do it in two lines of code or less.  If the child does not exist, return
an empty string.  

Since returning null from getChildText would require more than two lines,
this is not an acceptable option.  Here is what I propose.

1 - remove all the getChild*Text* methods from element (I'd be ok with
leaving the current though, just not adding more)
2 - Add helper methods like these

public static String getText(Element source) {
    if (source == null)
        return "";
    return source.getText()
}



Now some of the other ideas had assumed that a help could/should have been
used like


String value = parent.getChildText()  

has problem with returning null

String value = Helper.getChildText(parent, childName);

OK but still refers to child which is not needed IMHO

child = parent.getChild("name");
String value = Helper.getText(child);

or just
String value = Helper.getText(source.getChild("name"))

Seems like it meets all the criteria.  This comments about OO-ness seem a
little superfulous.  The appropriateness of the getChild*Text* is suspect.
The use of utiltity methods seems perfectly acceptable.  Whether or not to
return null, empty string, or throw an Exception is an api choice but only
one is possible at a time.  the use of the helper utility accepts the notion
that there is more than one correct answer.  The encapsulation of this fact
is not part of the definition of what an Element is but instead use of its
text content.