[
Lists Home |
Date Index |
Thread Index
]
Bill de hÓra <bill.dehora@propylon.com> writes:
> 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 ;)
I'm basing this more on what two Java XPath implementations have in
common than on what a user might conceivably find useful.
> > 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.
Expression.getMatchingNodes().item(0).toString is not the same as
Expression.getStringValue(), the latter, in XPath, gives you a
concatenation of all descendant text nodes.
> It's untyped and therefor risky, but the xpath is close by if
> there's a problem.
getBooleanValue() would follow XPath hopefully 1.0) rules of casting
things to booleans, not Java. Same for numbers.
> 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.
XPath recovers silently from cast errors.
> It'll be something that extends RuntimeException, in this case
> IllegalArgumentException. Checked exceptions wreck my buzz :)
Although I have a different opinion on checked exceptions, I'd point
out that DOMException is a RuntimeException -- all that JavaScript
heritage shows through.
Ari.
|
