commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morgan Delagrange" <>
Subject [Latka] XPath validator, BaseConditionalValidator class
Date Thu, 02 May 2002 23:00:05 GMT
Hi all,

I just added a class called BaseConditionalValidator.  A little while ago,
Jeff Turner suggested generalizing the true/false logic of our validator
tags.  The alternatives seemed to be creating a good base class for
conditional tags, or creating a wrapping tag "<not>" for all the tags.  I
decided to try the former solution for a couple of reasons:

  1) Less verbose
  2) Lots of tags don't need conditional support (e.g. why check to see if
     a server response does _not_ match a golden file?)

One of the challenges was that, in order to generalize this logic, we now
need to differentiate between failed conditions and bad tests.  For example,
a regular expression that does not match may or may not produce a failure,
but a poorly formed regular expression should always fail.  I think the new
subclass does a decent job along those lines.  The exception generation is a
little hokey, but it does the job.

I converted RegexpValidator, CookieValidator, ResponseHeaderValidator, and
XPathValidator (more on that in a moment) to the new base class.  I also
updated CookieHandler and ResponseHeaderHandler, so now all I have to do is
update the DTD, and you should be able to use the new conditional logic on
cookies and response headers.  None of the remaining Validators seemed to
suggest a need for conditional logic.

I think that XPathValidator in particular is easier to follow now, and I
think I got the sense of it right, although it's a tricky class.  Please
take a look and let me know if you approve of the new format.  I added an
XML file to the latka-webapp and a corresponding test file to the
distribution, so we should be able to perform decent functional tests on the
XPath tag now:

I am a little worried about the format of the xpath tag, though, now that
I've had the opportunity to use it.  If you look at the XML suite linked
above, there are two ways to test for values: as part of the XPath
expression, and as a separate attribute:

  <xpath select="doc/element/@attribute = 'foo'"/>
  <xpath select="string(doc/element/@attribute)" value="foo"/>

It seems confusing and a little redundant to do it that way.  Why not just
let XPath handle testing values, rather than doing it inside the tag?  It's
particularly confusing, I think, because tests that look similar actually
produce different results.  For example, if testing the
"TestMeWithXPath.xml" file:

    this would succeed, because there is a doc/element with an attribute
    of "bar"
  <xpath select="doc/element/@attribute = 'bar'">
    this would fail, because it's not the first element
  <xpath select="string(doc/element/@attribute)" value="bar">

Also, the latter approach is obviously awkward, because you always have to
use that string() function.  Finally, in many cases you ignore that value
entirely; you only obey it if Jaxen returns either a String, or something
other than a JDOM Element or a Boolean.

The cond="true|false" attribute seems fine; I don't see an easy way to do
something as effective inside the expression itself.

Oh yeah, FYI I had to change one of the import statements.  Jaxen appears to
have renamed a class from "org.jaxen.jdom.XPath" to

- Morgan

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message