[jdom-interest] More changes

[Brett McLaughlin]

Jason Hunter wrote:
> 
> > > 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

I read through it, and summed up what I thought was the crux of the
situation. Sorry ;-)

> 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.

I'm not sure I agree - it is the first method that combines obtaining
content with determining the existence of an Element. There is no way to
tell if an Element doesn't exist and you got defaults, or if the content
was wrong, and you got defaults, or there was an Element with no content
(only other Elements) and you got defaults.

This is the very thing we are trying to fix right now with getXXXContent
and getXXXValue

> 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.

But that is /always/ the use-case in XML - you can show almost any XML
document with attributes or elements. I'm just not convinced that this
is such a compelling use case. You are saying right off (by using
getChildContent(String name)) that you have an expected format for the
document. Because of that foreknowledge, I can't see this being any
advantage (albeit making slightly longer code) in functionality, and I
do think it falls in the category of API bloat.

> 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.)

It should be.

> 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()?

I still disagree that you should be able to do this sort of
pseudo-walking.

> 
> 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.

Ahhh ... now the real deal. XPath is absolutely the right solution. And
you taught me not to introduce a method you know you're going to
deprecate ;-)

I'm -1 on getChildContent(), but I am ok with adding a method like it in
the ElementLocator class, or some other utility class, that would serve
these needs until 1.1. I just don't want this in the core API.

_Brett

> 
> Back to real work for the rest of the day...
> 
> -jh-

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org