On Mon, Nov 2, 2009 at 23:43, Bret Pettichord <[email protected]> wrote:
> > On Mon, Nov 2, 2009 at 10:01 AM, Ethan <[email protected]> wrote: > >> Container#element and #elements is supported in my branch. >> > > Right, there is a lot of stuff in your branch. Would it be possible for you > to pull it out into feature branches to facilitate review? > I'm not certain. most of what I have currently is rather tightly-knit, and separating things out, I don't know if there would be a good way for me to go about that. I will ponder on it, but I think it would take time that I need to be spending working on features that my company needs with how we use watir. > Zero-based indexing, sounds good. I assume this would apply to subscripting >> element collections, (ie, container.divs[0] instead of container.divs[1]); >> would it also apply to container.div(:index, 0) rather than >> container.div(:index, 1)? >> > > http://jira.openqa.org/browse/WTR-61 > Sounds like 0-based everywhere. sounds good to me. > BTW, one of the things that I've noticed is that many of the discussions > about jira tickets never get recorded there and therefore get repeated a > lot. I'm wondering if in the end this is really a problem with Jira. I > noticed that in my recent use of Lighthouse, this didn't happen nearly as > much. I think that tool made it easier to forward emails to the ticket and > also encouraged people to post questions, etc in the ticket itself, partly > because people could be set up as watching the ticket and thus get emails > when ever someone added a comment. > > display_value, what's this? can you link to documentation or source? I'm >> not seeing this with a quick search. >> > > Good question. Here is what I'm talking about. > http://github.com/bret/watircraft/blob/master/lib/extensions/watir.rb > ah, interesting. with the ===, this would end up with true === #<Watir::Checkbox checked=true> which seems potentially a bit broad for a checkbox to be matching. where would this be useful? It is an interesting idea, I'm not sure I see the full use of it though. case element when true puts "the element seems to be true, whatever it is" when false puts "element is false" when /foo/ puts "element contains text foo" end What would change with table and radio? >> > > My email is really a followup to a number of ideas that I posted in this > thread. > http://rubyforge.org/pipermail/wtr-development/2009-October/001195.html > I recall that discussion, reading back through it, but I'm not seeing what in particular you have in mind to change. With tables, I think maybe you mean that it counts nested tables in row_count, for one thing, and doesn't really consistently deal with whether it's using rows from itself or from nested tables (this is also fixed in my branch). If not that, I'm not sure what you mean. For radios, I still don't know what should be different - I see you mention it in that discussion, but not what in particular is wrong. -Ethan
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
