[jdom-interest] getChildTextNormalize()

[Kent C. Johnson]

>Yup. Ditto on that from me; the idea of a helper class is to reduce the 
>core
>size. FWIW, I'm on the side of a helper class and less clutter in the core.
>That said, what little time I do have for JDOM, I probably won't be the one
>doing the work, so I can't be rock solid on my support (I don't like 
>signing
>other people up for work I want done ;-) ).

<warning>the following is quite long-winded</warning>

Sign me up. :)  What I'm saying is, the whole reason I joined these lists 
was to do *something* about getChildTextNormalize().  I really have only 
used JDOM a couple of times.  However, I didn't want to just add the method 
if so many people were against it, so I am trying to figure out what people 
can agree on.  If I ever hear a consensus, then I will happily implement it.

Which of the following proposals do y'all agree will, and actually want 
implemented.  Here is (basically) a complete list of the options I've heard:

1) Merely add the getChildTextNormalize() method to Element.  This (tiny 
amount of) work is already done and I have already submitted it.

    blahText = getChildTextNormalize("blah");

2) Remove (deprecate, whatever) all getChildText*() methods, leaving just 
getText(), getTextTrim(), and getTextNormalize() in the Element class.  If 
someone wants it from a child they can first use getChild(), make sure it's 
not null, and get it's text.  Or they can do what one is supposed to in Java 
when you think an exception (NullPointerException in this case) might be 
called, and put it in a try/catch statement.

    try {
        blahText = getChild("blah").getTextNormalize();
    } catch (NullPointerException npe) {
        blahText = "";
    }

   ...if a user wants a convenience method for the above they can basically 
just change "blahText =" to "return" and throw it in a method.

3) Keep getText() and getChildText(), and leave the normalizing to a helper 
method in a helper class, and leave trimming to String.trim().

    TextHelper.normalizeText(getChildText("blah"));

4) Same as (2) except without the try/catch: Make a static final version of 
a child Element (NULL_ELEMENT) that returns "" for it's getText*().  That 
way if one tried:

    getChild("blah").getTextNormalize();

   ...and the child did not exists, getChild("blah") would return this 
Element with no text, and getTextNormalize() would return "".  This would 
mean no fear of NullPointerExceptions.

5) <insert your idea here>

I hope that covers it all.  If not append your own idea.

My vote goes in for number 2.  I'm sure I'll end up changing my mind after 
hearing more discussion on it thought.  Here are my problems with all of 
them:

1) Very easy to implement, very convenient, but does add clutter.  And I 
completely agree with the argument of when do we stop and why don't we have 
getGrandChildTextNormalize().  The obvious implementation reason is that 
we'd have to recusively go down, rather than just check a list of elements, 
but I think implementation woes shouldn't change class design usually.  
Anyway, if nothing else this is a good start to add until we can agree on 
something else.

2) I think this is correct in design, but not as convenient as it could be.  
If end users are going to constantly be writing this same helper method for 
themselves, then it can be argued that we should write it.

3) This abstracts the normalizing from the Element class, but doesn't do 
anything about the problem of calling a child classes method (rather than 
letting the child do it).  It just doesn't seem like much is gain going this 
route.

4) First problem: seems like it's a magic trick... like it's rigged up.  Ok 
that ws the only problem, it just isn't intuitive.  No one would guess that 
behind the scenes we created this imaginary friend NULL_ELEMENT just for 
this case.

What are your comments?

Kent

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