[jdom-interest] More changes

[Jason Hunter]

> > There's the Ughhh.  :-)  What I really want is
> >
> > element.getChildContent(childName, "default");
> 
> OK - as nicely as possible ;-), this is the consequence of the null vs.
> Exception discussion - this sort of thing is the logical end-result. I
> agree that getChildContent() is fraught with confusion and
> double-meaning. Is the child returned the first child? SO if you want
> the second child you can't do this shortcut? Is the default returned
> when the value doesn't exist? when the child doesn't exist? When there's
> an error? Is the default an Element? or a value? Is that really
> accurate?
> 
> I think if this is really a problem, than what you are saying is that
> you want an Exception to be thrown. 

Whoa, that was fast.  You didn't comment on my code.  I'm not saying I
want an exception to be thrown.  I think the code shows pretty well that
the current approach isn't very conducive to the kind of access needed
to parse config files, nor is throwing an exception conducive either.

For a lot of uses, like web.xml, people use child elements to hold
values like some people use attributes.  Accessing those values is
currently overly difficult, as the code shows.

To answer your questions:
1) It acts only on the first child, just like getChild() does.  This is
no more confusing than methods already in the API.
2) Yes, you can't use this shortcut for the second child.  But since the
use case in places like web.xml is where elements are being used where
attributes might, it's not common for there to be two children.
3) When there's no content or no child, we should do the same as
getContent() when there's no content.  (Which currently is "" although
with the new null style it should probably be null.)
4) The return value is a String

I do agree we probably need a method renaming overhaul.  You're
absolutely right that because of the namings we've chosen we've backed
ourselves into a corner a bit here.  getChildContent() sound too much
like it returns child elements.  But that doesn't minimize the need for
something that gets a child's text "value" with a fallback if the child
doesn't exist.  Maybe the right terms are getValue() and
getChildValue()?

Maybe XPath would be sufficient to handle this; I haven't explored
enough there.  But in the near term I would really appreciate
functionality like this.  My code examples show that in my opinion.

Back to real work for the rest of the day...

-jh-