Apologies in advance for the long, dull novel.
> This is not exactly a bug - more a limitation of the design. At the
> moment, element locators are expected to return only a single element.
> This works nicely for most cases, but as you've found, it makes it
> trickier to deal with groups of radio-buttons or checkboxes.
Well... yes and no. At the moment, locating by name and xpath return single
elements no matter what, returning just the first item if the element is
grouped. However locating by dom returns exactly what was specified: in the
case of grouped elements it'll return a single element only if an implicit
selector (e.g. [1]) was part of the locator, and the whole group if not. So
from a user's standpoint (mine anyway, hah) it feels like inconsistent
behavior: I would intuitively expect "foo",
"document.forms[0].elements.foo", and "//[EMAIL PROTECTED]" to all return the
same thing. Now whether it should return the grouped element or just the
first item is a reasonable question.
Bear with me a sec, I just want to take a step back and look at this from a
design perspective. I realize that having a method return ambiguous data
types is a no-no in the world of most application/real languages. However
this is the browser dom, which plays by different rules. Since Selenium is a
tool for testing the UI, it seems reasonable to model its scripting
interface after the dom's, even if the natural behavior seems kludgy to
those used to a more disciplined structure ;) At least that's my take, being
a UI developer. I guess what I'm saying is I'm all about consistency and
doing what's intuitive, and what's intuitive to me is making it consistently
work like the dom. That's my vote, but I'll understand if I'm in the
minority :)
> (1) check <LOCATOR>
> (2) check <NAME> <SELECTOR>
>
> In (1) the argument is expected to be a normal locator, returning a
> single element. Only DOM or XPath locators would make sense, really.
>
> In (2), with a second SELECTOR argument, we can assume that the first
> argument is a NAME, not a locator (doesn't make sense otherwise). So
> we'd use something like PageBot.locateAllElementsByName(NAME) instead of
> findElement(NAME).
OK, design debates aside and following your logic here, what do you think
about this. I can do as you suggest and add a method on PageBot that'll
always return an element array (even if it is len 1), no prob. I'd probably
call it "findElementsByName" though, since the locate* methods seem to be
effectively private thus far and this is gonna need to be exposed to
Selenium's command methods. The doCheck method will only try to grab the
grouped element if a selector was specified, however; otherwise it'll just
use findElement like usual.
The rule would be that we infer the existence of a grouped element by the
presence of a selector, period. That means we can a) specify grouped
elements via dom and xpath refs as well as simple names, and b) still use
implicit selectors in the locator string, which is nice. However due to
differences in the way elements are currently located by dom vs. by
name/xpath (described above), it results in some slightly counter-intuitive
behavior by my definition (described below).
// by name
doCheck("radioArray", "index=1")
// checks radioArray[1]: OK
doCheck("radioArray", "")
// checks radioArray[0]: should throw error
// by dom
doCheck("document.forms[0].elements.radioArray", "index=1") //
checks radioArray[1]: OK
doCheck("document.forms[0].elements.radioArray", "")
// throws error: OK
doCheck("document.forms[0].elements.radioArray[1]", "") //
checks radioArray[1]: OK
doCheck("document.forms[0].elements.radioArray[0]", "index=1") // checks
radioArray[1]: should maybe throw error
// by xpath
doCheck("//[EMAIL PROTECTED]", "index=1")
// checks radioArray[1]: OK
doCheck("//[EMAIL PROTECTED]", "")
// checks radioArray[0]: should throw error
doCheck("//[EMAIL PROTECTED]'secondRadio']", "")
// checks radioArray[1]: OK
doCheck("//[EMAIL PROTECTED]'firstRadio']", "index=1")
// checks radioArray[1]: should maybe throw error
Sorry, I know that's a lot of introspection over a little detail... I have
no excuse. Let me know what you think.
Thanks,
Elaine
_______________________________________________
Selenium-devel mailing list
Selenium-devel@lists.public.thoughtworks.org
http://lists.public.thoughtworks.org/mailman/listinfo/selenium-devel
