[Latka] XPath validator, BaseConditionalValidator class

[Morgan Delagrange <md...@yahoo.com>]

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:


http://cvs.apache.org/viewcvs/jakarta-commons/latka/src/webapps/latka-webapp
/webapp/self-test/xpath/TestMeWithXPath.xml


http://cvs.apache.org/viewcvs/jakarta-commons/latka/src/distribution/tests/l
atka-self-test/TestLatkaOptional.xml

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
"org.jaxen.jdom.JDOMXPath".

- Morgan


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Latka] XPath validator, BaseConditionalValidator class

[Jeff Turner <je...@socialchange.net.au>]

On Thu, May 02, 2002 at 08:23:04PM -0400, bob mcwhirter wrote:
>> 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
>> "org.jaxen.jdom.JDOMXPath".

Ah yes, and that's breaking the build, because Maven is pulling in
jdom-b7.jar. Dion, do you know how to go about getting a jdom-b8.jar
uploaded?

--Jeff

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Latka] XPath validator, BaseConditionalValidator class

[Morgan Delagrange <md...@yahoo.com>]

Ha, just goes to show you, you never know who's
listening.  :)  Thanks Bob.

- Morgan

--- bob mcwhirter <bo...@werken.com> wrote:
> > 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
> > "org.jaxen.jdom.JDOMXPath".
> 
> Sorry 'bout that.  After much discussion on
> [jaxen-interest], we decided
> that it's best not to have 5 classes named
> "XPath"... ;)
> 
> Since we hit 1.0-FCS, we'll hopefully be less of a
> moving target.
> 
> 	-bob
> 


=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Latka] XPath validator, BaseConditionalValidator class

[bob mcwhirter <bo...@werken.com>]

> 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
> "org.jaxen.jdom.JDOMXPath".

Sorry 'bout that.  After much discussion on [jaxen-interest], we decided
that it's best not to have 5 classes named "XPath"... ;)

Since we hit 1.0-FCS, we'll hopefully be less of a moving target.

	-bob


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>