[jdom-interest] getChildTextNormalize()

[bob mcwhirter]

> > I have to disagree here.  That approach would imply the helper classes
> > would be part of the core, and that means the core API would get the
> > additional methods anyway -- same API size increase with the downside
> > they wouldn't be in the place one would expect them or look for them, or
> > in the place OOP would naturally place them.
> 
> 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 ;-) ).

Just a note, while we think about removing methods from objects, and
putting them into helper classes...

The whole point of OO programming is to make the relevant operations
available on the object you're mucking about with.

Once we start adding extra orders-of-removedness, with getChild*() types
of methods, it may become a slippery slope.  

Why not have getGrandChildTextTrim(String childName, String grandChildName)?

So, I vote on having basically just methods that affect the object directly.
I'd vote for removing most getChildText*() methods altogether.  (Then again,
I don't typically use even getChild(...) due to the miracle of XPath, and
my typical XML usage patterns).

But, if we move things to helper classes, I'd like to make sure we don't
move too much out of the object's method space.  If we have getText(),
then I think getTextTrim() and getNormalizedText() are all valid, since
they still operate on the object's properties.

Though, the normalization algorithm, I think, could be in a helper
class, which internally is called from Element.getNormalizedText().

Oh, I dunno.  Just ramblings.

	-bob