[jdom-interest] getChildTextNormalize()

Kent C. Johnson kentyman23 at hotmail.com
Wed Oct 3 17:04:28 PDT 2001

>From: philip.nelson at omniresources.com
>To: jdom-interest at jdom.org
>Subject: RE: [jdom-interest] getChildTextNormalize()
>Date: Wed, 3 Oct 2001 16:26:02 -0500
> > > 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.

Understood.  I had no idea it was already discussed, and I agree it is not 
worth bringing back up.

>Pandora's box is truly opened!  The more fruitful part of this discussion 
>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. ;-)

I had you listed under number 5... :)

5) <insert your idea here>

>In english the goal is to provide easy access to the text in normal, 
>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, 
>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"))

Was getting a little confused here but let me see if I got you.  The helper 
will have getText(Element), getTextTrim(Element), and 
getTextNormalize(Element), and who you get it from will just depend on the 
element (whether it be source or source.getChild("boofar")).  If that's what 
you propose I agree that it's a valid change, though I would like to hear if 
there are any ideas I left out of the list (probably by now they are all out 
of the "Box" :) ).

>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 
>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.
>To control your jdom-interest membership:

Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

More information about the jdom-interest mailing list