[jdom-interest] Attribute.getBooleanValue()

[Rosen, Alex]

> > The logic is that Element is "busy enough" as is.  If you want
> > conversion you can get the attribute as an Attribute and then have
> > access to additional methods.  Element retains just one convenience
> > method.
>
> Now that Alex is looking to putting this sort of functionality in a helper
> class, would it make sense to remove it from Attribute as well?  I don't
> remember the signatures well enough to know if this was what Alex is
> thinking but it seems to be a possibility.

I would completely agree with this, except that I'm tempted to punt on the data
conversion helpers. The problem is that there are so many axes of data access,
that you get an exponentially-increasing number of methods. So far, I've got:

- 5 ways to get plain text: getText(), getChildText(String),
getChildText(String, Namespace), getAttributeValue(String),
getAttributeValue(String, Namespace)

- Requiredness: return null vs. throws an exception (e.g.
getRequiredAttributeValue())

- Data types: I propose we limit it to int, boolean, long, double, and punt on
byte, short, float, BigDecimal, etc.

That makes 5 times 2 methods per datatype, times 4 datatypes, so that's 40
methods just for data conversion. God help us if we come up with another
axis...

What do you think?

> Move it from the core into a non-core component?  I would think
> attribute data conversion merits a place in the core.

I'm not sure I understand why attribute data conversion is more useful than
content data conversion. It seems that whatever we do with one, we should do
with the other. One is for Ant-style XML:

<car color="red" wheels="4" />

and the other for J2EE-style XML:

<car>
  <color>red</color>
  <wheels>4</wheels>
</car>

Alex Rosen
SilverStream Software