[
Lists Home |
Date Index |
Thread Index
]
K. Ari Krupnikov wrote:
> I think an interface with only a single method is of limited value,
> given the range of XPath uses.
That's what I thought. I've sitting on this for a few months,
thinking it was too trivial. But then I thought if that's all you
need, so be it, no point increasing the surface area for the sake of
it. I'm also curious to find out if that's all anyone else needs ;)
> One thing I'd consider is a convenience method getSingleNode with the
> same arguments - to eliminate the unnecessary cast (I realize things
> will change in 2.0, but I hear some folks are sticking with 1.0). I
> wasn't sure which List you refer to from the import statements; I
> wouldn't use java.util.List because of the casting - consider the
> better-typed NodeList.
[Actually the thing I have in cvs returns a NodeList and I changed
the signature it for distribution here, don't know why I did that...
:\ ]
> I would also consider getBooleanValue() and getStringValue().
What I do now is cast base on the xpath I'm putting in, ie if I put
in a path with text() I can make some assumptions about what's
coming back. It's untyped and therefor risky, but the xpath is close
by if there's a problem. I'd rather take the risk most of the time.
The downside of convenience methods as I see it is that you're
making calls applicable only for an xpath subset, that means you
have to have extra error handling goo to deal with time someone puts
in a path not that doesn't, but can't evaluate to the type. But if
it was limited to boolean, integer and float... maybe.
> Also to
> consider - what kind of exception will this class throw, for malformed
> XPath strings, for instance. Will it be a subclass of DOMException?
> Use a non-standard error code? many DOM application only declare
> DOMException in their methods.
It'll be something that extends RuntimeException, in this case
IllegalArgumentException. Checked exceptions wreck my buzz :)
Bill de hÓra
|
