commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@multitask.com.au
Subject RE: Latka Questions
Date Sat, 23 Mar 2002 05:45:03 GMT
"Waldhoff, Rodney" <rwaldhof@us.britannica.com> wrote on 23/03/2002 
01:46:36 AM:

> I don't think Latka's quite this smart yet, although you're not the only 
one
> who would like it to be.

In the immortal words of Shrek: "It's on my todo list!"

[snip]
> Latka can currently do this, but you need to tell it the names and 
values of
> each field in that form (i.e., you need to set <param>s in the <request>
> with predetermined names and values).  It seems reasonable, and perhaps 
not
> that difficult to make Latka support logic like "set the first <input
> type="text"> field in the form named 'addUser' to 'TestUserFoo" and 
submit
> it, which would allow us to populate forms without necessarily knowing 
what
> the field names are or what the form action/method is.  (Of course, it 
would
> make the testcase brittle with respect to reordering the fields in the
> form.)

The current unwritten plan is to allow parameters to be provided from form 
variables of previous requests (e.g. hidden fields, text etc), or as you 
say, from a 'variable/expression'.

> > D) Invoke ListUsersForEdit.do
> > E) Apply an xpath along these lines to locate the user I just added:
> >    //li[contains(.,"TestUserFoo")]/a
> > (that may not be perfectly correct but you get the idea)
> 
> Latka can currently do this as part of a validation, to confirm that
> 'TestUserFoo' is listed. 
> 
> > F) Use the getText() value of the 'a' element located to invoke 
> > DisplayUser.do?uid=whatever
> 
> AFAIK, Latka can't do that yet, but with variable support it could. 
(I.e.,
> set a variable to the value of that XPath, and then use that variable in 
a
> later request.)
> 
> Perhaps some of the more recently active committers can comment on this, 
or
> correct me where I'm wrong.

You're spot on.

> 
> - Rod

A short bit of recent history on Latka.

We never used to have much in the way of docs, so that was my first 
priority. We never used to have much in the way of validation, so I've 
helped in the build a bit there as well. We have 'undocumented' coding 
standards, which I'm attempting to a) document and b) verify using 
checkstyle.

So we're getting there gradually. I'd actually like to get a release 1.0 
out the door RSN.
--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
Developers: http://www.multitask.com.au/developers

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message