>On Fri, Sep 10, 2010 at 5:21 PM, Ethan <[email protected]> wrote:
> First (idealistic reason), a hash shouldn't behave the same way as giving
> two arguments. A hash, as a data structure/way of thinking about data,
> represents many items - it made sense to add to watir's api in order to
> specify multiple attributes. It doesn't make sense if you can use it to
> specify only one value (as in :xpath) and get an error using a hash with
> multiple keys.
I'm not convinced - even though what you're proposing is consistent, I
still think it adds unnecessary complexity, API-wise. Not going to try
and stop you from doing this in Vapir, of course :)
> Second (practical reason), while it is fine to treat :xpath as a special
> case because it's not an attribute, it doesn't work with :label, because
> :label is a valid attribute of some element types (two that I see, <option>
> and <optgroup>).
Actually, it's a valid attribute on all elements - it's defined on HTMLElement.
> if you do container.option(:label => 'foo') then will it
> look for a <label> with text 'foo' pointing at an <option>, or an <option>
> with a label attribute with a value of 'foo'? It's not the best distinction,
> but at least with my way you can unambiguously define that, since using hash
> means attributes, when :label is used in a hash it is an attribute; with two
> arguments, :label is a special specifier meaning to look for a <label>
> element.
I don't think this is a good argument for the hash-means-attributes
proposal, but I do agree with the main point, that :label is
problematic. One solution would be to have :label always match the
attribute, and then add Label#target or similar (e.g. Label#control as
in DOM, or maybe Label#referenced_element). Perhaps we can agree to
implement one of those? :)
> As far as I know no element has a 'index' attribute, but I don't like mixing
> it into the attributes hash either.
The option element has an index attribute. That's actually an argument
for removing :index from both hash and how-what locators. But I still
think it's fine to leave :index and let users use XPath for the
uncommon cases.
> :value very certainly is an attribute on the dom, and is in the html spec.
> I didn't say for every type of element; it is only a recognized attribute in
> vapir for input elements.
Right - so both celerity and watir-webdriver allows this:
browser.button(:value => "foo").html #=> <button>foo</button>
browser.button(:value => "bar").html #=> <input type=button value=bar>
I'm pretty sure we picked that up from Watir.
> :text doesn't map to value for <input type=text>. that doesn't make any sense
> to
> me, why would it do that? watir doesn't do this either. nor should it, that is
> just confusing. anyway, that's even further off-topic.
Ah, you're right about Watir not doing this. Both celerity and
watir-webdriver does. Similarily, calling value() on a <textarea> will
return its inner text.
The reason I guess is the wish to have the following be true, even if
the element changes from <input type=text> to <textarea> or vice
versa:
browser.text_field(:text => "bar").text #=> "bar"
browser.text_field(:value => "bar").value #=> "bar"
Basically it's just a side effect of text_field() finding two element
types, similar to the case above for button().
_______________________________________________
Wtr-development mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wtr-development
