[jdom-interest] getText() and getAttributeValue()

[Trimmer, Todd]

[Alex Rosen]
> According to the XML spec, there is no difference between
> <element></element> and <element/>, but there is a difference between
> <element att=""/> and <element/>. That's why JDOM must 
> distinguish between
> these two values in getAttributeValue().


But when calling getAttributeValue() you are choosing to ignore this
difference. You just want the text, if present, and move on.

This is the 80% use case. The 20% use case that DOES CARE <element att="" />
differs from <element/> shouldn't be granted the convenience of
getAttributeValue(). They should be forced to use getAttribute() to check
for that difference.

If I want to safety check...

	element.getAttribute("foo").getValue();

I would write:

   Attribute attr = element.getAttribute("foo");
   String value = "";

   if (attr != null)
      value = attr.getValue();

But if I want to safety check...

   element.getAttributeValue("foo");

I would write:

   String value = element.getAttributeValue("foo");

   if (value == null)
     value = "";

Gee. Not a lot of savings here beyond the four characters I save in writing
getAttributeValue("foo") vs. getAttribute("foo").getValue(). Suddenly, this
*convenience* method doesn't seem very convenient, does it? It doesn't save
me any work at all.


[Philip Nelson]
> And those of us that think null is the appropriate response feel that
> returning "" on a non exsistent attribute is masking knowledge of what the
> xml actually contains.  You can make excellent application specific
> arguments about this issue, but not at the level JDOM sits.


Again, I *WANT* to be shielded from the difference betweeen <element att="">
and <element/> when calling getAttributeValue(). This is what W3C DOM's
getAttribute() does. And since JDOM is using the 80/20 guideline,
application use IS appropriate when making design considerations at this
level.

getAttributeValue() should not double its functionality by both getting an
attribute value AND detecting the existence/non-existence of an attribute.
That's why it shouldn't return null when empty string and empty string alone
completely satisfies the first mentioned function.


[Jason Hunter]
> I think Phil said it best.  At the relatively low-level of JDOM, more
> information is better.


Sure thing. The 20% use case that wants the extra information can use
getAttribute().


[Jason Hunter]
> As a second argument, we need

> Attribute Element.getAttribute(String)

> to return null if the attribute doesn't exist.  We're not going to
> return a NO_ATTRIBUTE constant or anything fancy.  So for consistency,
> we should have getAttributeValue(String) return null also.  The "value"
> method is a convenience on top of the former.


If getAttributeValue() merely wraps around getAttribute(), with both being
able to return null, then getAttributeValue() provides NO CONVENIENCE AT ALL
(or relatively none), as you can see in my examples above.

getContent() or getChildren() always return a list. Even if there is no
content or no children we still get an empty list. Why not null? Because the
List interface already has an analogue of the empty set, the empty list, and
can return an object represting it. The String class does too -- the empty
string. No, Attribute or Element do not have these constructions, nor do I
propose we create them. This is why I'm not arguing against returning null
for getAttribute() or getChild() (I would prefer exceptions, but that has
already been voted on, so I won't push it). I am arguing that since List
already has an "empty" instantiation, and JDOM uses it, then why doesn't
JDOM use the empty instantiation of String, the empty string, in methods
that return String?

To sum up:
1) getAttributeValue() returning empty string falls on the 80% side
2) The 20% side should use getAttribute() to get information on such a
nuance
3) Having getAttributeValue() return null forces it to such a trivial
advancement beyond getAttribute("foo").getValue(), that it is reduced to
fluff.


Todd Trimmer

p.s. -- I like the element.getAttributeValue(name, defaultValue) idea, too.