Ethan Jewett wrote: Thanks for sharing your code. > 1) Is there an easier way to do this? > You created a method in a mixin and then added the mixin to the class. It would be simpler to just add the method directly to the class and forget about the mixin. > 2) If not, what with the growing popularity of javascript events > triggered by such things as list selection, button clicking, etc, > would it be a popular idea to start defining a framework for alternate > behaviors like "no_wait" of action methods like click, goto, select, > etc? > First, i have to say that your solution will not help the OP. The click_no_wait doesn't wait, but it also executes the click method in a separately spawned Ruby process. This is necessary because modal dialogs block the process that trigger them. So we create sacrificial process that we don't need care about (it could wait, for all we care, and originally did -- this was changed simply to avoid benign error messages that sometimes occurred.)
Speaking only with regards to Ajax support, i agree that we need a general solution for the problems you've run into, packaged with Watir. > One suggestion: All action methods take an optional hash as a > parameter, allowing for click(:no_wait => true) to have the same > behavior as click_no_wait. In Akash's case, he could use select(item, > :no_wait => true). I'd be happy to contribute some test cases if this > sounds like a decent approach. > Another suggestion: We use class_variables wrapped by class_methods to control whether a wait will occur automatically with certain methods. Thus: Button.wait_after_click = false # "global" setting affects all buttons ie.button(:index, 1).click # would not wait I suspect that you might even want to configure Watir so that no waits are automatic and you have to code them all explicitly... Bret _______________________________________________ Wtr-general mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-general
