[Webtest] StoreXPath for non-node evaluation

Dierk Koenig webtest@lists.canoo.com
Mon, 11 Aug 2003 19:32:33 +0200


Hi Christopher,

thanx for the reminder.

We applied the same to VerifyXpath but forgot to do it for StoreXpath.
It is now integrated since build 346.

cheers
Mittie

P.S. Your CVS access is under way...

> -----Original Message-----
> From: webtest-admin@lists.canoo.com
> [mailto:webtest-admin@lists.canoo.com]On Behalf Of Christopher
> Painter-Wakefield
> Sent: Montag, 11. August 2003 16:53
> To: webtest@gate.canoo.com
> Subject: [Webtest] StoreXPath for non-node evaluation
>
>
>
>
>
>
>
> I'm sure this has been posted before, but let me try again.  We need a
> patch to StoreXPath to allow us to store the results of XPath functions
> such as substring-after().  The current code assumes the XPath expression
> evaluates to a Node:
>
>       protected String getXPath(Document document)
>       {
>             Node node = document.selectSingleNode(getXpath());
>             if (node == null)
>             {
>                   throw new StepFailedException("No match for xpath
> expression <" + getXpath() + ">", this);
>             }
>             return node.getStringValue();
>       }
>
> Since the node is reduced to a String when returned, I'm not sure of the
> logic behind this.  This approach breaks when you use a function
> expression, such as "substring-after(...)", which evaluates to a
> String and
> not to a Node.  (The exception is wrong, in this case.)  A better way
> (IMHO) is to rewrite the function this way:
>
>       protected String getXPath(Document document)
>       {
>             return document.valueOf(getXpath());
>       }
>
> I'm not sure what happens when you call this on an XPath expression which
> doesn't evaluate to anything (I'll be testing this shortly, using a custom
> step).  It might throw an exception, which can easily be caught and
> reworked into the StepFailedException as in the current code.  On
> the other
> hand, it might just evaluate to an empty string, which is just fine with
> me.  The storexpath step shouldn't be used to verify the existence of a
> node, that is the job of the verifyxpath.
>
> If the current developers don't have time to implement this change, but
> agree with it, maybe you can give me contributor access to your CVS tree?
> We are actively using webtest, and extending it (the verifyxpath code was
> originally written by a consultant for our project).
>
> Thanks,
> Christopher
>
>
> _______________________________________________
> WebTest mailing list
> WebTest@lists.canoo.com
> http://lists.canoo.com/mailman/listinfo/webtest
>