On Fri, May 7, 2010 at 11:42, Jarmo <[email protected]> wrote: > 1) Default locator for all elements should be :index => 0 >
Concur. I too am annoyed by having to type a bunch when I just want the first element of the specified type. Same for IE.attach; if no :title or :url specifier is given, it should just attach to the first IE it finds. And with the possibility (from Google Wave about Watir 2.0 by Jari) to > use locators for collections: > product = b.table(:id => "table_id").trs(:text => "Something else").first > product.link.click > Definitely. This is a priority for me in my fork. > 2) Selenium has a lot of different ways of locating elements. This is > not what i would like to see in > Watir and as i understand then most of you in here also think like > that. But i think that it would > be great if ALL elements would accept one String as an identifier, > which would be used to locate an > element first by id and then by name. No exceptions - it would be the > same for every element. > I'd limit this to just id. conflating it with name introduces significant ambiguity, since the name of one element can be the same as the id of another. Do we go with the first id that's found, or the first name, or the first of either sort? The last seems most consistent with how watir operates / returns things, but incurs a significant performance hit because you can't use getElementById or getElementByName, because you won't know which element comes first. 3) Allow only hash syntax for element locators (+ String in proposal > #2). So, text_field(:id, 'sfdsa') is not allowed anymore. Why? > Well, it's again to have less syntax for finding elements and you can > use only hash when using multiple identifiers anyway. > Especially newcomers might get confused if at one place they read > text_field(:id => 'sfdsa') and other place comma > is used. > Sounds good to me. Not mentioned here, but in the same vein, the third argument (value) passed to radio/checkbox should definitely be dropped.
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
