David Kemp wrote:
I like the idea of extending the locator.
Great.
Should you be able to capture the state of a single check box with:
| storeChecked | options cheese | myVariable |
Can you then use that variable later to set the checked status of
another check box:
| check | options onions | ${myVariable} |
Interesting. It would be good to automatically generate "store"
commands based on "isXyz" methods on the selenium API, wouldn't it? I
like the idea of "check" taking an (optional) boolean flag.
With the <select> element, I have found it useful to be able to select
an option by it's index, id, value, or text content. It would not
surprise me if some of these might also be useful for check boxes (and
radio buttons maybe???)
e.g. To check the first checkbox in the list, simply use:
| check | options index=1 |
To store whether or not the fist check box is checked, use:
| storeChecked | options index=1 | myVariable |
Absolutely; you read my mind. I think it make sense for "value=" to be
the default, don't you?
Like I said, I was thinking of generalising the "option locators" and
turn them into "element selectors". Rather than knowing select-specific
stuff, e.g.
optionLocator.findOption(selectElement)
optionLocator.assertSelected(selectElement)
they'd just act as simple predicates
elementSelector.matches(element)
Of course, "select" and friends would probably have to change a little
if we want to use them there.
--
cheers, MikeW http://www.dogbiscuit.org/mdub/
_______________________________________________
Selenium-devel mailing list
Selenium-devel@lists.public.thoughtworks.org
http://lists.public.thoughtworks.org/mailman/listinfo/selenium-devel
