What Charley is describing (wrapped elements with timed out waits ...) sounds basically like what I've currently built. But, I think after reading this thread, I'm going to remove that functionality and just go back to explicitly setting wait_until for DOM elements inside my page objects instead of having my code magically take care of it. I'm starting to think that it probably just reads better. More importantly, what I did want to say, is that as an end user of the WATIR API, I did find the suggestions for element#appears? / element#disappears? really interesting.
On Wed, Oct 20, 2010 at 1:14 PM, Charley Baker <[email protected]>wrote: > Exactly. I prefer having the test writer decide which DOM elements to > wait on. I did play around with wrapped (monkey patched) elements with > timed out waits for one of the apps I was testing due to network speed > and app issues, but eventually decided on explicitly calling out or > adding waits. > > > Charley Baker > Lead Developer, Watir, http://watir.com > > > > On Wed, Oct 20, 2010 at 10:40 AM, Jarmo <[email protected]> wrote: > > Okay, so you'd just do that wait_until in these procs and it's not > > done anywhere automatically? > > > > Jarmo > > > > On Wed, Oct 20, 2010 at 6:09 PM, Charley Baker <[email protected]> > wrote: > >> It basically breaks down into elements as they're defined taking a > >> proc: http://github.com/scudco/taza/wiki/Elements > >> > >> -c > > _______________________________________________ > > Wtr-development mailing list > > [email protected] > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/wtr-development >
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
