> im_doing_it_wrong="id">, in which case it should successfully find that. >> > > FireWatir works as you suggest and I don't like it. I really like my > testing tools to fail loudly and this approach causes it to fail quietly, > and makes it hard to debug my tests. > > I do like the idea of making it easier to use other attributes, though. > Okay. I can change this to raise MissingWayOfFindingObjectException when given something that's not valid for the particular element is given. I was thinking that this was going to be annoying, having a list to maintain of valid attributes to search for, but realized that those attributes are already defined on each class for exposing dom methods into ruby; can just reuse what's defined for those. > > By not repeated, I just mean that there's no def inspect or def to_s on >> each class. By modified, I mean, for example: >> * >> * >> >> module InputElement >> inspect_these :name, :value, :type >> end >> >> > i like this. > > The inspect_these method adds those attributes to a list of what gets >> inspected for InputElement (and things that inherit from InputElement). >> I also added a function that combined this with dom_wrap so that it can be >> put more concisely what attributes should both be inspected, have methods >> that point to their dom attributes, so that became: >> >> module InputElement >> dom_wrap_inspect :name, :value, :type >> end >> >> >> But I'm not sure, that may be a bit much and may negatively affect >> readability. >> > > Yes. We used the more verbose approach because it allowed the Rdoc to pick > up our methods. > okay, I'll separate back out inspect stuff. > > I considered putting them in their own namespaces but I decided that >> would be too confusing. Say you have >> >> - Watir::TextField for common >> - Watir::IE::TextField >> - Watir::Firefox::TextField >> >> I think it would get confusing when you are in, say, the Watir::Firefox >> namespace, whether an unprefixed TextField is meant to refer to the common >> one or the firefox one. Maybe >> >> - Watir::Common::TextField >> - Watir::IE::TextField >> - Watir::Firefox::Textfield >> >> I like this. > > BTW, this is a big change and really needs to be discussed in the context > of how we want to structure Watir 2.0. > > >> so that in any namespace you have to prefix the other's namespace. But >> that would break everything that checks stuff like >> foo.is_a?(Watir::TextField) - I named the common one after the existing IE >> one so that that would still work. (it still breaks backwards compatibility >> if code uses foo.class==Watir::TextField, but is_a? is generally >> recommended, so I figured this would be acceptable.) >> >> Another possibility is >> >> - Watir::TextField for common >> - IEWatir::TextField >> - FireWatir::TextField >> >> But I figured having separate browser-specific class names in one >> namespace was preferable to having identical class names in browser-specific >> namespaces. >> > > I don't know which one of those I prefer, they all have their pros and cons. I am inclined toward one of the first two, as breaking existing foo.is_a?(Watir::TextField) seems like a bigger negative than having different names (FFTextField and TextField) or ambiguity in some namespace. ? Watir::TextField ? Watir::IETextField ? Watir::FFTextField all in the same top namespace, no ambiguity referring to TextField, but prefixes mean class-specific ones aren't consistently named TextField. ? Watir::TextField ? Watir::IE::TextField ? Watir::Firefox::TextField all in the same top namespace, all consistently named TextField, but ambiguous in browser namespace. ? Watir::Common::TextField ? Watir::IE::TextField ? Watir::Firefox::Textfield all in the same top namespace, consistent names, no ambiguity, but breaks existing code checking for Watir::TextField. Bret Pettichord says: I like this. ? Watir::TextField for common ? IEWatir::TextField ? FireWatir::TextField different top-level namespace, so no ambiguity, all consistently named TextField. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Tue Oct 13 18:14:26 2009 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 14 Oct 2009 00:14:26 +0200 Subject: [Wtr-development] Release 1.6.5rc2? In-Reply-To: References: Message-ID: On Tue, Oct 13, 2009 at 7:29 PM, Charley Baker wrote: > Unless anyone has any objections, I'm going to tag and release 1.6.5.rc2 either end of day today or first thing tomorrow and send a mail to watir-general. +1 ?eljko -- http://watirpodcast.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Tue Oct 13 18:37:06 2009 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 14 Oct 2009 00:37:06 +0200 Subject: [Wtr-development] AWTA 2010 In-Reply-To: References: Message-ID: On Mon, Oct 12, 2009 at 4:45 PM, Bret Pettichord wrote: > I'm thinking about hosting AWTA 2010 in January or February and focusing on Watir 2.0. I'm curious to know what interest their may be in this? I would really like to participate. I plan to sleep less next year (literally) and do some coding on Watir, and AWTA 2010 focusing on Watir 2.0 sounds like a great place to learn how to do it. ?eljko -- http://watirpodcast.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.koops at gmail.com Wed Oct 14 00:46:58 2009 From: tim.koops at gmail.com (Tim Koopmans) Date: Wed, 14 Oct 2009 15:46:58 +1100 Subject: [Wtr-development] A question of timing Message-ID: <93ee69e90910132146p59f10806tc2085f6e56e2b4e3@mail.gmail.com> Hi guys, I've been using watir recently in load tests, to drive single user transactions from a browser whilst the backend servers are under load. We're particularly interested in things like client render time which is otherwise hard to measure. Not really affected by server load but of interest to the client ... The naive way of measuring 'browser time' is to wrap timers around the transaction of interest. e.g. start_time = Time.now browser.button(:text, "Search").click end_time = Time.now elapsed_time = end_time - start_time ... However when observing this replay in the browser there seems to be some latency both before and after the click event which is included in my elapsed time. Observing differences between fiddler session times (network + server) and watir times (browser) range in the order of 2 - 4 seconds. I know some can be attributed to client rendering but I would like to get rid of any wasted time caused by watir itself. I think I've isolated the wasted time before the event in element.rb where assert_enabled and highlight methods contribute to start time latency. To overcome this I put this at the top of my test module Watir class Element def click! assert_enabled highlight(:st) @@start_time - Time.now ole_object.click highlight(:clear) end end end I'm tempted to put an @@end_time after the call to ole_object.click to see if I can recover some wasted time after the click event but I don't really understand the logic behind Brett's comment on the wiki: "Watir is deterministic. Watir does not wait X seconds. It waits until the page is loaded. Period." i.e. what really determines the page is loaded (and can I put my end_time statement there)? Is this the best way to achieve my goal? That is to accurately record the response time as observed by the client (browser) following a click event on a button or a link... Regards, Tim Koopmans From angrez at gmail.com Wed Oct 14 01:59:41 2009 From: angrez at gmail.com (Angrez Singh) Date: Wed, 14 Oct 2009 11:29:41 +0530 Subject: [Wtr-development] Release 1.6.5rc2? In-Reply-To: References: Message-ID: I have a couple of new things added to Firewatir (got few hours free this week :)): 1. close_all_browsers method was missing 2. click_no_wait method added for handling javascript pop ups 3. added new method for entering username, password in authentication pop up. Let me know where it should go. Thanks, Angrez On Wed, Oct 14, 2009 at 3:44 AM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Tue, Oct 13, 2009 at 7:29 PM, Charley Baker > wrote: > > Unless anyone has any objections, I'm going to tag and release 1.6.5.rc2 > either end of day today or first thing tomorrow and send a mail to > watir-general. > > +1 > > ?eljko > -- > http://watirpodcast.com/ > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Wed Oct 14 10:30:33 2009 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 14 Oct 2009 09:30:33 -0500 Subject: [Wtr-development] Release 1.6.5rc2? In-Reply-To: References: Message-ID: Could you push these changes to your own fork so we can review the code and comment on it? Bret On Wed, Oct 14, 2009 at 12:59 AM, Angrez Singh wrote: > I have a couple of new things added to Firewatir (got few hours free this > week :)): > 1. close_all_browsers method was missing > 2. click_no_wait method added for handling javascript pop ups > 3. added new method for entering username, password in authentication pop > up. > > Let me know where it should go. > > Thanks, > Angrez > > On Wed, Oct 14, 2009 at 3:44 AM, ?eljko Filipin < > zeljko.filipin at wa-research.ch> wrote: > >> On Tue, Oct 13, 2009 at 7:29 PM, Charley Baker >> wrote: >> > Unless anyone has any objections, I'm going to tag and release 1.6.5.rc2 >> either end of day today or first thing tomorrow and send a mail to >> watir-general. >> >> +1 >> >> ?eljko >> -- >> http://watirpodcast.com/ >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Wed Oct 14 10:54:05 2009 From: notethan at gmail.com (Ethan) Date: Wed, 14 Oct 2009 10:54:05 -0400 Subject: [Wtr-development] A question of timing In-Reply-To: <93ee69e90910132146p59f10806tc2085f6e56e2b4e3@mail.gmail.com> References: <93ee69e90910132146p59f10806tc2085f6e56e2b4e3@mail.gmail.com> Message-ID: Tim, In the code you pasted, the 'click' method of the WIN32OLE is called without waiting for any result. This should return as soon as any javascript events associated with the onclick event return (if there are none, then it should return immediately). If you're waiting for new page to load as a result of that click, you want to see the the Watir::IE#wait method, in ie-class.rb. It blocks until any new page is fully loaded. What determines that the page is loaded is the page itself saying that it is loaded, via WIN32OLE. There are a number of criteria for this, all of which must be met: The browser's WIN32OLE object's 'busy' attribute being false; The browser WIN32OLE's 'readyState' attribute being equal to READYSTATE_COMPLETE; The browser WIN32OLE's 'document' attribute existing; It then checks the following attributes of each document - the browser window has a document, and each frame has a document; frames are checked recursively: The document WIN32OLE's 'readyState' attribute is equal to 'complete'. Again, you can see all of the relevant code for yourself for that, in Watir::IE#wait method, in ie-class.rb. It is true that you should start your timer after calls to assert_enabled and highlight; they both call to assert_exists which is possibly slightly slow - although certainly not on the order of 2-4 seconds. Hope that helps. Ethan On Wed, Oct 14, 2009 at 00:46, Tim Koopmans wrote: > Hi guys, > > I've been using watir recently in load tests, to drive single user > transactions from a browser whilst the backend servers are under load. > We're particularly interested in things like client render time which > is otherwise hard to measure. Not really affected by server load but > of interest to the client ... > > The naive way of measuring 'browser time' is to wrap timers around the > transaction of interest. > > e.g. > start_time = Time.now > browser.button(:text, "Search").click > end_time = Time.now > > elapsed_time = end_time - start_time > ... > > However when observing this replay in the browser there seems to be > some latency both before and after the click event which is included > in my elapsed time. Observing differences between fiddler session > times (network + server) and watir times (browser) range in the order > of 2 - 4 seconds. I know some can be attributed to client rendering > but I would like to get rid of any wasted time caused by watir itself. > > I think I've isolated the wasted time before the event in element.rb > where assert_enabled and highlight methods contribute to start time > latency. To overcome this I put this at the top of my test > > module Watir > class Element > def click! > assert_enabled > > highlight(:st) > @@start_time - Time.now > ole_object.click > highlight(:clear) > end > end > end > > I'm tempted to put an @@end_time after the call to ole_object.click to > see if I can recover some wasted time after the click event but I > don't really understand the logic behind Brett's comment on the wiki: > "Watir is deterministic. Watir does not wait X seconds. It waits until > the page is loaded. Period." > > i.e. what really determines the page is loaded (and can I put my > end_time statement there)? > > Is this the best way to achieve my goal? That is to accurately record > the response time as observed by the client (browser) following a > click event on a button or a link... > > > > > Regards, > Tim Koopmans > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marekj.com at gmail.com Wed Oct 14 11:05:56 2009 From: marekj.com at gmail.com (marekj) Date: Wed, 14 Oct 2009 10:05:56 -0500 Subject: [Wtr-development] A question of timing In-Reply-To: References: <93ee69e90910132146p59f10806tc2085f6e56e2b4e3@mail.gmail.com> Message-ID: As Ethan mentioned the IE#wait method is called on every click (most of them) I wrote a bit about it and about adding error_checkers. You could created a listener as as error_checker that reports a loadtime using the error_checker block. something like this perhaps that uses down_load_time module BrowserCheckers # reports to log the load time the page took on actions that call wait method LOADTIME_REPORTER = lambda do |ie| loadtime = ie.down_load_time if loadtime > 1.0 # not interested in things that take less than 1 second log.info "loadtime :#{ie.hwnd}; #{ie.title}; #{loadtime}" end end end then add it to error_checker loop ie.add_checker BrowserCheckers::LOADTIME_REPORTER the times may not be accurate but work for me. I run logging gem and output all the times to it for some audits later. marekj Watirloo: Semantic Page Objects in UseCases http://github.com/marekj/watirloo/ On Wed, Oct 14, 2009 at 9:54 AM, Ethan wrote: > Tim, > In the code you pasted, the 'click' method of the WIN32OLE is called without > waiting for any result. This should return as soon as any javascript events > associated with the onclick event return (if there are none, then it should > return immediately). > If you're waiting for new page to load as a result of that click, you want > to see the the Watir::IE#wait method, in ie-class.rb. It blocks until any > new page is fully loaded. > What determines that the page is loaded is the page itself saying that it is > loaded, via WIN32OLE. There are a number of criteria for this, all of which > must be met: > The browser's WIN32OLE object's 'busy' attribute being false; > The browser WIN32OLE's 'readyState' attribute being equal to > READYSTATE_COMPLETE; > The browser WIN32OLE's 'document' attribute existing; > It then checks the following attributes of each document - the browser > window has a document, and each frame has a document; frames are checked > recursively: > The document WIN32OLE's 'readyState' attribute is equal to 'complete'. > > Again, you can see all of the relevant code for yourself for that, in > Watir::IE#wait method, in ie-class.rb. > > It is true that you should start your timer after calls to assert_enabled > and highlight; they both call to assert_exists which is possibly slightly > slow - although certainly not on the order of 2-4 seconds. > > Hope that helps. > > Ethan > > On Wed, Oct 14, 2009 at 00:46, Tim Koopmans wrote: >> >> Hi guys, >> >> I've been using watir recently in load tests, to drive single user >> transactions from a browser whilst the backend servers are under load. >> We're particularly interested in things like client render time which >> is otherwise hard to measure. Not really affected by server load but >> of interest to the client ... >> >> The naive way of measuring 'browser time' is to wrap timers around the >> transaction of interest. >> >> e.g. >> start_time = Time.now >> browser.button(:text, "Search").click >> end_time = Time.now >> >> elapsed_time = end_time - start_time >> ... >> >> However when observing this replay in the browser there seems to be >> some latency both before and after the click event which is included >> in my elapsed time. Observing differences between fiddler session >> times (network + server) and watir times (browser) range in the order >> of 2 - 4 seconds. I know some can be attributed to client rendering >> but I would like to get rid of any wasted time caused by watir itself. >> >> I think I've isolated the wasted time before the event in element.rb >> where assert_enabled and highlight methods contribute to start time >> latency. To overcome this I put this at the top of my test >> >> module Watir >> ?class Element >> ? ?def click! >> ? ? ?assert_enabled >> >> ? ? ?highlight(:st) >> ? ? ?@@start_time - Time.now >> ? ? ? ole_object.click >> ? ? ?highlight(:clear) >> ? ?end >> ?end >> end >> >> I'm tempted to put an @@end_time after the call to ole_object.click to >> see if I can recover some wasted time after the click event but I >> don't really understand the logic behind Brett's comment on the wiki: >> "Watir is deterministic. Watir does not wait X seconds. It waits until >> the page is loaded. Period." >> >> i.e. what really determines the page is loaded (and can I put my >> end_time statement there)? >> >> Is this the best way to achieve my goal? That is to accurately record >> the response time as observed by the client (browser) following a >> click event on a button or a link... >> >> >> >> >> Regards, >> Tim Koopmans >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From marekj.com at gmail.com Wed Oct 14 11:06:49 2009 From: marekj.com at gmail.com (marekj) Date: Wed, 14 Oct 2009 10:06:49 -0500 Subject: [Wtr-development] A question of timing In-Reply-To: References: <93ee69e90910132146p59f10806tc2085f6e56e2b4e3@mail.gmail.com> Message-ID: Oops. forgot to the about those error_checkers and wait method http://rubytester.com/blog/2009/07/27/watir-run-error-checks-callback-in-wait-method.html marekj Watirloo: Semantic Page Objects in UseCases http://github.com/marekj/watirloo/ On Wed, Oct 14, 2009 at 10:05 AM, marekj wrote: > As Ethan mentioned the IE#wait method is called on every click (most of them) > I wrote a bit about it and about adding error_checkers. > You could created a listener as as error_checker that reports a > loadtime using the error_checker block. > something like this perhaps that uses down_load_time > > module BrowserCheckers > ?# reports to log the load time the page took on actions that call wait method > ?LOADTIME_REPORTER = lambda do |ie| > ? ?loadtime = ie.down_load_time > ? ?if loadtime > 1.0 # not interested in things that take less than 1 second > ? ? ?log.info "loadtime :#{ie.hwnd}; #{ie.title}; #{loadtime}" > ? ?end > ?end > end > > then add it to error_checker loop > ie.add_checker BrowserCheckers::LOADTIME_REPORTER > > the times may not be accurate but work for me. > I run logging gem and output all the times to it for some audits later. > > > marekj > > Watirloo: Semantic Page Objects in UseCases > http://github.com/marekj/watirloo/ > > > > > On Wed, Oct 14, 2009 at 9:54 AM, Ethan wrote: >> Tim, >> In the code you pasted, the 'click' method of the WIN32OLE is called without >> waiting for any result. This should return as soon as any javascript events >> associated with the onclick event return (if there are none, then it should >> return immediately). >> If you're waiting for new page to load as a result of that click, you want >> to see the the Watir::IE#wait method, in ie-class.rb. It blocks until any >> new page is fully loaded. >> What determines that the page is loaded is the page itself saying that it is >> loaded, via WIN32OLE. There are a number of criteria for this, all of which >> must be met: >> The browser's WIN32OLE object's 'busy' attribute being false; >> The browser WIN32OLE's 'readyState' attribute being equal to >> READYSTATE_COMPLETE; >> The browser WIN32OLE's 'document' attribute existing; >> It then checks the following attributes of each document - the browser >> window has a document, and each frame has a document; frames are checked >> recursively: >> The document WIN32OLE's 'readyState' attribute is equal to 'complete'. >> >> Again, you can see all of the relevant code for yourself for that, in >> Watir::IE#wait method, in ie-class.rb. >> >> It is true that you should start your timer after calls to assert_enabled >> and highlight; they both call to assert_exists which is possibly slightly >> slow - although certainly not on the order of 2-4 seconds. >> >> Hope that helps. >> >> Ethan >> >> On Wed, Oct 14, 2009 at 00:46, Tim Koopmans wrote: >>> >>> Hi guys, >>> >>> I've been using watir recently in load tests, to drive single user >>> transactions from a browser whilst the backend servers are under load. >>> We're particularly interested in things like client render time which >>> is otherwise hard to measure. Not really affected by server load but >>> of interest to the client ... >>> >>> The naive way of measuring 'browser time' is to wrap timers around the >>> transaction of interest. >>> >>> e.g. >>> start_time = Time.now >>> browser.button(:text, "Search").click >>> end_time = Time.now >>> >>> elapsed_time = end_time - start_time >>> ... >>> >>> However when observing this replay in the browser there seems to be >>> some latency both before and after the click event which is included >>> in my elapsed time. Observing differences between fiddler session >>> times (network + server) and watir times (browser) range in the order >>> of 2 - 4 seconds. I know some can be attributed to client rendering >>> but I would like to get rid of any wasted time caused by watir itself. >>> >>> I think I've isolated the wasted time before the event in element.rb >>> where assert_enabled and highlight methods contribute to start time >>> latency. To overcome this I put this at the top of my test >>> >>> module Watir >>> ?class Element >>> ? ?def click! >>> ? ? ?assert_enabled >>> >>> ? ? ?highlight(:st) >>> ? ? ?@@start_time - Time.now >>> ? ? ? ole_object.click >>> ? ? ?highlight(:clear) >>> ? ?end >>> ?end >>> end >>> >>> I'm tempted to put an @@end_time after the call to ole_object.click to >>> see if I can recover some wasted time after the click event but I >>> don't really understand the logic behind Brett's comment on the wiki: >>> "Watir is deterministic. Watir does not wait X seconds. It waits until >>> the page is loaded. Period." >>> >>> i.e. what really determines the page is loaded (and can I put my >>> end_time statement there)? >>> >>> Is this the best way to achieve my goal? That is to accurately record >>> the response time as observed by the client (browser) following a >>> click event on a button or a link... >>> >>> >>> >>> >>> Regards, >>> Tim Koopmans >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > From angrez at gmail.com Wed Oct 14 13:16:13 2009 From: angrez at gmail.com (Angrez Singh) Date: Wed, 14 Oct 2009 22:46:13 +0530 Subject: [Wtr-development] Release 1.6.5rc2? In-Reply-To: References: Message-ID: How to push it to my own fork? I committed the changes, when I use "git push" it gives error? Shall I use "git push origin master"? - Angrez On Wed, Oct 14, 2009 at 8:00 PM, Bret Pettichord wrote: > Could you push these changes to your own fork so we can review the code and > comment on it? > > Bret > > > On Wed, Oct 14, 2009 at 12:59 AM, Angrez Singh wrote: > >> I have a couple of new things added to Firewatir (got few hours free this >> week :)): >> 1. close_all_browsers method was missing >> 2. click_no_wait method added for handling javascript pop ups >> 3. added new method for entering username, password in authentication pop >> up. >> >> Let me know where it should go. >> >> Thanks, >> Angrez >> >> On Wed, Oct 14, 2009 at 3:44 AM, ?eljko Filipin < >> zeljko.filipin at wa-research.ch> wrote: >> >>> On Tue, Oct 13, 2009 at 7:29 PM, Charley Baker >>> wrote: >>> > Unless anyone has any objections, I'm going to tag and release >>> 1.6.5.rc2 either end of day today or first thing tomorrow and send a mail to >>> watir-general. >>> >>> +1 >>> >>> ?eljko >>> -- >>> http://watirpodcast.com/ >>> >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charley.baker at gmail.com Wed Oct 14 15:02:09 2009 From: charley.baker at gmail.com (Charley Baker) Date: Wed, 14 Oct 2009 13:02:09 -0600 Subject: [Wtr-development] Release 1.6.5rc2? In-Reply-To: References: Message-ID: This page should help explain it: http://help.github.com/forking/ I would like to wait for these changes if you can get them in quickly; it certainly would help answer a lot of questions on the list. If you can commit these now, and submit a pull request, we can make a quick decision as to whether to include them now or later. LMK -Charley On Wed, Oct 14, 2009 at 11:16 AM, Angrez Singh wrote: > How to push it to my own fork? I committed the changes, when I use "git > push" it gives error? Shall I use "git push origin master"? > > - Angrez > > > On Wed, Oct 14, 2009 at 8:00 PM, Bret Pettichord wrote: > >> Could you push these changes to your own fork so we can review the code >> and comment on it? >> >> Bret >> >> >> On Wed, Oct 14, 2009 at 12:59 AM, Angrez Singh wrote: >> >>> I have a couple of new things added to Firewatir (got few hours free this >>> week :)): >>> 1. close_all_browsers method was missing >>> 2. click_no_wait method added for handling javascript pop ups >>> 3. added new method for entering username, password in authentication pop >>> up. >>> >>> Let me know where it should go. >>> >>> Thanks, >>> Angrez >>> >>> On Wed, Oct 14, 2009 at 3:44 AM, ?eljko Filipin < >>> zeljko.filipin at wa-research.ch> wrote: >>> >>>> On Tue, Oct 13, 2009 at 7:29 PM, Charley Baker >>>> wrote: >>>> > Unless anyone has any objections, I'm going to tag and release >>>> 1.6.5.rc2 either end of day today or first thing tomorrow and send a mail to >>>> watir-general. >>>> >>>> +1 >>>> >>>> ?eljko >>>> -- >>>> http://watirpodcast.com/ >>>> >>>> >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>> >>> >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> >> >> -- >> Bret Pettichord >> Lead Developer, Watir, www.watir.com >> >> Blog, www.io.com/~wazmo/blog >> Twitter, www.twitter.com/bpettichord >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.koops at gmail.com Wed Oct 14 20:07:23 2009 From: tim.koops at gmail.com (Tim Koopmans) Date: Thu, 15 Oct 2009 11:07:23 +1100 Subject: [Wtr-development] A question of timing In-Reply-To: <0016e64af8a858a94d0475ede81c@google.com> References: <00504502f52b1669a50475edc661@google.com> <0016e64af8a858a94d0475ede81c@google.com> Message-ID: <93ee69e90910141707t2be5a909l50cf5d928fdae4be@mail.gmail.com> This is what I've hacked together for now using an @wasted_time instance variable ... module Watir class IE def wait(no_sleep=false) @rexmlDomobject = nil @down_load_time = 0.0 @wasted_time = 0.0 a_moment = 0.2 # seconds start_load_time = Time.now begin while @ie.busy # XXX need to add time out sleep a_moment @wasted_time += a_moment end until @ie.readyState == READYSTATE_COMPLETE do sleep a_moment @wasted_time += a_moment end sleep a_moment @wasted_time += a_moment until @ie.document do sleep a_moment @wasted_time += a_moment end documents_to_wait_for = [@ie.document] rescue WIN32OLERuntimeError # IE window must have been closed @down_load_time = Time.now - start_load_time sleep @pause_after_wait unless no_sleep return @down_load_time end while doc = documents_to_wait_for.shift begin until doc.readyState == "complete" do sleep a_moment @wasted_time += a_moment end @url_list << doc.location.href unless @url_list.include?(doc.location.href) doc.frames.length.times do |n| begin documents_to_wait_for << doc.frames[n.to_s].document rescue WIN32OLERuntimeError, NoMethodError end end rescue WIN32OLERuntimeError end end @down_load_time = Time.now - start_load_time - @wasted_time run_error_checks sleep @pause_after_wait unless no_sleep @down_load_time end end end Regards, Tim Koopmans On Thu, Oct 15, 2009 at 10:56 AM, wrote: > Actually looking at this in more detail, it would appear that watir may wait > for up to 0.8 seconds for a single page, due to the sequential while and > until loops in def wait. There is also a minimum fixed 0.2 seconds outside > of any loop. And if my page happens to have inner frames etc (which my > application does) then there are further penalties for the > documents_to_wait_for. This may start to explain why I'm seeing additional > time in my measurements. > > We really just want to calculate render time, so I might try and hack > together a modified wait method that excludes wasted time on sleep calls. > > Thanks! > > Tim > > On 15/10/2009 10:46am, tim.koops at gmail.com wrote: >> Thanks guys for your help. >> >> Now that you mention it, ie-class.rb already has a down_load_time >> attribute which I think is what I need for now. I believe this would be >> accurate to +/- 0.2 seconds since that is what the a_moment variable is set >> to (when sleeping between various checks for ie busy/ready states, including >> recursive documents. >> >> Thanks again! >> >> On 15/10/2009 1:54am, Ethan notethan at gmail.com> wrote: >> > Tim, >> > In the code you pasted, the 'click' method of the WIN32OLE is called >> > without waiting for any result. This should return as soon as any javascript >> > events associated with the onclick event return (if there are none, then it >> > should return immediately). >> > >> > >> > If you're waiting for new page to load as a result of that click, you >> > want to see the the Watir::IE#wait method, in ie-class.rb. It blocks until >> > any new page is fully loaded. >> > What determines that the page is loaded is the page itself saying that >> > it is loaded, via WIN32OLE. There are a number of criteria for this, all of >> > which must be met: >> > >> > >> > The browser's WIN32OLE object's 'busy' attribute being false; >> > The browser WIN32OLE's 'readyState' attribute being equal to >> > READYSTATE_COMPLETE; >> > The browser WIN32OLE's 'document' attribute existing; >> > >> > >> > It then checks the following attributes of each document - the browser >> > window has a document, and each frame has a document; frames are checked >> > recursively: >> > The document WIN32OLE's 'readyState' attribute is equal to 'complete'. >> > >> > >> > >> > Again, you can see all of the relevant code for yourself for that, in >> > Watir::IE#wait method, in ie-class.rb. >> > >> > It is true that you should start your timer after calls to >> > assert_enabled and highlight; they both call to assert_exists which is >> > possibly slightly slow - although certainly not on the order of 2-4 seconds. >> > >> > >> > >> > Hope that helps. >> > >> > Ethan >> > >> > On Wed, Oct 14, 2009 at 00:46, Tim Koopmans tim.koops at gmail.com> wrote: >> > >> > >> > >> > Hi guys, >> > >> > >> > >> > I've been using watir recently in load tests, to drive single user >> > >> > transactions from a browser whilst the backend servers are under load. >> > >> > We're particularly interested in things like client render time which >> > >> > is otherwise hard to measure. Not really affected by server load but >> > >> > of interest to the client ... >> > >> > >> > >> > The naive way of measuring 'browser time' is to wrap timers around the >> > >> > transaction of interest. >> > >> > >> > >> > e.g. >> > >> > start_time = Time.now >> > >> > browser.button(:text, "Search").click >> > >> > end_time = Time.now >> > >> > >> > >> > elapsed_time = end_time - start_time >> > >> > ... >> > >> > >> > >> > However when observing this replay in the browser there seems to be >> > >> > some latency both before and after the click event which is included >> > >> > in my elapsed time. Observing differences between fiddler session >> > >> > times (network + server) and watir times (browser) range in the order >> > >> > of 2 - 4 seconds. I know some can be attributed to client rendering >> > >> > but I would like to get rid of any wasted time caused by watir itself. >> > >> > >> > >> > I think I've isolated the wasted time before the event in element.rb >> > >> > where assert_enabled and highlight methods contribute to start time >> > >> > latency. To overcome this I put this at the top of my test >> > >> > >> > >> > module Watir >> > >> > ?class Element >> > >> > ? ?def click! >> > >> > ? ? ?assert_enabled >> > >> > >> > >> > ? ? ?highlight(:st) >> > >> > ? ? ?@@start_time - Time.now >> > >> > ? ? ? ole_object.click >> > >> > ? ? ?highlight(:clear) >> > >> > ? ?end >> > >> > ?end >> > >> > end >> > >> > >> > >> > I'm tempted to put an @@end_time after the call to ole_object.click to >> > >> > see if I can recover some wasted time after the click event but I >> > >> > don't really understand the logic behind Brett's comment on the wiki: >> > >> > "Watir is deterministic. Watir does not wait X seconds. It waits until >> > >> > the page is loaded. Period." >> > >> > >> > >> > i.e. what really determines the page is loaded (and can I put my >> > >> > end_time statement there)? >> > >> > >> > >> > Is this the best way to achieve my goal? That is to accurately record >> > >> > the response time as observed by the client (browser) following a >> > >> > click event on a button or a link... >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > Regards, >> > >> > Tim Koopmans >> > >> > _______________________________________________ >> > >> > Wtr-development mailing list >> > >> > Wtr-development at rubyforge.org >> > >> > http://rubyforge.org/mailman/listinfo/wtr-development >> > >> > >> > >> > From notethan at gmail.com Wed Oct 14 20:29:11 2009 From: notethan at gmail.com (Ethan) Date: Wed, 14 Oct 2009 20:29:11 -0400 Subject: [Wtr-development] A question of timing In-Reply-To: <93ee69e90910141707t2be5a909l50cf5d928fdae4be@mail.gmail.com> References: <00504502f52b1669a50475edc661@google.com> <0016e64af8a858a94d0475ede81c@google.com> <93ee69e90910141707t2be5a909l50cf5d928fdae4be@mail.gmail.com> Message-ID: Your "wasted time" is mostly going to be time actually spent waiting for the page to be in a ready state. Most of those sleeps are not wasting time; they represent time that the browser is taking to load. Except for that one that's not in a while loop, I don't know what that's doing there. I believe that's been fixed in the latest head on github; you can remove it. Anyway, this line will be highly inaccurate: @down_load_time = Time.now - start_load_time - @wasted_time I'm also not sure why no_sleep defaults to false, seems to me that it should default to true. Though I do not know what @pase_after_wait defaults to, maybe it's 0. You could get more precise results by dropping a_moment from 0.2 to to something much lower, 0.01 or something. I don't think it would make a difference to anything else; a hundredth of a second is still a relatively long time compared to how long the ruby code around this should take to run. On Wed, Oct 14, 2009 at 20:07, Tim Koopmans wrote: > This is what I've hacked together for now using an @wasted_time > instance variable ... > > > module Watir > class IE > def wait(no_sleep=false) > @rexmlDomobject = nil > @down_load_time = 0.0 > @wasted_time = 0.0 > a_moment = 0.2 # seconds > start_load_time = Time.now > > begin > while @ie.busy # XXX need to add time out > sleep a_moment > @wasted_time += a_moment > end > until @ie.readyState == READYSTATE_COMPLETE do > sleep a_moment > @wasted_time += a_moment > end > sleep a_moment > @wasted_time += a_moment > until @ie.document do > sleep a_moment > @wasted_time += a_moment > end > > documents_to_wait_for = [@ie.document] > > rescue WIN32OLERuntimeError # IE window must have been closed > @down_load_time = Time.now - start_load_time > sleep @pause_after_wait unless no_sleep > return @down_load_time > end > > while doc = documents_to_wait_for.shift > begin > until doc.readyState == "complete" do > sleep a_moment > @wasted_time += a_moment > end > @url_list << doc.location.href unless > @url_list.include?(doc.location.href) > doc.frames.length.times do |n| > begin > documents_to_wait_for << doc.frames[n.to_s].document > rescue WIN32OLERuntimeError, NoMethodError > end > end > rescue WIN32OLERuntimeError > end > end > > @down_load_time = Time.now - start_load_time - @wasted_time > run_error_checks > sleep @pause_after_wait unless no_sleep > @down_load_time > end > end > end > > Regards, > Tim Koopmans > > > > On Thu, Oct 15, 2009 at 10:56 AM, wrote: > > Actually looking at this in more detail, it would appear that watir may > wait > > for up to 0.8 seconds for a single page, due to the sequential while and > > until loops in def wait. There is also a minimum fixed 0.2 seconds > outside > > of any loop. And if my page happens to have inner frames etc (which my > > application does) then there are further penalties for the > > documents_to_wait_for. This may start to explain why I'm seeing > additional > > time in my measurements. > > > > We really just want to calculate render time, so I might try and hack > > together a modified wait method that excludes wasted time on sleep calls. > > > > Thanks! > > > > Tim > > > > On 15/10/2009 10:46am, tim.koops at gmail.com wrote: > >> Thanks guys for your help. > >> > >> Now that you mention it, ie-class.rb already has a down_load_time > >> attribute which I think is what I need for now. I believe this would be > >> accurate to +/- 0.2 seconds since that is what the a_moment variable is > set > >> to (when sleeping between various checks for ie busy/ready states, > including > >> recursive documents. > >> > >> Thanks again! > >> > >> On 15/10/2009 1:54am, Ethan notethan at gmail.com> wrote: > >> > Tim, > >> > In the code you pasted, the 'click' method of the WIN32OLE is called > >> > without waiting for any result. This should return as soon as any > javascript > >> > events associated with the onclick event return (if there are none, > then it > >> > should return immediately). > >> > > >> > > >> > If you're waiting for new page to load as a result of that click, you > >> > want to see the the Watir::IE#wait method, in ie-class.rb. It blocks > until > >> > any new page is fully loaded. > >> > What determines that the page is loaded is the page itself saying that > >> > it is loaded, via WIN32OLE. There are a number of criteria for this, > all of > >> > which must be met: > >> > > >> > > >> > The browser's WIN32OLE object's 'busy' attribute being false; > >> > The browser WIN32OLE's 'readyState' attribute being equal to > >> > READYSTATE_COMPLETE; > >> > The browser WIN32OLE's 'document' attribute existing; > >> > > >> > > >> > It then checks the following attributes of each document - the browser > >> > window has a document, and each frame has a document; frames are > checked > >> > recursively: > >> > The document WIN32OLE's 'readyState' attribute is equal to 'complete'. > >> > > >> > > >> > > >> > Again, you can see all of the relevant code for yourself for that, in > >> > Watir::IE#wait method, in ie-class.rb. > >> > > >> > It is true that you should start your timer after calls to > >> > assert_enabled and highlight; they both call to assert_exists which is > >> > possibly slightly slow - although certainly not on the order of 2-4 > seconds. > >> > > >> > > >> > > >> > Hope that helps. > >> > > >> > Ethan > >> > > >> > On Wed, Oct 14, 2009 at 00:46, Tim Koopmans tim.koops at gmail.com> > wrote: > >> > > >> > > >> > > >> > Hi guys, > >> > > >> > > >> > > >> > I've been using watir recently in load tests, to drive single user > >> > > >> > transactions from a browser whilst the backend servers are under load. > >> > > >> > We're particularly interested in things like client render time which > >> > > >> > is otherwise hard to measure. Not really affected by server load but > >> > > >> > of interest to the client ... > >> > > >> > > >> > > >> > The naive way of measuring 'browser time' is to wrap timers around the > >> > > >> > transaction of interest. > >> > > >> > > >> > > >> > e.g. > >> > > >> > start_time = Time.now > >> > > >> > browser.button(:text, "Search").click > >> > > >> > end_time = Time.now > >> > > >> > > >> > > >> > elapsed_time = end_time - start_time > >> > > >> > ... > >> > > >> > > >> > > >> > However when observing this replay in the browser there seems to be > >> > > >> > some latency both before and after the click event which is included > >> > > >> > in my elapsed time. Observing differences between fiddler session > >> > > >> > times (network + server) and watir times (browser) range in the order > >> > > >> > of 2 - 4 seconds. I know some can be attributed to client rendering > >> > > >> > but I would like to get rid of any wasted time caused by watir itself. > >> > > >> > > >> > > >> > I think I've isolated the wasted time before the event in element.rb > >> > > >> > where assert_enabled and highlight methods contribute to start time > >> > > >> > latency. To overcome this I put this at the top of my test > >> > > >> > > >> > > >> > module Watir > >> > > >> > class Element > >> > > >> > def click! > >> > > >> > assert_enabled > >> > > >> > > >> > > >> > highlight(:st) > >> > > >> > @@start_time - Time.now > >> > > >> > ole_object.click > >> > > >> > highlight(:clear) > >> > > >> > end > >> > > >> > end > >> > > >> > end > >> > > >> > > >> > > >> > I'm tempted to put an @@end_time after the call to ole_object.click to > >> > > >> > see if I can recover some wasted time after the click event but I > >> > > >> > don't really understand the logic behind Brett's comment on the wiki: > >> > > >> > "Watir is deterministic. Watir does not wait X seconds. It waits until > >> > > >> > the page is loaded. Period." > >> > > >> > > >> > > >> > i.e. what really determines the page is loaded (and can I put my > >> > > >> > end_time statement there)? > >> > > >> > > >> > > >> > Is this the best way to achieve my goal? That is to accurately record > >> > > >> > the response time as observed by the client (browser) following a > >> > > >> > click event on a button or a link... > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > Regards, > >> > > >> > Tim Koopmans > >> > > >> > _______________________________________________ > >> > > >> > Wtr-development mailing list > >> > > >> > Wtr-development at rubyforge.org > >> > > >> > http://rubyforge.org/mailman/listinfo/wtr-development > >> > > >> > > >> > > >> > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.koops at gmail.com Wed Oct 14 21:04:19 2009 From: tim.koops at gmail.com (Tim Koopmans) Date: Thu, 15 Oct 2009 12:04:19 +1100 Subject: [Wtr-development] A question of timing In-Reply-To: References: <00504502f52b1669a50475edc661@google.com> <0016e64af8a858a94d0475ede81c@google.com> <93ee69e90910141707t2be5a909l50cf5d928fdae4be@mail.gmail.com> Message-ID: <93ee69e90910141804r664b7210p2c0299a84ffbf8ff@mail.gmail.com> Yes, see what you mean, those sleep a_moments are necessary, it's really just the last sleep a_moment in the loop that is potentially wasted, but as you said the impact of this could be reduced by decreasing a_moment to 0.01. Thanks for spotting this! Regards, Tim Koopmans On Thu, Oct 15, 2009 at 11:29 AM, Ethan wrote: > Your "wasted time" is mostly going to be time actually spent waiting for the > page to be in a ready state. Most of those sleeps are not wasting time; they > represent time that the browser is taking to load. Except for that one > that's not in a while loop, I don't know what that's doing there. I believe > that's been fixed in the latest head on github; you can remove it. Anyway, > this line will be highly inaccurate: > @down_load_time = Time.now - start_load_time - @wasted_time > I'm also not sure why no_sleep defaults to false, seems to me that it should > default to true. Though I do not know what @pase_after_wait defaults to, > maybe it's 0. > You could get more precise results by dropping a_moment from 0.2 to to > something much lower, 0.01 or something. I don't think it would make a > difference to anything else; a hundredth of a second is still a relatively > long time compared to how long the ruby code around this should take to > run. > > On Wed, Oct 14, 2009 at 20:07, Tim Koopmans wrote: >> >> This is what I've hacked together for now using an @wasted_time >> instance variable ... >> >> >> module Watir >> ?class IE >> ? def wait(no_sleep=false) >> ? ? @rexmlDomobject = nil >> ? ? @down_load_time = 0.0 >> ? ? @wasted_time ? ?= 0.0 >> ? ? a_moment = 0.2 # seconds >> ? ? start_load_time = Time.now >> >> ? ? begin >> ? ? ? while @ie.busy # XXX need to add time out >> ? ? ? ? sleep a_moment >> ? ? ? ? @wasted_time += a_moment >> ? ? ? end >> ? ? ? until @ie.readyState == READYSTATE_COMPLETE do >> ? ? ? ? sleep a_moment >> ? ? ? ? @wasted_time += a_moment >> ? ? ? end >> ? ? ? sleep a_moment >> ? ? ? @wasted_time += a_moment >> ? ? ? until @ie.document do >> ? ? ? ? sleep a_moment >> ? ? ? ? @wasted_time += a_moment >> ? ? ? end >> >> ? ? ? documents_to_wait_for = [@ie.document] >> >> ? ? rescue WIN32OLERuntimeError # IE window must have been closed >> ? ? ? @down_load_time = Time.now - start_load_time >> ? ? ? sleep @pause_after_wait unless no_sleep >> ? ? ? return @down_load_time >> ? ? end >> >> ? ? while doc = documents_to_wait_for.shift >> ? ? ? begin >> ? ? ? ? until doc.readyState == "complete" do >> ? ? ? ? ? sleep a_moment >> ? ? ? ? ? @wasted_time += a_moment >> ? ? ? ? end >> ? ? ? ? @url_list << doc.location.href unless >> @url_list.include?(doc.location.href) >> ? ? ? ? doc.frames.length.times do |n| >> ? ? ? ? ? begin >> ? ? ? ? ? ? documents_to_wait_for << doc.frames[n.to_s].document >> ? ? ? ? ? rescue WIN32OLERuntimeError, NoMethodError >> ? ? ? ? ? end >> ? ? ? ? end >> ? ? ? rescue WIN32OLERuntimeError >> ? ? ? end >> ? ? end >> >> ? ? @down_load_time = Time.now - start_load_time - @wasted_time >> ? ? run_error_checks >> ? ? sleep @pause_after_wait unless no_sleep >> ? ? @down_load_time >> ? end >> ?end >> end >> >> Regards, >> Tim Koopmans >> >> >> >> On Thu, Oct 15, 2009 at 10:56 AM, ? wrote: >> > Actually looking at this in more detail, it would appear that watir may >> > wait >> > for up to 0.8 seconds for a single page, due to the sequential while and >> > until loops in def wait. There is also a minimum fixed 0.2 seconds >> > outside >> > of any loop. And if my page happens to have inner frames etc (which my >> > application does) then there are further penalties for the >> > documents_to_wait_for. This may start to explain why I'm seeing >> > additional >> > time in my measurements. >> > >> > We really just want to calculate render time, so I might try and hack >> > together a modified wait method that excludes wasted time on sleep >> > calls. >> > >> > Thanks! >> > >> > Tim >> > >> > On 15/10/2009 10:46am, tim.koops at gmail.com wrote: >> >> Thanks guys for your help. >> >> >> >> Now that you mention it, ie-class.rb already has a down_load_time >> >> attribute which I think is what I need for now. I believe this would be >> >> accurate to +/- 0.2 seconds since that is what the a_moment variable is >> >> set >> >> to (when sleeping between various checks for ie busy/ready states, >> >> including >> >> recursive documents. >> >> >> >> Thanks again! >> >> >> >> On 15/10/2009 1:54am, Ethan notethan at gmail.com> wrote: >> >> > Tim, >> >> > In the code you pasted, the 'click' method of the WIN32OLE is called >> >> > without waiting for any result. This should return as soon as any >> >> > javascript >> >> > events associated with the onclick event return (if there are none, >> >> > then it >> >> > should return immediately). >> >> > >> >> > >> >> > If you're waiting for new page to load as a result of that click, you >> >> > want to see the the Watir::IE#wait method, in ie-class.rb. It blocks >> >> > until >> >> > any new page is fully loaded. >> >> > What determines that the page is loaded is the page itself saying >> >> > that >> >> > it is loaded, via WIN32OLE. There are a number of criteria for this, >> >> > all of >> >> > which must be met: >> >> > >> >> > >> >> > The browser's WIN32OLE object's 'busy' attribute being false; >> >> > The browser WIN32OLE's 'readyState' attribute being equal to >> >> > READYSTATE_COMPLETE; >> >> > The browser WIN32OLE's 'document' attribute existing; >> >> > >> >> > >> >> > It then checks the following attributes of each document - the >> >> > browser >> >> > window has a document, and each frame has a document; frames are >> >> > checked >> >> > recursively: >> >> > The document WIN32OLE's 'readyState' attribute is equal to >> >> > 'complete'. >> >> > >> >> > >> >> > >> >> > Again, you can see all of the relevant code for yourself for that, in >> >> > Watir::IE#wait method, in ie-class.rb. >> >> > >> >> > It is true that you should start your timer after calls to >> >> > assert_enabled and highlight; they both call to assert_exists which >> >> > is >> >> > possibly slightly slow - although certainly not on the order of 2-4 >> >> > seconds. >> >> > >> >> > >> >> > >> >> > Hope that helps. >> >> > >> >> > Ethan >> >> > >> >> > On Wed, Oct 14, 2009 at 00:46, Tim Koopmans tim.koops at gmail.com> >> >> > wrote: >> >> > >> >> > >> >> > >> >> > Hi guys, >> >> > >> >> > >> >> > >> >> > I've been using watir recently in load tests, to drive single user >> >> > >> >> > transactions from a browser whilst the backend servers are under >> >> > load. >> >> > >> >> > We're particularly interested in things like client render time which >> >> > >> >> > is otherwise hard to measure. Not really affected by server load but >> >> > >> >> > of interest to the client ... >> >> > >> >> > >> >> > >> >> > The naive way of measuring 'browser time' is to wrap timers around >> >> > the >> >> > >> >> > transaction of interest. >> >> > >> >> > >> >> > >> >> > e.g. >> >> > >> >> > start_time = Time.now >> >> > >> >> > browser.button(:text, "Search").click >> >> > >> >> > end_time = Time.now >> >> > >> >> > >> >> > >> >> > elapsed_time = end_time - start_time >> >> > >> >> > ... >> >> > >> >> > >> >> > >> >> > However when observing this replay in the browser there seems to be >> >> > >> >> > some latency both before and after the click event which is included >> >> > >> >> > in my elapsed time. Observing differences between fiddler session >> >> > >> >> > times (network + server) and watir times (browser) range in the order >> >> > >> >> > of 2 - 4 seconds. I know some can be attributed to client rendering >> >> > >> >> > but I would like to get rid of any wasted time caused by watir >> >> > itself. >> >> > >> >> > >> >> > >> >> > I think I've isolated the wasted time before the event in element.rb >> >> > >> >> > where assert_enabled and highlight methods contribute to start time >> >> > >> >> > latency. To overcome this I put this at the top of my test >> >> > >> >> > >> >> > >> >> > module Watir >> >> > >> >> > ?class Element >> >> > >> >> > ? ?def click! >> >> > >> >> > ? ? ?assert_enabled >> >> > >> >> > >> >> > >> >> > ? ? ?highlight(:st) >> >> > >> >> > ? ? ?@@start_time - Time.now >> >> > >> >> > ? ? ? ole_object.click >> >> > >> >> > ? ? ?highlight(:clear) >> >> > >> >> > ? ?end >> >> > >> >> > ?end >> >> > >> >> > end >> >> > >> >> > >> >> > >> >> > I'm tempted to put an @@end_time after the call to ole_object.click >> >> > to >> >> > >> >> > see if I can recover some wasted time after the click event but I >> >> > >> >> > don't really understand the logic behind Brett's comment on the wiki: >> >> > >> >> > "Watir is deterministic. Watir does not wait X seconds. It waits >> >> > until >> >> > >> >> > the page is loaded. Period." >> >> > >> >> > >> >> > >> >> > i.e. what really determines the page is loaded (and can I put my >> >> > >> >> > end_time statement there)? >> >> > >> >> > >> >> > >> >> > Is this the best way to achieve my goal? That is to accurately record >> >> > >> >> > the response time as observed by the client (browser) following a >> >> > >> >> > click event on a button or a link... >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > Regards, >> >> > >> >> > Tim Koopmans >> >> > >> >> > _______________________________________________ >> >> > >> >> > Wtr-development mailing list >> >> > >> >> > Wtr-development at rubyforge.org >> >> > >> >> > http://rubyforge.org/mailman/listinfo/wtr-development >> >> > >> >> > >> >> > >> >> > >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From bret at pettichord.com Wed Oct 14 21:04:56 2009 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 14 Oct 2009 20:04:56 -0500 Subject: [Wtr-development] Release 1.6.5rc2? In-Reply-To: References: Message-ID: Angrez, You will need to 1. create your own fork, as Charley describes 2. add a remote (git remote add angrez url) 3. push to it (git push angrez master) -- this pushes it to your fork 4. do the pull request This in general is the best way to hand code that you would like to be reviewed before it gets pulled into trunk. Jari, e.g., has been good about doing this. Bret On Wed, Oct 14, 2009 at 2:02 PM, Charley Baker wrote: > This page should help explain it: http://help.github.com/forking/ I > would like to wait for these changes if you can get them in quickly; it > certainly would help answer a lot of questions on the list. If you can > commit these now, and submit a pull request, we can make a quick decision as > to whether to include them now or later. LMK > > > -Charley > > > > > On Wed, Oct 14, 2009 at 11:16 AM, Angrez Singh wrote: > >> How to push it to my own fork? I committed the changes, when I use "git >> push" it gives error? Shall I use "git push origin master"? >> >> - Angrez >> >> >> On Wed, Oct 14, 2009 at 8:00 PM, Bret Pettichord wrote: >> >>> Could you push these changes to your own fork so we can review the code >>> and comment on it? >>> >>> Bret >>> >>> >>> On Wed, Oct 14, 2009 at 12:59 AM, Angrez Singh wrote: >>> >>>> I have a couple of new things added to Firewatir (got few hours free >>>> this week :)): >>>> 1. close_all_browsers method was missing >>>> 2. click_no_wait method added for handling javascript pop ups >>>> 3. added new method for entering username, password in authentication >>>> pop up. >>>> >>>> Let me know where it should go. >>>> >>>> Thanks, >>>> Angrez >>>> >>>> On Wed, Oct 14, 2009 at 3:44 AM, ?eljko Filipin < >>>> zeljko.filipin at wa-research.ch> wrote: >>>> >>>>> On Tue, Oct 13, 2009 at 7:29 PM, Charley Baker < >>>>> charley.baker at gmail.com> wrote: >>>>> > Unless anyone has any objections, I'm going to tag and release >>>>> 1.6.5.rc2 either end of day today or first thing tomorrow and send a mail to >>>>> watir-general. >>>>> >>>>> +1 >>>>> >>>>> ?eljko >>>>> -- >>>>> http://watirpodcast.com/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> Wtr-development mailing list >>>>> Wtr-development at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>> >>> >>> >>> >>> -- >>> Bret Pettichord >>> Lead Developer, Watir, www.watir.com >>> >>> Blog, www.io.com/~wazmo/blog >>> Twitter, www.twitter.com/bpettichord >>> >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.koops at gmail.com Wed Oct 14 21:15:27 2009 From: tim.koops at gmail.com (Tim Koopmans) Date: Thu, 15 Oct 2009 12:15:27 +1100 Subject: [Wtr-development] A question of timing In-Reply-To: References: <00504502f52b1669a50475edc661@google.com> <0016e64af8a858a94d0475ede81c@google.com> <93ee69e90910141707t2be5a909l50cf5d928fdae4be@mail.gmail.com> Message-ID: <93ee69e90910141815m4e3b3c89gcee770639626a2f2@mail.gmail.com> That's fine Bret, totally understand, and thanks for introducing me to the heisenberg principle! I'm happy to mix in my own module for this case, as accuracy is what I'm after. I'm also correlating results with fiddler traces at the same time for single test cases with about 30 steps. I'll keep an eye on CPU/mem but I'm on a fairly decent spec'd box (for loadrunner) so no problems observed yet with Intel core 2 duo (2.39GHz) and 2GB RAM. Regards, Tim Koopmans On Thu, Oct 15, 2009 at 12:01 PM, Bret Pettichord wrote: > On Wed, Oct 14, 2009 at 7:29 PM, Ethan wrote: >> >> You could get more precise results by dropping a_moment from 0.2 to to >> something much lower, 0.01 or something. I don't think it would make a >> difference to anything else; a hundredth of a second is still a relatively >> long time compared to how long the ruby code around this should take to >> run. > > You need to be careful about dropping the polling interval too low. I tried > several values, and this is what seemed to me to be the one that gave Watir > the best performance. If the polling interval is too long, then you risk > "wasting" time -- on average you will waste half of the polling interval on > each wait. > > On the other hand if the polling interval is too short, then the act of > polling itself consumes more CPU, thus slowing down other processes > (including the browser rendering). > > This is really a heisenberg principle. The smaller the polling interval, the > more accurate the result, but the more the act of measurement has changed > the thing being measured. > > On the other hand, it has been a long time since I chose the 0.2 polling > interval. We have newer versions of IE and now typically have more powerful > machines. I'm open to changing this interval if some one does some > experiments and has a better suggestion. But also note, that my goal has > been to make Watir as fast as possible, even if that means that the timings > aren't as accurate as possible. > > Bret > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From tim.koops at gmail.com Wed Oct 14 21:23:04 2009 From: tim.koops at gmail.com (Tim Koopmans) Date: Thu, 15 Oct 2009 12:23:04 +1100 Subject: [Wtr-development] A question of timing In-Reply-To: <93ee69e90910141815m4e3b3c89gcee770639626a2f2@mail.gmail.com> References: <00504502f52b1669a50475edc661@google.com> <0016e64af8a858a94d0475ede81c@google.com> <93ee69e90910141707t2be5a909l50cf5d928fdae4be@mail.gmail.com> <93ee69e90910141815m4e3b3c89gcee770639626a2f2@mail.gmail.com> Message-ID: <93ee69e90910141823g664cbcedpa04d33eac647113a@mail.gmail.com> Also which process would be most affected by this change? ruby.exe or iexplore.exe? Regards, Tim Koopmans On Thu, Oct 15, 2009 at 12:15 PM, Tim Koopmans wrote: > That's fine Bret, totally understand, and thanks for introducing me to > the heisenberg principle! > > I'm happy to mix in my own module for this case, as accuracy is what > I'm after. I'm also correlating results with fiddler traces at the > same time for single test cases with about 30 steps. I'll keep an eye > on CPU/mem but I'm on a fairly decent spec'd box (for loadrunner) so > no problems observed yet with Intel core 2 duo (2.39GHz) and 2GB RAM. > > > > Regards, > Tim Koopmans > > > > On Thu, Oct 15, 2009 at 12:01 PM, Bret Pettichord wrote: >> On Wed, Oct 14, 2009 at 7:29 PM, Ethan wrote: >>> >>> You could get more precise results by dropping a_moment from 0.2 to to >>> something much lower, 0.01 or something. I don't think it would make a >>> difference to anything else; a hundredth of a second is still a relatively >>> long time compared to how long the ruby code around this should take to >>> run. >> >> You need to be careful about dropping the polling interval too low. I tried >> several values, and this is what seemed to me to be the one that gave Watir >> the best performance. If the polling interval is too long, then you risk >> "wasting" time -- on average you will waste half of the polling interval on >> each wait. >> >> On the other hand if the polling interval is too short, then the act of >> polling itself consumes more CPU, thus slowing down other processes >> (including the browser rendering). >> >> This is really a heisenberg principle. The smaller the polling interval, the >> more accurate the result, but the more the act of measurement has changed >> the thing being measured. >> >> On the other hand, it has been a long time since I chose the 0.2 polling >> interval. We have newer versions of IE and now typically have more powerful >> machines. I'm open to changing this interval if some one does some >> experiments and has a better suggestion. But also note, that my goal has >> been to make Watir as fast as possible, even if that means that the timings >> aren't as accurate as possible. >> >> Bret >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > From tim.koops at gmail.com Wed Oct 14 23:04:57 2009 From: tim.koops at gmail.com (Tim Koopmans) Date: Thu, 15 Oct 2009 14:04:57 +1100 Subject: [Wtr-development] A question of timing In-Reply-To: References: <00504502f52b1669a50475edc661@google.com> <0016e64af8a858a94d0475ede81c@google.com> <93ee69e90910141707t2be5a909l50cf5d928fdae4be@mail.gmail.com> <93ee69e90910141815m4e3b3c89gcee770639626a2f2@mail.gmail.com> <93ee69e90910141823g664cbcedpa04d33eac647113a@mail.gmail.com> Message-ID: <93ee69e90910142004k12a4aaecg677115454b7c91e8@mail.gmail.com> Cool! When using 0.01 instead of 0.20 seconds for a_moment, the following differences were noted: iexplore.exe +0.27% overhead for the mean +1.88% overhead for the median ruby.exe -0.85% overhead for the mean +0.30% overhead for the median Metric sampled was \Process(ruby | iexplore)\%Processor Time every 5 seconds for approximately 10 minutes using the same test case for each run. When comparing @down_load_time to session times (observed in fiddler = network + server time) I am getting an average of 0.7 secs, which is assumed to be client render time with sleep a_moment = 0.01. The same test was showing client render time with an average of 1.4 secs with sleep a_moment = 0.20 I'm much happier with a_moment set to 0.01 for now. Thanks, Tim Koopmans On Thu, Oct 15, 2009 at 12:27 PM, Bret Pettichord wrote: > Good question. Probably some of both, but only one way to find out! Put it > to the test. > > Bret > > On Wed, Oct 14, 2009 at 8:23 PM, Tim Koopmans wrote: >> >> Also which process would be most affected by this change? >> ruby.exe or iexplore.exe? >> >> Regards, >> Tim Koopmans >> >> >> >> On Thu, Oct 15, 2009 at 12:15 PM, Tim Koopmans >> wrote: >> > That's fine Bret, totally understand, and thanks for introducing me to >> > the heisenberg principle! >> > >> > I'm happy to mix in my own module for this case, as accuracy is what >> > I'm after. I'm also correlating results with fiddler traces at the >> > same time for single test cases with about 30 steps. I'll keep an eye >> > on CPU/mem but I'm on a fairly decent spec'd box (for loadrunner) so >> > no problems observed yet with Intel core 2 duo (2.39GHz) and 2GB RAM. >> > >> > >> > >> > Regards, >> > Tim Koopmans >> > >> > >> > >> > On Thu, Oct 15, 2009 at 12:01 PM, Bret Pettichord >> > wrote: >> >> On Wed, Oct 14, 2009 at 7:29 PM, Ethan wrote: >> >>> >> >>> You could get more precise results by dropping a_moment from 0.2 to to >> >>> something much lower, 0.01 or something. I don't think it would make a >> >>> difference to anything else; a hundredth of a second is still a >> >>> relatively >> >>> long time compared to how long the ruby code around this should take >> >>> to >> >>> run. >> >> >> >> You need to be careful about dropping the polling interval too low. I >> >> tried >> >> several values, and this is what seemed to me to be the one that gave >> >> Watir >> >> the best performance. If the polling interval is too long, then you >> >> risk >> >> "wasting" time -- on average you will waste half of the polling >> >> interval on >> >> each wait. >> >> >> >> On the other hand if the polling interval is too short, then the act of >> >> polling itself consumes more CPU, thus slowing down other processes >> >> (including the browser rendering). >> >> >> >> This is really a heisenberg principle. The smaller the polling >> >> interval, the >> >> more accurate the result, but the more the act of measurement has >> >> changed >> >> the thing being measured. >> >> >> >> On the other hand, it has been a long time since I chose the 0.2 >> >> polling >> >> interval. We have newer versions of IE and now typically have more >> >> powerful >> >> machines. I'm open to changing this interval if some one does some >> >> experiments and has a better suggestion. But also note, that my goal >> >> has >> >> been to make Watir as fast as possible, even if that means that the >> >> timings >> >> aren't as accurate as possible. >> >> >> >> Bret >> >> >> >> _______________________________________________ >> >> Wtr-development mailing list >> >> Wtr-development at rubyforge.org >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> >> >> > >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From notethan at gmail.com Thu Oct 15 00:15:49 2009 From: notethan at gmail.com (Ethan) Date: Thu, 15 Oct 2009 00:15:49 -0400 Subject: [Wtr-development] Release 1.6.5rc2? In-Reply-To: References: Message-ID: Can you link to the github fork in question? On Thu, Oct 15, 2009 at 00:13, Bret Pettichord wrote: > > > On Wed, Oct 14, 2009 at 11:06 PM, Angrez Singh wrote: > >> 2. In the future, it makes it easier if each change is in a separate >>> commit. >>> >> Will do that from next time onwards. >> >>> 3. I think i'm fine with close_all and click_no_wait, although i only >>> looked at the code briefly. Do we have tests for these? >>> 4. I'd like to hold off on logon and click_js_popup_button. These appear >>> to be new methods, not in Watir::IE and I'd like to review the method names >>> and signatures, and consider these for 1.7.0. >>> >>> We need click_js_popup_button method to click the buttons on javascript >> alerts. Thats why I added click_no_wait method. Earlier pop up handling was >> different. So I think we should either add all or just close_all method. Yes >> there are unit test cases of each new function. >> > > I think the method for doing this is different in Watir::IE. I'm wondering > if we want to introduce an inconsistency here. > > Bret > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Thu Oct 15 16:39:21 2009 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 15 Oct 2009 22:39:21 +0200 Subject: [Wtr-development] Missing Archives In-Reply-To: References: Message-ID: On Tue, Oct 6, 2009 at 12:06 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > > On Fri, Oct 2, 2009 at 4:38 PM, Bret Pettichord wrote: > > It seems that none of my recent emails to this list are being archived. > > Submitted support request: > http://tinyurl.com/ya9s7af No reply in 9 days, so I posted a message to the forum too: http://tinyurl.com/yhjfbmj ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Thu Oct 15 18:15:16 2009 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 15 Oct 2009 17:15:16 -0500 Subject: [Wtr-development] Missing Archives In-Reply-To: References: Message-ID: Thanks. I'm setting up mail-archive.com to archive this list. This email is a test of it. Bret On Thu, Oct 15, 2009 at 3:39 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Tue, Oct 6, 2009 at 12:06 PM, ?eljko Filipin < > zeljko.filipin at wa-research.ch> wrote: > > > > On Fri, Oct 2, 2009 at 4:38 PM, Bret Pettichord > wrote: > > > It seems that none of my recent emails to this list are being archived. > > > > Submitted support request: > > http://tinyurl.com/ya9s7af > > No reply in 9 days, so I posted a message to the forum too: > > http://tinyurl.com/yhjfbmj > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Thu Oct 1 02:09:53 2009 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 1 Oct 2009 01:09:53 -0500 Subject: [Wtr-development] What I'm Thinking of Doing Message-ID: Over the past year, I tried to start a Watir-based business and failed. In April and May and June I disengaged from Watir, but more recently I've gotten involved with it again. I'm now using it everyday, in my work at Convio. We have a bunch of people using Watir and indeed we've been using something close the latest version in Github. Over the past couple of years, I've had a fair amount of my time funded to work on Watir, but that isn't really true any more. I now have a regular job, much like many of you, where I automate tests for my company's products. When I was trying to launch a Watir-based business, I had a vision of Watir that partly based on what Watir needed to be to sustain that business. Now I'm looking more at what can be done in the limited time I have and what are the things that could be done to Watir that would make it more valuable to Convio and similar companies. Hugh McGowan has built and large Watir/Rasta based framework that is used by the entire QA group at Convio. He's also made a number of private additions to the Watir code base, mostly as monkey patches. We've started to take that code and make it publicly available by pushing it to a public branch on github called convio. There are still a lot of monkey patches that need to be pushed, but we've made a start. http://github.com/bret/watir/commits/convio Indeed, I'm hoping that more people will do the same thing, because I know that there are a lot of people out there who have made private changes and additions to Watir. If others also put them on Github it gives me a better understanding of what kind of changes may be warrented to the core code base. One of the things that I'd really like to do soon is get a new release of Watir out. I was thinking of taking what we have in master and just calling it 1.7.0, but it might even make more sense to call it 1.6.3, because although there are lots of fixes and compatibilty improvements, I'm not so sure that there are really any new features. BTW, we have been using this code base at Convio for over a month (or at least the IE code) without problem. Anyway, I mostly want to release it because I'm seeing more and more people complain about problems on Watir General that are fixed in master (what we used to call trunk). While I was taking a break from Watir and deciding whether it merited my continued involvement, I must say that I got an enormous amount of joy from looking at the Watir network graph on github and seeing all the work that others were doing on Watir. Please take a look at this. http://github.com/bret/watir/network If you haven't seen this before, you need to know that this graph is very wide and you can scroll it by dragging it. If you spend much time looking at this, you'll see there are two major forks developing. The one based on bret/master, that charley and angrez and jari have been merging into, and another that is based on ajcollins/master and is focussed on firefox development with contributions from several others. One of the reasons that I asked to Charley to release what have now is because I think we need to figure out how to merge these two major forks and I fear it will be somewhat destabilizing and take time, and would like to get all the good stuff we have right now out to people. Now back to Convio... I've been very interested to see Hugh's additions (and this is partly why I want to see more of what people are doing). Some of these might be generally useful, although they may need tests and some refinement. Others are clearly specific to our application. At the same time, I'm starting to see the kinds of customizations that people are making to Watir. And even if these are app-specific, there clearly is a need to define supported API's to making these kinds of changes. And also helping people to be able to make customizations that will work with both IE and Firefox. Convio's products used to be very IE centric, but with time they have added more and better support for Firefox. Our tests, mostly just run on IE. It is clear that we need to find a way to get our tests to run with Firefox and that means that (1) need to port the IE-specific features in Watir that we are using to also support Firefox and (2) need to port our own (i.e. Hugh's) IE specific monkey patches to work with Firefox. It seems like a big a job, but also, I'm guessing, something that a lot of other Watir users are facing as well. I see this as a major, but essential challenge for Watir. Critical to Convio, but also critical to other Watir users and critical to our ability to keep Watir as a viable testing platform that will draw contributors. As I've looked at this challenge, it has become clear to me that it is time for me to start working on Watir 2.0. The key thing about Watir 2.0 is that it needs to be easier to customize, customizations need to be able to work with multiple browsers, and we need to make it easier to create Watir implementations for new browsers. At the same time, we need to simplify the Watir API, deprecate obsolete syntax, including syntax that goes back to Watir 1.0. This is also the opportunity for us to fix things we got wrong in Watir 1.x, including doing tables and rows and cells wrong, and a radios wrong, and, finally, going to a zero-based index. In other words, I'm gearing up to rework Watir so that it is simpler, cleaner, easier to understand, easier to customize and easier to port. There will be a lot of issues to hash out, and some potential disruption for people who have old test code that they want to move forward with. For example, I'm thinking that Watir 2.0 should only support hash syntax. Thus: browser.text_field(:id => 'name').set 'Grayson' will continue to work, but browser.text_field(:id, 'name').set 'Grayson' won't. I haven't made up my mind on this, and am eager for feedback, but I want to give you a picture, right now of the kind of disruptions I'm anticipating for Watir 2.0. But wait! That's not all. I've been building a lot of frameworks with Watir and there is a short list of features that we could add to Watir that would make it much easier to build frameworks on. Here's the list: 1. Display Value - there should be a single message that you use to get the visible value of an element. http://github.com/bret/watircraft/blob/master/lib/extensions/watir.rb 2. Match - Provide a simple, standard syntax for validating the display values of elements. (I have the details worked out in my head, but it's late, so I'll write them up another day.) So, before Watir 2.0, I see another release that would include these features. Maybe this would be Watir 1.8. I'm not sure if this would be before or after the merge with the ajcollins branch. I think the changes are orthogonal. Anyway, that is what I'm thinking of doing. -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Thu Oct 1 03:28:37 2009 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 1 Oct 2009 09:28:37 +0200 Subject: [Wtr-development] Policy on Watir Additions In-Reply-To: References: Message-ID: On Thu, Oct 1, 2009 at 3:08 AM, Bret Pettichord wrote: > In other words, github IS contrib. Sounds good to me. ?eljko -- http://watirpodcast.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Thu Oct 1 03:58:59 2009 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 1 Oct 2009 09:58:59 +0200 Subject: [Wtr-development] What I'm Thinking of Doing In-Reply-To: References: Message-ID: Bret, this would be a great blog post. Comments inline. On Thu, Oct 1, 2009 at 8:09 AM, Bret Pettichord wrote: > I was thinking of taking what we have in master and just > calling it 1.7.0, but it might even make more sense to call it 1.6.3 Both numbers sound good to me. After all, they are just numbers. > http://github.com/bret/watir/network The graph is impressive. > At the same time, we need to simplify the Watir API, deprecate > obsolete syntax, including syntax that goes back to Watir 1.0. This is > also the opportunity for us to fix things we got wrong in Watir 1.x, > including doing tables and rows and cells wrong, and a radios wrong, > and, finally, going to a zero-based index. +1 > Thus: > browser.text_field(:id => 'name').set 'Grayson' > will continue to work, but > browser.text_field(:id, 'name').set 'Grayson' > won't. +1 I think that will be a few minutes of work for me to fix my tests for Watir 2.0 > 1. Display Value - there should be a single message that you use to > get the visible value of an element. > 2. Match - Provide a simple, standard syntax for validating the > display values of elements. Sounds great. I wish I had some time to work on Watir code. The time ahead sounds very interesting. Bret (and other Watir developers), I have a few questions: 1) If I had some time to work on Watir code (like if my company said I could spend a few hours a week on Watir), would anybody be interested in training me (or other interested candidates) as a apprentice, something like Google summer of code? Fix a bug here and there, write a test... 2) Is there any documentation (wiki, blog posts...) that could help me understand how to fix/change/develop Watir code? Watir architecture, ole objects and stuff like that. If not, would anybody be interested in writing something? 3) I have been thinking for a long time about this, maybe now is the time to ask. Will there be AWTA 2010? Or similar gathering of Watir community? Schedule? Something like this: morning consists of lectures on how different browsers work, how Watir code is structured, afternoon consist of pair programming (fixing bugs, implementing features...). ?eljko -- http://watirpodcast.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.rogers at shaw.ca Thu Oct 1 10:24:29 2009 From: paul.rogers at shaw.ca (Paul Rogers) Date: Thu, 1 Oct 2009 08:24:29 -0600 Subject: [Wtr-development] jQuery support / experience report with Windmill In-Reply-To: References: <970956b0909301453m52f6de56ha7c65a61c3bfad7c@mail.gmail.com> Message-ID: nicely put! I guess ideas are easy, step 2 is harder, and 5 even harder too. Wish I had a bit more time to help out. Paul On Wed, Sep 30, 2009 at 9:52 PM, Bret Pettichord wrote: > So here is how i think development of watir features ... develops. > > 1. Somebody has an idea > 2. Somebody creates an implementation > 3. Somebody adds the code to a fork on github > 4. Somebody adds some tests > 5. Somebody makes sure the feature works with both IE and Firefox > 6. Somebody makes the case that the feature should be added to the official > release > 7. We pull it in. > > I see Jeff right now at step 1, trying to get to step 2. Paul is saying it > might be hard to get to step 5 and therefore step 7 (which I guess I agree > with). > > But i would really like to see more people doing 2 and 3 first and then we > can discuss whether it might go all the way to step 7. > > Bret > > > On Wed, Sep 30, 2009 at 10:17 PM, Paul Rogers wrote: > >> I would suggest that using jquery doesnt make a very testable >> application. The code below is neither readable, nor likely to survive any >> minor reorganization of the users html. If you're serious about testability >> add ids. >> >> But saying that, I do agree that jquery selectors would help in some >> cases. >> >> Im not entirely sure that we would ever be able to be truly browser >> agnostic, but a goal we should definitely strive for. See Brets post >> regarding the element/elements that dont work in firefox. >> >> Paul >> >> >> On Wed, Sep 30, 2009 at 3:53 PM, Jeff Fry wrote: >> >>> Re: not adding features that are browser specific to the core of watir: I >>> like the idea a lot. Getting to be *really really* browser agnostic is going >>> to be important for watir. >>> >>> On a relatedish note: I've recently been using http://getwindmill.com for >>> browser-based test automation, and it has what for me has really turned into >>> a killer feature. Backing up a second, the shop I'm at now is VERY python >>> focused, and in order to get devs to look at, let alone write, test scripts >>> means having them written in python. Based on this requirement, plus the >>> need to handle an AJAX-heavy site, I came across Windmill, which was started >>> by some Se devs who started their own project to support very AJAX-y apps. >>> >>> I started evaluating it, but was frustrated with their API, which is >>> *much* less expressive than the watir API. Their/python's xpath >>> implementation is pretty zippy, but for most everything I was working on, I >>> ended up needing to fall back on xpath selectors, and I was NOT enjoying my >>> xpath learning curve. >>> >>> Anyway, just as I was thinking I might not be able to live with their >>> API, they added support for using jQuery in selectors. I hadn't ever used >>> jQuery before, but it's super easy to learn, incredibly powerful, and is >>> really just harnessing the power (&syntax) of CSS. In many ways, it feels >>> like the natural progression of Bret's rail against vendorscripts...an API >>> that's not unique to one tool, but can be implemented by any tool, and is in >>> use by a rapidly growing group of web developers. More importantly, over one >>> weekend, Windmill went from a frustratingly primitive API to one that is >>> more powerful than (though not necessarily as elegant as) the Watir API. >>> >>> Some examples would be handy right about now: >>> >>> Select based on a regex of a custom attibute's value >>> >>> #like it or not, we use /many/ custom attributes. jQuery can select by any of them. >>> >>> c.click(jquery=u'("a.prop-edit-button[fb__href*=\'%s\']")[0]' % property) >>> >>> Using *:last* to get the final of several nodes >>> >>> c.type(jquery=u'("input.prop-table-edit-thead-primary[fb__pid=\'%s\']:last")[0]' % property, text=value) >>> >>> Of several nodes of a given class, select the *:visible* one >>> >>> self.type(text=topic_name, jquery=u'("input.adddatameta-input:visible")[0]') >>> >>> Select one node, then go to a child of it >>> >>> #find the last form with class foo. within it, find a button that matches regex bar. >>> >>> self.click(jquery=u'("form.add-data-form:last button[name=\'add\']")[0]') >>> >>> #find a div whose fb__pid matches foo. Within it go to a node of any type with classes .bar and .baz. >>> >>> c.click(jquery=u'("div[fb__pid*=\'%s\'] .prop-edit-menu-title.popup-trigger")[0]' % property) >>> >>> #is the "Import list" link now visible? >>> >>> c.asserts.assertNode(jquery=u'("div[fb__pid*=\'%s\'] .import-link:visible")[0]' % property) >>> >>> #within a div that matches foo, click on a node with class .bar >>> >>> c.click(jquery=u'("div[fb__pid*=\'%s\'] .import-link")[0]' % property) >>> >>> Now, for the things like this that watir can do, watir typically does >>> them more elegantly. But there are other things (like selecting based on >>> custom attributes) that jQuery support makes very powerful. The whole jQuery >>> selector library is pretty straightforward to learn, and quite well >>> documented http://docs.jquery. >>> com/Selectors >>> >>> By the way, one of the things web devs like about jquery is that it's >>> very sandboxable. That allows Windmill to instantiate jquery themselves, and >>> so their selectors work exactly the same whether or not the site under test >>> uses jquery in the page, and don't materially change the AUT. (As a tester >>> I'll note that these are bold assertions, but that the data I've seen so far >>> has been quite encouraging.) >>> >>> At this point, having used it for a while, I think jQuery support is a >>> huge deal. It certainly is on our site, which (for understandable reasons) >>> often has many similar nodes that are only distinguishable based on a custom >>> attribute, a distinguishing parent or sibling node, or etc. >>> >>> The Windmill source is at github.com/windmill/windmill and jQuery >>> support is only in the v1.3 beta now. I'm not sure how relevant the >>> implementation in Windmill would be to the implementation in Watir...but I >>> include the link in case it's helpful, and in case someone is interested in >>> taking a whack at it. >>> >>> I'm happy to chat more about this, on or off list. >>> >>> Hope all's well with y'all, >>> >>> -- >>> Jeff Fry >>> >>> http://testingjeff.wordpress.com >>> http://associationforsoftwaretesting.org >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Fri Oct 2 10:38:20 2009 From: bret at pettichord.com (Bret Pettichord) Date: Fri, 2 Oct 2009 09:38:20 -0500 Subject: [Wtr-development] Missing Archives Message-ID: It seems that none of my recent emails to this list are being archived. Indeed the recent jquery-thread with me and paul and jeff is missing as well. But other stuff is in. Would some one be willing to volunteer to work with the folks at rubyforge to figure out what is happening? I don't have any idea about what is going on. Bret -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Fri Oct 2 10:46:29 2009 From: bret at pettichord.com (Bret Pettichord) Date: Fri, 2 Oct 2009 09:46:29 -0500 Subject: [Wtr-development] Next release Message-ID: Charley, How are things going with the next Watir release? Bret -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From charley.baker at gmail.com Fri Oct 2 14:00:06 2009 From: charley.baker at gmail.com (Charley Baker) Date: Fri, 2 Oct 2009 12:00:06 -0600 Subject: [Wtr-development] Next release In-Reply-To: References: Message-ID: Going well, I just checked in the updated change list, running the tests now. Wondering if we should use this rubygems feature (1.3.2+) for the versioning? * Gem::Version now understands prerelease versions using letters. (eg. '1.2.1.b') Could call this 1.6.3.b or 1.6.3.rc1 before releasing the final version (version number dependent on your previous comment about possibly just calling this 1.6.3 instead of 1.7.0). -c On Fri, Oct 2, 2009 at 8:46 AM, Bret Pettichord wrote: > Charley, > > How are things going with the next Watir release? > > Bret > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Sun Oct 4 22:27:07 2009 From: bret at pettichord.com (Bret Pettichord) Date: Sun, 4 Oct 2009 21:27:07 -0500 Subject: [Wtr-development] What I'm Thinking of Doing In-Reply-To: References: Message-ID: On Thu, Oct 1, 2009 at 2:58 AM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > Bret, this would be a great blog post. I was going to post a link to it, but it didn't make into the archive. Does some one want to track down why? 1) If I had some time to work on Watir code (like if my company said I could > spend a few hours a week on Watir), would anybody be interested in training > me (or other interested candidates) as a apprentice, something like Google > summer of code? Fix a bug here and there, write a test... > > 2) Is there any documentation (wiki, blog posts...) that could help me > understand how to fix/change/develop Watir code? Watir architecture, ole > objects and stuff like that. If not, would anybody be interested in writing > something? > I would recommended looking at the code and the unit tests and looking at the changes that developers are making and see if you can understand what they are changing and why. I was going to suggest that you ask questions here and our answers could help with the understanding, but not having them archived makes this not so good an idea. If you want to understand OLE, there are lots of source of information on that. I learned a lot about OLE from reading a book called understanding ActiveX and OLE by David Chappell years ago. I'm sure there are lots of other sources of information about it as well. I've been thinking of trying help some of our staff at Convio to understand this kind of thing, but it is a lot easier to coach people you see everyday. When I was running WatirCraft, I had a GoToMeeting account, which provided a handy way to screenshare remotely, but I had to shut down my account because of the cost. I think it is $25 or $50 a month. Also, as I said before, I don't really have a lot of time to devote to this kind of thing any more, so am reluctant to make commitments. The best thing to do, really, is to pick an issue that means something to you and then start working on it. This is what you did with the bug you fixed several months ago. Maybe you want to look through Jira? Actually, that reminds me. We've been negligent in responding to some of the newer reports in Jira. Maybe you want to look at them and see if they really are bugs or what? > 3) I have been thinking for a long time about this, maybe now is the time > to ask. Will there be AWTA 2010? Or similar gathering of Watir community? > Schedule? Something like this: morning consists of lectures on how different > browsers work, how Watir code is structured, afternoon consist of pair > programming (fixing bugs, implementing features...). > Good question. I've been thinking about it. Right now I'm leaning towards doing something like this. Usually I decide in October or early November. -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Sun Oct 4 22:27:57 2009 From: bret at pettichord.com (Bret Pettichord) Date: Sun, 4 Oct 2009 21:27:57 -0500 Subject: [Wtr-development] Next release In-Reply-To: References: Message-ID: Charley and me talked. We're going to call it 1.6.5, and charley's working on RC1. On Fri, Oct 2, 2009 at 1:00 PM, Charley Baker wrote: > Going well, I just checked in the updated change list, running the tests > now. Wondering if we should use this rubygems feature (1.3.2+) for the > versioning? > > * Gem::Version now understands prerelease versions using letters. (eg. > > '1.2.1.b') > > > Could call this 1.6.3.b or 1.6.3.rc1 before releasing the final version > (version number dependent on your previous comment about possibly just > calling this 1.6.3 instead of 1.7.0). > > -c > > > On Fri, Oct 2, 2009 at 8:46 AM, Bret Pettichord wrote: > >> Charley, >> >> How are things going with the next Watir release? >> >> Bret >> >> -- >> Bret Pettichord >> Lead Developer, Watir, www.watir.com >> >> Blog, www.io.com/~wazmo/blog >> Twitter, www.twitter.com/bpettichord >> >> > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Mon Oct 5 01:16:26 2009 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 5 Oct 2009 00:16:26 -0500 Subject: [Wtr-development] Policy on Watir Additions In-Reply-To: <2a379a300909302050o542fc75co3a3a7d3180aecb88@mail.gmail.com> References: <2a379a300909302050o542fc75co3a3a7d3180aecb88@mail.gmail.com> Message-ID: On Wed, Sep 30, 2009 at 10:50 PM, Alan Baird wrote: > It sounds just fine to me in theory. Ideally all of the Watir features > should "just work" across both and I don't think we shouldn't try. > However, the unintended side affect might be you get less contributions if > all contributions have to be cross platform. Most of our code that we would > consider contributing are things we have already coded and want to > contribute to the community. However, since Firefox isn't required by our > customers, we don't have any reason to code tests for it, and I don't think > our shop is the only one that's like this. > One option would be to collect IE-specific additions to watir into a separate gem. That way people could use it if they wanted to. At the same time, people who were trying to write scripts that would work with multiple browsers wouldn't install it and wouldn't have to worry about portability. What are people's thoughts about this? > I think another problem might be that people aren't as familiar with the > way that FireWatir works as opposed to Watir (I know that's my problem). > Are there any resources out there that explain more about this? Maybe I > can collect some links or write up a Wiki article on this. > Firewatir uses javascript to control the browser. Because Javascript is so well documented, it is actually easier to understand than Watir. Since you and Zeljko are both interested in learning about this stuff, and so are a couple of my collegues at Convio, maybe it makes sense for me to host an architecture overview of Watir. I am also thinking about maybe charging a fee for this. I am also thinking out loud here. Please let me know if you might be interested to participate. -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Mon Oct 5 17:32:55 2009 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 5 Oct 2009 23:32:55 +0200 Subject: [Wtr-development] Policy on Watir Additions In-Reply-To: References: <2a379a300909302050o542fc75co3a3a7d3180aecb88@mail.gmail.com> Message-ID: On Mon, Oct 5, 2009 at 7:16 AM, Bret Pettichord wrote: > One option would be to collect IE-specific additions to watir into a separate gem. +1 > Since you and Zeljko are both interested in learning about this stuff, and so are a couple of my collegues at Convio, maybe it makes sense for me to host an architecture overview of Watir. I am also thinking about maybe charging a fee for this. I am very interested, but it is not easy for me to fly to Austin. I could do that only if my company pays for it (and they probably would). Would they pay for Watir training too? I do not know. It would be better for me personally if you could record the training. Or if the training was on-line (video chat and/or screen sharing). Or write a blog post, article, book... It would probably be more affordable for me to pay for something like that. Even better, I could probably get my company to pay for it. The only reason why I want to learn more about Watir is to be able to contribute. Of course, and to _just_ learn something new. I am aware of the fact that you do not have any short-term benefit from creating architecture overview of Watir for free, and it would probably be a lot of work. I would be glad to pay for the training, but my ability to do so is limited at the moment. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Mon Oct 5 17:41:31 2009 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 5 Oct 2009 23:41:31 +0200 Subject: [Wtr-development] Missing Archives In-Reply-To: References: Message-ID: On Fri, Oct 2, 2009 at 4:38 PM, Bret Pettichord wrote: > Would some one be willing to volunteer to work with the folks at rubyforge to figure out what is happening? If nobody beats me, I will try to do it tomorrow. ?eljko -- http://watirpodcast.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Mon Oct 5 18:16:57 2009 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 6 Oct 2009 00:16:57 +0200 Subject: [Wtr-development] What I'm Thinking of Doing In-Reply-To: References: Message-ID: On Mon, Oct 5, 2009 at 4:27 AM, Bret Pettichord wrote: > I would recommended looking at the code and the unit tests and looking at the changes that developers are making and see if you can understand what they are changing and why. Sure, I have already done that, and it is a great way to learn your way around. It is great for learning new stuff, but it is slow. When I solve a problem, and see that it is not documented, I usually document it. That makes the process even slower. I am thinking about the optimal time/benefit ratio. If the objective is to learn new stuff, poking around is the best way. If we want to make it easy for people to contribute code to Watir, maybe we should produce some documentation on how to do it. Maybe there should be a threshold. If you can not manage to find your way around Watir code yourself, we do not want your code anyway. :) > I was going to suggest that you ask questions here and our answers could help with the understanding, but not having them archived makes this not so good an idea. Asking questions here is also a good idea. I will try to contact rubyforge tomorrow and see what is the problem. > If you want to understand OLE, there are lots of source of information on that. I learned a lot about OLE from reading a book called understanding ActiveX and OLE by David Chappell years ago. I'm sure there are lots of other sources of information about it as well. I will try to get the book. If anybody knows about web pages/sites that talk about it, that would be great too. > I've been thinking of trying help some of our staff at Convio to understand this kind of thing, but it is a lot easier to coach people you see everyday. When I was running WatirCraft, I had a GoToMeeting account, which provided a handy way to screenshare remotely, but I had to shut down my account because of the cost. I think it is $25 or $50 a month. $49/month. When I collaborate with my developer we usually use iChat or Skype screen sharing. iChat even has a feature that the other person can control your machine. > Also, as I said before, I don't really have a lot of time to devote to this kind of thing any more, so am reluctant to make commitments. I am aware of the fact that almost everybody on this list has very limited time to work on Watir. Including myself. I am writing this after midnight. > The best thing to do, really, is to pick an issue that means something to you and then start working on it. This is what you did with the bug you fixed several months ago. Maybe you want to look through Jira? My coding back then was more an exercise in Git and Github than Watir. Now that I am familiar with the tools maybe I should really just pick up something. I was thinking big. Run Watir tests on SafariWatir and try to fix them. Or even try to merge SafariWatir and Watir. > We've been negligent in responding to some of the newer reports in Jira. Maybe you want to look at them and see if they really are bugs or what? I will take a look and see if there is anything interesting. > I've been thinking about it. Right now I'm leaning towards doing something like this. Usually I decide in October or early November. I am looking forward to that. I hope you decide to host AWTA. (And I hope I will be able to come.) AWTA 2009 was more focused on WatirCraft and bussines around Watir, and that was not really my game. If the next year there is more coding and less beer, that would be great. No, wait, did I say less beer? Forget that. Crazy talk. :) ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Mon Oct 5 20:41:17 2009 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 5 Oct 2009 19:41:17 -0500 Subject: [Wtr-development] Policy on Watir Additions In-Reply-To: References: <2a379a300909302050o542fc75co3a3a7d3180aecb88@mail.gmail.com> Message-ID: I've been thinking about doing this kind of class both face-to-face and online. GotoMeeting might work well for this kind of thing and has the side benefit of being able to record it. Bret On Mon, Oct 5, 2009 at 4:32 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > > Since you and Zeljko are both interested in learning about this stuff, > and so are a couple of my collegues at Convio, maybe it makes sense for me > to host an architecture overview of Watir. I am also thinking about maybe > charging a fee for this. > > I am very interested, but it is not easy for me to fly to Austin. I could > do that only if my company pays for it (and they probably would). Would they > pay for Watir training too? I do not know. > > It would be better for me personally if you could record the training. Or > if the training was on-line (video chat and/or screen sharing). Or write a > blog post, article, book... It would probably be more affordable for me to > pay for something like that. Even better, I could probably get my company to > pay for it. > > The only reason why I want to learn more about Watir is to be able to > contribute. Of course, and to _just_ learn something new. I am aware of the > fact that you do not have any short-term benefit from creating architecture > overview of Watir for free, and it would probably be a lot of work. I would > be glad to pay for the training, but my ability to do so is limited at the > moment. > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Mon Oct 5 20:43:15 2009 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 5 Oct 2009 19:43:15 -0500 Subject: [Wtr-development] Missing Archives In-Reply-To: References: Message-ID: That would be great. BTW, one of the things that motivates me to consider doing some training for your benefit, is the way that you are eager to jump in and help with things like this. E.g. creating the redirects for watir.com . Bret On Mon, Oct 5, 2009 at 4:41 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Fri, Oct 2, 2009 at 4:38 PM, Bret Pettichord > wrote: > > Would some one be willing to volunteer to work with the folks at > rubyforge to figure out what is happening? > > If nobody beats me, I will try to do it tomorrow. > > ?eljko > -- > http://watirpodcast.com/ > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-developmen > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Mon Oct 5 21:02:08 2009 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 5 Oct 2009 20:02:08 -0500 Subject: [Wtr-development] What I'm Thinking of Doing In-Reply-To: References: Message-ID: On Mon, Oct 5, 2009 at 5:16 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Mon, Oct 5, 2009 at 4:27 AM, Bret Pettichord > wrote: > > I would recommended looking at the code and the unit tests and looking at > the changes that developers are making and see if you can understand what > they are changing and why. > > Sure, I have already done that, and it is a great way to learn your way > around. It is great for learning new stuff, but it is slow. > I agree. The best way to learn is to pair. When I solve a problem, and see that it is not documented, I usually > document it. That makes the process even slower. > > I am thinking about the optimal time/benefit ratio. If the objective is to > learn new stuff, poking around is the best way. If we want to make it easy > for people to contribute code to Watir, maybe we should produce some > documentation on how to do it. > Just to be clear, in general I am not worried about recruiting people to help contribute to Watir. And, as i detailed in the head of this conversation, what I most want to do is restructure Watir to make it easier for people to extend it, whether for their own purposes, or for the benefit of all. One of the reasons that I don't spend a lot of time documenting stuff with Watir, is that once I've figured out what people want to know and what kinds of things they are trying to do, it usually easier for me to restructure Watir to make it easier for them than it is to document for them how to better understand the soon-to-be-obsolete structure of the code. Maybe there should be a threshold. If you can not manage to find your way > around Watir code yourself, we do not want your code anyway. :) Actually the best strategy I can think of for getting more people to hack on Watir code is to reduce the distance between the IE/Windows code and Firefox/Linux/Mac code. Because there are a lot more potential contributors -- people who can understand Ruby, Watir, etc -- on the more open platform. > I was going to suggest that you ask questions here and our answers could help with the understanding, but not having them archived makes this not so good an idea. Asking questions here is also a good idea. I will try to contact rubyforge > tomorrow and see what is the problem. Thanks. > If you want to understand OLE, there are lots of source of information on that. I learned a lot about OLE from reading a book called understanding ActiveX and OLE by David Chappell years ago. I'm sure there are lots of other sources of information about it as well. I will try to get the book. If anybody knows about web pages/sites that talk > about it, that would be great too. It was just a book I picked up at a used bookstore ages ago. > I've been thinking of trying help some of our staff at Convio to understand this kind of thing, but it is a lot easier to coach people you see everyday. When I was running WatirCraft, I had a GoToMeeting account, which provided a handy way to screenshare remotely, but I had to shut down my account because of the cost. I think it is $25 or $50 a month. $49/month. > > When I collaborate with my developer we usually use iChat or Skype screen > sharing. iChat even has a feature that the other person can control your > machine. GotoMeeting works well for groups. It is very easy to set up. I have used other, cheaper tools, but they generally feasible for me only if I am one-on-one remote. To me this is like deciding whether to teach in a nice class room, or some spare room somewhere that you can get for cheap. Because my time is limited, i would like to use a tool that is proven and would not require me to spend fiddle-time on. This is why I said i would have to charge for it. > Also, as I said before, I don't really have a lot of time to devote to this kind of thing any more, so am reluctant to make commitments. I am aware of the fact that almost everybody on this list has very limited > time to work on Watir. Including myself. I am writing this after midnight. > > > The best thing to do, really, is to pick an issue that means something to > you and then start working on it. This is what you did with the bug you > fixed several months ago. Maybe you want to look through Jira? > > My coding back then was more an exercise in Git and Github than Watir. Now > that I am familiar with the tools maybe I should really just pick up > something. > > I was thinking big. Run Watir tests on SafariWatir and try to fix them. Or > even try to merge SafariWatir and Watir. That sounds fine. Part of my plan right now is to better integrate IEWatir and FireWatir so that it will be easier to make things like SafariWatir work. > We've been negligent in responding to some of the newer reports in Jira. Maybe you want to look at them and see if they really are bugs or what? I will take a look and see if there is anything interesting. > > > I've been thinking about it. Right now I'm leaning towards doing > something like this. Usually I decide in October or early November. > > I am looking forward to that. I hope you decide to host AWTA. (And I hope I > will be able to come.) AWTA 2009 was more focused on WatirCraft and bussines > around Watir, and that was not really my game. If the next year there is > more coding and less beer, that would be great. No, wait, did I say less > beer? Forget that. Crazy talk. :) > One of things you need to understand is that this is not the place to find encouragement to work on Watir. That is the responsibility of the users, not the developers. This is the place to get help and direction if you have already decided that you want to contribute to Watir. Bret -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From abaird at bairdsnet.net Tue Oct 6 01:40:41 2009 From: abaird at bairdsnet.net (Alan Baird) Date: Tue, 6 Oct 2009 00:40:41 -0500 Subject: [Wtr-development] fix WTR-324 in 1.6.5? Message-ID: <2a379a300910052240j663f37daj3063f40b8491f510@mail.gmail.com> All - I put in a ticket for the longstanding issue of Watir::Table.each throwing a WIN32OLERuntimeError when itterating over nested tables ( http://jira.openqa.org/browse/WTR-324). I have attached a fix for the issue to the ticket (1 line fix). Sorry the test isn't nicer, but it's not a complex issue. Although this issue has been around for a while, I think it would be great if we could include it in the upcoming release. Please? :) Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Tue Oct 6 04:29:29 2009 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 6 Oct 2009 10:29:29 +0200 Subject: [Wtr-development] Missing Archives In-Reply-To: References: Message-ID: On Tue, Oct 6, 2009 at 2:43 AM, Bret Pettichord wrote: > BTW, one of the things that motivates me to consider doing some training for your benefit, is the way that you are eager to jump in and help with things like this. E.g. creating the redirects for watir.com. Before doing redirects for watir.com, I did not know how to do it. I did a bit of research (Google, Wikipedia and internet in the whole just rule) and now I know a bit about .htaccess files. Just enough to redirect what I needed. With this Rubyforge problem, I do not know even where to start, so it looks like it would be an interesting journey. I like the feeling of being completely lost, and then step by step finding my way. :) ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Tue Oct 6 06:06:02 2009 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 6 Oct 2009 12:06:02 +0200 Subject: [Wtr-development] Missing Archives In-Reply-To: References: Message-ID: On Fri, Oct 2, 2009 at 4:38 PM, Bret Pettichord wrote: > It seems that none of my recent emails to this list are being archived. Submitted support request: http://tinyurl.com/ya9s7af ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Tue Oct 6 15:03:47 2009 From: bret at pettichord.com (Bret Pettichord) Date: Tue, 6 Oct 2009 14:03:47 -0500 Subject: [Wtr-development] fix WTR-324 in 1.6.5? In-Reply-To: <2a379a300910052240j663f37daj3063f40b8491f510@mail.gmail.com> References: <2a379a300910052240j663f37daj3063f40b8491f510@mail.gmail.com> Message-ID: Does someone want to look into checking this into git? Zeljko? Bret On Tue, Oct 6, 2009 at 12:40 AM, Alan Baird wrote: > All - > I put in a ticket for the longstanding issue of Watir::Table.each throwing > a WIN32OLERuntimeError when itterating over nested tables ( > http://jira.openqa.org/browse/WTR-324). I have attached a fix for the > issue to the ticket (1 line fix). Sorry the test isn't nicer, but it's not > a complex issue. > > Although this issue has been around for a while, I think it would be great > if we could include it in the upcoming release. > > Please? :) > Alan > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From charley.baker at gmail.com Tue Oct 6 15:18:23 2009 From: charley.baker at gmail.com (Charley Baker) Date: Tue, 6 Oct 2009 13:18:23 -0600 Subject: [Wtr-development] fix WTR-324 in 1.6.5? In-Reply-To: References: <2a379a300910052240j663f37daj3063f40b8491f510@mail.gmail.com> Message-ID: Zeljko, you want to roll this in so it gets included in the final 1.6.5? -c On Tue, Oct 6, 2009 at 1:03 PM, Bret Pettichord wrote: > Does someone want to look into checking this into git? Zeljko? > > Bret > > On Tue, Oct 6, 2009 at 12:40 AM, Alan Baird wrote: > >> All - >> I put in a ticket for the longstanding issue of Watir::Table.each throwing >> a WIN32OLERuntimeError when itterating over nested tables ( >> http://jira.openqa.org/browse/WTR-324). I have attached a fix for the >> issue to the ticket (1 line fix). Sorry the test isn't nicer, but it's not >> a complex issue. >> >> Although this issue has been around for a while, I think it would be great >> if we could include it in the upcoming release. >> >> Please? :) >> Alan >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aidy.lewis at googlemail.com Wed Oct 7 05:53:32 2009 From: aidy.lewis at googlemail.com (aidy lewis) Date: Wed, 7 Oct 2009 10:53:32 +0100 Subject: [Wtr-development] Using JSSH to automate Firefox preference Message-ID: <7ac2300c0910070253q4381d5aau2e5fd2a6a1923d51@mail.gmail.com> Hi, A developer at our work has used JSSH to automate Firefox preferences including downloads and NTLM settings. Where abouts in the Watir/Firewatir folder structure should this be committed? Aidy From angrez at gmail.com Wed Oct 7 06:25:55 2009 From: angrez at gmail.com (Angrez Singh) Date: Wed, 7 Oct 2009 15:55:55 +0530 Subject: [Wtr-development] Using JSSH to automate Firefox preference In-Reply-To: <7ac2300c0910070253q4381d5aau2e5fd2a6a1923d51@mail.gmail.com> References: <7ac2300c0910070253q4381d5aau2e5fd2a6a1923d51@mail.gmail.com> Message-ID: Wow .. thats interesting .. can you share the code? It might be useful in handling pop ups also. On Wed, Oct 7, 2009 at 3:23 PM, aidy lewis wrote: > Hi, > > A developer at our work has used JSSH to automate Firefox preferences > including downloads and NTLM settings. > > Where abouts in the Watir/Firewatir folder structure should this be > committed? > > Aidy > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Wed Oct 7 06:30:08 2009 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 7 Oct 2009 12:30:08 +0200 Subject: [Wtr-development] fix WTR-324 in 1.6.5? In-Reply-To: References: <2a379a300910052240j663f37daj3063f40b8491f510@mail.gmail.com> Message-ID: Alan, you have github account, why don't you fork bret/watir, commit your change and send pull request. Please let me know if you need help with that. I will do it tonight if Alan does not do it first. ?eljko -- http://watirpodcast.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aidy.lewis at googlemail.com Wed Oct 7 09:06:10 2009 From: aidy.lewis at googlemail.com (aidy lewis) Date: Wed, 7 Oct 2009 14:06:10 +0100 Subject: [Wtr-development] Using JSSH to automate Firefox preference In-Reply-To: References: <7ac2300c0910070253q4381d5aau2e5fd2a6a1923d51@mail.gmail.com> Message-ID: <7ac2300c0910070606o65165c0cj704bb8f553a25d2d@mail.gmail.com> Hi Angrez, The developer will be in touch with you off-line. Aidy 2009/10/7 Angrez Singh : > Wow .. thats interesting .. can you share the code? It might be useful in > handling pop ups also. > > On Wed, Oct 7, 2009 at 3:23 PM, aidy lewis > wrote: >> >> ?Hi, >> >> ?A developer at our work has used JSSH to automate Firefox preferences >> including downloads and NTLM settings. >> >> ?Where abouts in the Watir/Firewatir folder structure should this be >> committed? >> >> ?Aidy >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From bret at pettichord.com Thu Oct 8 00:20:41 2009 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 7 Oct 2009 23:20:41 -0500 Subject: [Wtr-development] dev status: one error (utf8/firefox) Message-ID: i'm excited by this release. i jumped in and pulled in several fixes today. built the gems (after "gem update --system" and "gem install hoe"). i ran the ie tests, which look good. i ran the ff tests, and had one problem that i have not researched: 1) Failure: test_is_correct_encoding(TC_Utf8) [C:/work/watir/commonwatir/unittests/utf8_test .rb:16]: <"\303\246\303\270\303\245"> expected but was <"\346\370\345">. is this something we need to fix? bret -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Thu Oct 8 00:32:39 2009 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 7 Oct 2009 23:32:39 -0500 Subject: [Wtr-development] pull request autoresponder Message-ID: I just set up the following autoresponder to pull requests to bret/master: Thank you for contributing to the Watir project. We are always eager to see bug fixes and improvements to the compatibility between (IE)Watir and FireWatir and other Watir implementations. We are slow to add new features, and will consider doing so only when (1) they have unit tests and (2) they have been implemented for both (IE)Watir and FireWatir. The bret/master repository is currently being maintained by charley, jarib, angrez and bret. Please send your pull request to all of us. -- The Core Watir Development Team I hope you like it because github doesn't let you edit it. (You have to delete it and then recreate it.) Bret -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From jari.bakken at gmail.com Thu Oct 8 03:22:34 2009 From: jari.bakken at gmail.com (Jari Bakken) Date: Thu, 8 Oct 2009 09:22:34 +0200 Subject: [Wtr-development] dev status: one error (utf8/firefox) In-Reply-To: References: Message-ID: On Thu, Oct 8, 2009 at 6:20 AM, Bret Pettichord wrote: > ? 1) Failure: > test_is_correct_encoding(TC_Utf8) > [C:/work/watir/commonwatir/unittests/utf8_test > .rb:16]: > <"\303\246\303\270\303\245"> expected but was > <"\346\370\345">. > That's weird. It's passing for me on both Watir on Windows and FireWatir on Windows + OS X. From charley.baker at gmail.com Thu Oct 8 10:32:45 2009 From: charley.baker at gmail.com (Charley Baker) Date: Thu, 8 Oct 2009 08:32:45 -0600 Subject: [Wtr-development] dev status: one error (utf8/firefox) In-Reply-To: References: Message-ID: Working for me as well in both FF and IE on WinXP. -c On Thu, Oct 8, 2009 at 1:22 AM, Jari Bakken wrote: > On Thu, Oct 8, 2009 at 6:20 AM, Bret Pettichord > wrote: > > 1) Failure: > > test_is_correct_encoding(TC_Utf8) > > [C:/work/watir/commonwatir/unittests/utf8_test > > .rb:16]: > > <"\303\246\303\270\303\245"> expected but was > > <"\346\370\345">. > > > > That's weird. It's passing for me on both Watir on Windows and > FireWatir on Windows + OS X. > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Thu Oct 8 10:55:39 2009 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 8 Oct 2009 09:55:39 -0500 Subject: [Wtr-development] dev status: one error (utf8/firefox) In-Reply-To: References: Message-ID: I was running this on WinXP. I will try to run it on my other WinXP machine. I may have been using an old version of Firefox. Bret On Thu, Oct 8, 2009 at 9:32 AM, Charley Baker wrote: > Working for me as well in both FF and IE on WinXP. > > -c > > > > On Thu, Oct 8, 2009 at 1:22 AM, Jari Bakken wrote: > >> On Thu, Oct 8, 2009 at 6:20 AM, Bret Pettichord >> wrote: >> > 1) Failure: >> > test_is_correct_encoding(TC_Utf8) >> > [C:/work/watir/commonwatir/unittests/utf8_test >> > .rb:16]: >> > <"\303\246\303\270\303\245"> expected but was >> > <"\346\370\345">. >> > >> >> That's weird. It's passing for me on both Watir on Windows and >> FireWatir on Windows + OS X. >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From abaird at bairdsnet.net Thu Oct 8 19:22:44 2009 From: abaird at bairdsnet.net (Alan Baird) Date: Thu, 8 Oct 2009 18:22:44 -0500 Subject: [Wtr-development] fix WTR-324 in 1.6.5? In-Reply-To: References: <2a379a300910052240j663f37daj3063f40b8491f510@mail.gmail.com> Message-ID: <2a379a300910081622rf0442ecg8024105c4072f8c0@mail.gmail.com> Ok, I'll try to do that tonight. I'm still a Git noob but I should be able to pull it together. Alan On Wed, Oct 7, 2009 at 5:30 AM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > Alan, > > you have github account, why don't you fork bret/watir, commit your change > and send pull request. Please let me know if you need help with that. > > I will do it tonight if Alan does not do it first. > > ?eljko > -- > http://watirpodcast.com/ > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Fri Oct 9 04:26:34 2009 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 9 Oct 2009 10:26:34 +0200 Subject: [Wtr-development] fix WTR-324 in 1.6.5? In-Reply-To: <2a379a300910081622rf0442ecg8024105c4072f8c0@mail.gmail.com> References: <2a379a300910052240j663f37daj3063f40b8491f510@mail.gmail.com> <2a379a300910081622rf0442ecg8024105c4072f8c0@mail.gmail.com> Message-ID: On Fri, Oct 9, 2009 at 1:22 AM, Alan Baird wrote: > Ok, I'll try to do that tonight. I'm still a Git noob but I should be able to pull it together. Good luck. If you get stuck, ask. If you are on Mac, I wrote about my Git/Github adventures: http://zeljkofilipin.com/2009/03/28/git-and-github-on-mac/ If you are not on Mac, I guess you could still use a lot of information there. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From EThiel at mdsol.com Fri Oct 9 21:22:50 2009 From: EThiel at mdsol.com (Ethan Thiel) Date: Sat, 10 Oct 2009 01:22:50 -0000 Subject: [Wtr-development] Watir changes Message-ID: <7438EC0DB461E04182017BCB8DCC53AA052C403E@SECEXC004V.ad.mdsol.com> Dear Watir Development, My company (Medidata Solutions) has been using Watir for some time, and we have recently been working on adding Firefox testing to our application, so started using Firewatir. There were some incompatibilities with how we used watir for IE, so I forked from the latest git version of watir+firewatir, and started fixing things. That snowballed. A while after, barely a line of Firewatir code in my local repository was what I had started with. Then I started making my changes apply to IE as well. I think that my changes have improved the codebase substantially, and I would love to see them incorporated back into the main Watir repository. I am currently in the process of adding my code to a fork at github, but I'll outline major changes here. My github repository is at http://github.com/ethan-medidata/watir where you can see what I have added so far. I've tried to keep stuff that users tend to use the same, or as similar as I think is good. Nearly everything that used to work (that users tend to use) still does, but some behaves slightly differently. User-facing changes common to both browsers: The most major user-facing change is that I have made Container methods named after elements (such as #text_field, #div) return nil if the specified element does not exist. The previous practice of returning an element that did not exist, and then calling exists? to check if it exists, seemed unproductive to me; returning nil rather than a non-existent (and therefore pretty useless) object seems more natural. I have also added corresponding bang-methods (#text_field!, #div!) that error with Watir::Exception::UnknownObjectException if the specified element does not exist. These are useful when you expect that an element will be where you are looking, and it not being there is, well, exceptional. This seems more logical than raising UnknownObjectException when trying to use any method on a nonexistent object - error when instantiating an element, if it is expected to exist, rather than when using it later on. Other user-facing changes, more minor to varying degrees: Specifying elements by attribute works on any attribute that's defined on the DOM. MissingWayOfFindingObjectException is no longer raised as it no longer applies; any specified attribute is looked for. SelectList#options returns array of Options, not strings. SelectList#option_texts returns this instead. a bunch of methods which I renamed from names that didn't seem to me to make much sense, I have made to write a deprecation warning on STDERR when used. for example: SelectList#getAllContents SelectList#getSelectedItems both return an array of strings; why they are called 'Contents' in one and 'Items' in the other is not clear to me. I renamed these to: SelectList#option_texts SelectList#selected_option_texts those seeming like more sensible names (given the implementations are options.map(&:text) and selected_options.map(&:text)). Likewise, isSet? and getState are deprecated for the more ruby-like names set? or checked?. Elements no longer respond to methods that do not apply to them. A Div does not have a #value method, for example; nothing but a Label has a #for method. Only input elements have #disabled (actually, since writing that, I added it back on IE, having learned that apparently in IE the disabled attribute causes javascript events not to fire on any element. it does nothing in Firefox). #inspect and #to_s are different. they generally convey the same information as before, but they are each implemented once on Element and modified for each inheriting class, rather than being repeated on each inheriting class. show_#{element_name} (that is, show_forms, show_divs) prints out the number of matched elements and the #to_s for each element, rather than being reimplemented to show different information than #inspect or #to_s. #rows and #cells are only implemented on Table and TBody (rather than Element as before). TableRow also has #cells. These refer to the #rows and #cells methods present on the DOM, and don't use any GetElementsByWhatever - so, they don't return rows/cells from nested tables. For other Containers, #table_row and #table_cell exist, and do use GetElementsByWhatever, so do return nested stuff. #bodies is now #tbodies, as the former is likely to be confused with the tag. #to_s behaves the same on table/tr/td elements as it does on every other element, rather than returning #text. #innerText is deprecated as it doesn't exist on firefox and #text does what it does. #textContent is similarly deprecated. Image#height and #width return numbers rather than strings, as returned by WIN32OLE. I am not sure why these were cast to strings previously. The way that attributes are matched causes whitespace to be handled differently. Much of whitespace_test.rb failed, but I think correctly so. #text should return the full text and not strip whitespace from ends; it certainly shouldn't change whitespace in the middle of the string. Regexp should be used if one wants to match a different string, including a string that differs on whitespace, as I have done matching things in changes I made to whitespace_test (see github). Internal changes common to both browsers: Moved a whole lot of code into commonwatir. Some functions were repeated on every element class, of both browsers, such as #to_s (and related string_creator methods), #locate, and #initialize. These are all gone and replaced by a single method each on the Element module which every element class includes. Browser-specific classes were renamed to browser-specific class names. Created modules for elements (TextField, Div, etc) which browser-specific classes include. Many functions that were duplicated across IE and Firefox are likewise moved to common. Got rid of instances of evaluating strings as ruby; got rid of launching new ruby processes with dynamically generated code. 'how' (or @how) is now one of :attributes, :xpath, or :element_object. Specifying :id or :name or whatever to container.text_field(:id, "foo") gets converted into how=:attributes what={:id => 'foo'}. Internal changes to Firewatir: Well, nearly everything, really. There's barely a line of code in there that's the same. JsshObject is probably the biggest change. This class was created with similar intent to WIN32OLE - a JsshObject wraps around a javascript object (in the case of element objects, wraps around a DOM object) and exposes the properties of the object into ruby. You can access javascript objects in the same way as you would with a ruby object; no more strings of javascript code (sometimes hundreds of lines of spaghetti code) getting passed around. you can just write ruby. Following the JsshObject change, I ripped out pretty much every piece of javascript and related functionality that was in Firewatir. Which was most of it. No more variables with strings representing the names of javascript variables (window_var, document_var, element_object - element_object is now a JsshObject). No more long strings of javascript code being js_eval'd. (well, mostly - some stuff is still written in javascript, where it is necessary; other places for optimization.) Browser windows are kept track of by the actual window object, not guessing at the index of JSSH's getWindows() array. The Firewatir namespace is gone; everything is in Watir namespace. element classes are prefixed with FF (FFElement, FFTextField). Got rid of method_missing on the Element class (FFElement). This was causing Watir unit tests that should have failed to pass because it returns an empty string when an attribute doesn't exist, and it was being called with nonexistent attributes. Modal dialogs are handled by actually interacting with the modal dialog, not redefining alert, prompt, etc. startClicker is gone. Internal changes to IE Watir: Most of the IE changes apply to both browsers and are mentioned in the section about common changes. changed Element classes to IE-prefixed (IEElement, IETextField). winclicker is dead, and I use a class I wrote to interact with windows in Windows. I hope to kill AutoIt as well. Stuff remaining for me to do: The big ones are as usual testing and documentation. I have almost all of the unit tests passing, but I haven't written tests new tests for the code that I have written. A lot is covered by existing unit tests, but I haven't even run rcov yet to see what is not. For documentation: I have moved quite a bit of repetition out to metaprogramming type stuff, which is nicer for maintaining, but rdoc doesn't really handle it. I have yet to look to see how bad it is or what I can do with rdoc to make things any better. I need to add comments on quite a bit of stuff. I need to go through methods I have created and make sure things are private that ought to be. I have broken dialog and popup stuff in IE. I hope to kill reliance on AutoIt. Go through all my own #TODO comments and do them. Okay. That was a lot. I will be happy to answer questions, as I'm sure there will be (or at least, I hope this is interesting enough to generate questions), and discuss changes I have made. I will be continuing to work on the things I mentioned remaining to do, and pushing to github. Also, much thanks to the Watir development team for creating such a great tool, I have very much enjoyed working on it. Ethan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jari.bakken at gmail.com Sat Oct 10 11:08:47 2009 From: jari.bakken at gmail.com (Jari Bakken) Date: Sat, 10 Oct 2009 17:08:47 +0200 Subject: [Wtr-development] Watir changes In-Reply-To: <7438EC0DB461E04182017BCB8DCC53AA052C403E@SECEXC004V.ad.mdsol.com> References: <7438EC0DB461E04182017BCB8DCC53AA052C403E@SECEXC004V.ad.mdsol.com> Message-ID: Nice work, Ethan! Lots of changes, which makes it difficult to review it all in detail, so here's some comments just based on your email: On Sat, Oct 10, 2009 at 3:22 AM, Ethan Thiel wrote: > > The most major user-facing change is that I have made Container methods > named after elements (such as #text_field, #div) return nil if the specified > element does not exist. The previous practice of returning an element that > did not exist, and then calling exists? to check if it exists, seemed > unproductive to me; returning nil rather than a non-existent (and therefore > pretty useless) object seems more natural. > This is a mistake in my opinion. The returned object is not useless - it contains information about how to locate the element on the page. I don't see any real benefits to changing this, AND it breaks backwards compatibility. There are some benefits to the way it's currently working though, especially when writing abstractions around Watir objects. Consider this example: http://gist.github.com/206839 One of the benefits of Watir over Selenium++ IMO have always been that it's more object-oriented - and the 'lazy locate' is definitely part of what makes the above example easy to write. > I have also added corresponding bang-methods (#text_field!, #div!) that > error with Watir::Exception::UnknownObjectException if the specified element > does not exist. These are useful when you expect that an element will be > where you are looking, and it not being there is, well, exceptional. This > seems more logical than raising UnknownObjectException when trying to use > any method on a nonexistent object - error when instantiating an element, if > it is expected to exist, rather than when using it later on. This goes against API design princible of making "common things easy and rare things possible" - in most cases you want the exception raised, so that should be the default syntax. I would have to add exclamation marks all over my code. Also this is tied to the previous point - i.e. these methods are only needed if the nil change is accepted (which I'm against). > > Other user-facing changes, more minor to varying degrees: > > Specifying elements by attribute works on any attribute that's defined on > the DOM. MissingWayOfFindingObjectException is no longer raised as it no > longer applies; any specified attribute is looked for. This sounds good as well. What happens if the attribute doesn't exist - i.e. browser.div(:im_doing_it_wrong, 'id') ? > > SelectList#options returns array of Options, not strings. > SelectList#option_texts returns this instead. I agree with this change, this is more consistent. Are we happy with option_texts and selected_option_texts as the method names? > for example: > > ? SelectList#getAllContents > > ? SelectList#getSelectedItems > > both return an array of strings; why they are called 'Contents' in one and > 'Items' in the other is not clear to me. I renamed these to: > > ? SelectList#option_texts > > ? SelectList#selected_option_texts > > those seeming like more sensible names (given the implementations are > options.map(&:text) and selected_options.map(&:text)). > > Likewise, isSet? and getState are deprecated for the more ruby-like names > set? or checked?. > A lot of these changes were already made, in this commit: http://github.com/bret/watir/commit/3e5816fcd06568895c2fee1a3d5e1a5821c44a77. Deprecation warnings are nice though. > Elements no longer respond to methods that do not apply to them. A Div does > not have a #value method, for example; nothing but a Label has a #for > method. Only input elements have #disabled (actually, since writing that, I > added it back on IE, having learned that apparently in IE the disabled > attribute causes javascript events not to fire on any element. it does > nothing in Firefox). > > #inspect and #to_s are different. they generally convey the same information > as before, but they are each implemented once on Element and modified for > each inheriting class, rather than being repeated on each inheriting class. What does 'modified' vs 'repeated' mean in this context? > > show_#{element_name} (that is, show_forms, show_divs) prints out the number > of matched elements and the #to_s for each element, rather than being > reimplemented to show different information than #inspect or #to_s. > > #rows and #cells are only implemented on Table and TBody (rather than > Element as before). TableRow also has #cells. These refer to the #rows and > #cells methods present on the DOM, and don't use any GetElementsByWhatever - > so, they don't return rows/cells from nested tables. For other Containers, > #table_row and #table_cell exist, and do use GetElementsByWhatever, so do > return nested stuff. #bodies is now #tbodies, as the former is likely to be > confused with the tag. > > #to_s behaves the same on table/tr/td elements as it does on every other > element, rather than returning #text. > > #innerText is deprecated as it doesn't exist on firefox and #text does what > it does. #textContent is similarly deprecated. > > Image#height and #width return numbers rather than strings, as returned by > WIN32OLE. I am not sure why these were cast to strings previously. > > > > The way that attributes are matched causes whitespace to be handled > differently. Much of whitespace_test.rb failed, but I think correctly so. > #text should return the full text and not strip whitespace from ends; it > certainly shouldn't change whitespace in the middle of the string. Regexp > should be used if one wants to match a different string, including a string > that differs on whitespace, as I have done matching things in changes I made > to whitespace_test (see github). > Agreed. I think replacing entities (e.g. ) is ok though. > > > Internal changes common to both browsers: > > Moved a whole lot of code into commonwatir. Some functions were repeated on > every element class, of both browsers, such as #to_s (and related > string_creator methods), #locate, and #initialize. These are all gone and > replaced by a single method each on the Element module which every element > class includes. Sounds good. > > Browser-specific classes were renamed to browser-specific class names. Not sure what this means. > The Firewatir namespace is gone; everything is in Watir namespace. element > classes are prefixed with FF (FFElement, FFTextField). Why? In a language that actually supports namespaces, prefixing class names seems unnecessary. > > > changed Element classes to IE-prefixed (IEElement, IETextField). Again, I don't see why when Ruby has modules for this exact purpose. > > > Ethan > > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From jari.bakken at gmail.com Sat Oct 10 11:50:58 2009 From: jari.bakken at gmail.com (Jari Bakken) Date: Sat, 10 Oct 2009 17:50:58 +0200 Subject: [Wtr-development] Watir changes In-Reply-To: <7438EC0DB461E04182017BCB8DCC53AA052C403E@SECEXC004V.ad.mdsol.com> References: <7438EC0DB461E04182017BCB8DCC53AA052C403E@SECEXC004V.ad.mdsol.com> Message-ID: > For documentation: I have moved quite a bit of repetition out to > metaprogramming type stuff, which is nicer for maintaining, but rdoc doesn't > really handle it. I've looked through some of that now - to be honest I'm a little scared by the code in this file: http://github.com/ethan-medidata/watir/blob/master/commonwatir/lib/watir/elements/element.rb Perhaps it would be easier to just add some class methods to Element (likely in a module, so that the common modules can be extended with them), and use class instance variables instead of constants to store the configuration. So the common element definitions would end up something like this: http://gist.github.com/206929 I think this is better than using the ActiveSupport magic to add the methods based on the class name. (ActiveSupport is a huge dependency, and affects the load time a lot; which is ok for long-running processes like Rails, but bad for Watir where a common use case is to run short scripts over and over again). Right now it seems like almost all the Element modules include both ContainerMethodsFromName and ElementModule, I think replacing this with one extend() call and some class method calls in the class body makes the code a lot easier to understand. Sometimes readability is more important than DRY. From notethan at gmail.com Sat Oct 10 16:12:47 2009 From: notethan at gmail.com (Ethan) Date: Sat, 10 Oct 2009 16:12:47 -0400 Subject: [Wtr-development] container methods returning nil; bang-methods Message-ID: I'm breaking this off into a separate thread as it is the most major change I made, and the most subject to discussion. (Same Ethan here, but at home instead of at work.) On Sat, Oct 10, 2009 at 3:22 AM, Ethan wrote: > >> The most major user-facing change is that I have made Container methods >> named after elements (such as #text_field, #div) return nil if the specified >> element does not exist. The previous practice of returning an element that >> did not exist, and then calling exists? to check if it exists, seemed >> unproductive to me; returning nil rather than a non-existent (and therefore >> pretty useless) object seems more natural. > > I have also added corresponding bang-methods (#text_field!, #div!) that >> error with Watir::Exception::UnknownObjectException if the specified >> element does not exist. These are useful when you expect that an element >> will be where you are looking, and it not being there is, well, exceptional. >> This seems more logical than raising UnknownObjectException when trying to >> use any method on a nonexistent object - error when instantiating an >> element, if it is expected to exist, rather than when using it later on. > > > Jari Bakken wrote: > > This is a mistake in my opinion. The returned object is not useless - it > contains information about how to locate the element on the page. I don't > see any real benefits to changing this, AND it breaks > backwards compatibility. There are some benefits to the way it's > currently working though, especially when writing abstractions around > Watir objects. Consider this example: > http://gist.github.com/206839 > > One of the benefits of Watir over Selenium++ IMO have always been that it's > more object-oriented - and the 'lazy locate' is definitely part of what > makes the above example easy to write. > > Ethan wrote: > >> I have also added corresponding bang-methods (#text_field!, #div!) that >> error with Watir::Exception::UnknownObjectException if the specified >> element does not exist. These are useful when you expect that an element >> will be where you are looking, and it not being there is, well, exceptional. >> This seems more logical than raising UnknownObjectException when trying to >> use any method on a nonexistent object - error when instantiating an >> element, if it is expected to exist, rather than when using it later on. > > > Jari Bakken wrote: > This goes against API design princible of making "common things easy and > rare things possible" - in most cases you want the exception raised, so that > should be the default syntax. I would have to add exclamation marks all over > my code. Also this is tied to the previous point - i.e. these methods are > only needed if the nil change is accepted (which I'm against). > > For me at least - for my usage of Watir - it is not the case that it goes against the principle of making common things easiest. In my case I am testing a page and not certain of whether an element is on the page where I am looking, and I always have to check .exists? before I continue. just checking the return value of the container method would be more straightforward. This is in contrast with how the Watir unit tests tend to operate, where they interact with static pages, and it is expected that elements are where they are. My own usage and the unit tests are the only two usages of Watir I am particularly aware of; I would be interested to know if other people's usage is more similar to one or the other of those. The change to returning nil is only any different when an object doesn't exist. In that case, it's still returning a value that does not correspond to any element on the page: my way, it's nil; the current way, it's an element that can't be located and will raise exception if used. the returned object is not useless - it contains information about how to > locate the element on the page. What use is this information? The element is not on the page, so knowing how to locate it doesn't really do much good. The exception to that (the only one I can think of) is where AJAX loads elements onto a page - this is a discussion that I had with a coworker regarding this change. The example was elements appearing in the dom due to ajax calls, so say we do: javascript_button=browser.button(:id, 'foo') # say this button causes a table to pop into existence when clicked javascript_button.click table=browser.table :id, 'newly_existing_table' that will fail if the #click calls to something that returns before 'newly_existing_table' pops into existence, as with an ajax call or a setTimeout. to make it work the old way, it would be something like: table=browser.table :id, 'newly_existing_table' until table.exists? sleep 1 end my way, it would be something like: until table=browser.table :id, 'newly_existing_table' sleep 1 end Still, the latter seems more natural to me. it breaks backwards compatibility That is a major sticking point, it does break compatibility when elements are not found. One possibility is defining nil.exists? => false. My project does this (though I would prefer to remove reliance on it), and perhaps Watir including this would improve transitioning (hypothetically, if this ends up being the way things are done). But the exception raised on usage is different. Calling, say, browser.text_field(:id, 'nonexistent').click raises "NoMethodError: undefined method `click' for nil:NilClass"; the current way it raises UnknownObjectException. It is indeed a major API change that would break things, but I think it ends up being more natural and is worth the transition. Consider this example: > http://gist.github.com/206839 > I think that my way actually improves this example. You don't need the loading? method at all; it is implicit in the return value of loading_div. #save can simply use while !loading_div. You'd probably want to change browser.button(:id, 'save') to browser.button!(:id, 'save'), since you expect it to exist (since it gets clicked without checking .exists?). That runs into the issue you mention of adding !s all over the code. I think of the ! as your code asserting that it expects a thing to exist, and expects the error if it doesn't. Before, it was implied that code always expected an element to exist, and had to go out of its way calling .exists? if it wasn't sure. That just wasn't consistent with how I used Watir. But maybe my usage is not the norm. Ethan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Sat Oct 10 16:50:13 2009 From: bret at pettichord.com (Bret Pettichord) Date: Sat, 10 Oct 2009 15:50:13 -0500 Subject: [Wtr-development] container methods returning nil; bang-methods In-Reply-To: References: Message-ID: Ethan, Thanks for your thoughtful comments. Originally, I wanted exists? to work this way: browser.div(:id, 'body').button(:id, 'save').exists? would return false if either the div or the button didn't exist. We've never implemented it to work this way, but I think it would still be a good idea and more in line with the expectations and needs of our typical users. I would welcome a patch that made Watir work this way. Your proposal would not make this possible. As you note, the current implementation does provide better error reporting that what we'd get with your proposal. Very early versions of Watir, in fact, worked as you suggest -- it is the "natural" and easiest way of implementing it. But we added support for the current, less-natural behavior because it allowed us to give more helpful error messages to our users. Bret On Sat, Oct 10, 2009 at 3:12 PM, Ethan wrote: > I'm breaking this off into a separate thread as it is the most major change > I made, and the most subject to discussion. (Same Ethan here, but at home > instead of at work.) > > On Sat, Oct 10, 2009 at 3:22 AM, Ethan wrote: >> >>> The most major user-facing change is that I have made Container methods >>> named after elements (such as #text_field, #div) return nil if the specified >>> element does not exist. The previous practice of returning an element that >>> did not exist, and then calling exists? to check if it exists, seemed >>> unproductive to me; returning nil rather than a non-existent (and therefore >>> pretty useless) object seems more natural. >> >> I have also added corresponding bang-methods (#text_field!, #div!) that >>> error with Watir::Exception::UnknownObjectException if the specified >>> element does not exist. These are useful when you expect that an element >>> will be where you are looking, and it not being there is, well, exceptional. >>> This seems more logical than raising UnknownObjectException when trying to >>> use any method on a nonexistent object - error when instantiating an >>> element, if it is expected to exist, rather than when using it later on. >> >> >> Jari Bakken wrote: >> >> This is a mistake in my opinion. The returned object is not useless - it >> contains information about how to locate the element on the page. I don't >> see any real benefits to changing this, AND it breaks >> backwards compatibility. There are some benefits to the way it's >> currently working though, especially when writing abstractions around >> Watir objects. Consider this example: >> http://gist.github.com/206839 >> >> One of the benefits of Watir over Selenium++ IMO have always been >> that it's more object-oriented - and the 'lazy locate' is definitely part of >> what makes the above example easy to write. >> >> Ethan wrote: >> >>> I have also added corresponding bang-methods (#text_field!, #div!) that >>> error with Watir::Exception::UnknownObjectException if the specified >>> element does not exist. These are useful when you expect that an element >>> will be where you are looking, and it not being there is, well, exceptional. >>> This seems more logical than raising UnknownObjectException when trying to >>> use any method on a nonexistent object - error when instantiating an >>> element, if it is expected to exist, rather than when using it later on. >> >> >> Jari Bakken wrote: >> This goes against API design princible of making "common things easy and >> rare things possible" - in most cases you want the exception raised, so that >> should be the default syntax. I would have to add exclamation marks all over >> my code. Also this is tied to the previous point - i.e. these methods are >> only needed if the nil change is accepted (which I'm against). >> >> > For me at least - for my usage of Watir - it is not the case that it goes > against the principle of making common things easiest. In my case I am > testing a page and not certain of whether an element is on the page where I > am looking, and I always have to check .exists? before I continue. just > checking the return value of the container method would be more > straightforward. > This is in contrast with how the Watir unit tests tend to operate, where > they interact with static pages, and it is expected that elements are where > they are. My own usage and the unit tests are the only two usages of Watir I > am particularly aware of; I would be interested to know if other people's > usage is more similar to one or the other of those. > > The change to returning nil is only any different when an object doesn't > exist. In that case, it's still returning a value that does not correspond > to any element on the page: my way, it's nil; the current way, it's an > element that can't be located and will raise exception if used. > > the returned object is not useless - it contains information about how to >> locate the element on the page. > > > What use is this information? The element is not on the page, so knowing > how to locate it doesn't really do much good. > The exception to that (the only one I can think of) is where AJAX loads > elements onto a page - this is a discussion that I had with a coworker > regarding this change. The example was elements appearing in the dom due to > ajax calls, so say we do: > > javascript_button=browser.button(:id, 'foo') # say this button causes a > table to pop into existence when clicked > > javascript_button.click > > table=browser.table :id, 'newly_existing_table' > > that will fail if the #click calls to something that returns before > 'newly_existing_table' pops into existence, as with an ajax call or a > setTimeout. > to make it work the old way, it would be something like: > > table=browser.table :id, 'newly_existing_table' > > until table.exists? > > sleep 1 > > end > > my way, it would be something like: > > until table=browser.table :id, 'newly_existing_table' > > sleep 1 > > end > > Still, the latter seems more natural to me. > > > it breaks backwards compatibility > > > That is a major sticking point, it does break compatibility when elements > are not found. > One possibility is defining nil.exists? => false. My project does this > (though I would prefer to remove reliance on it), and perhaps Watir > including this would improve transitioning (hypothetically, if this ends up > being the way things are done). > But the exception raised on usage is different. Calling, say, > browser.text_field(:id, 'nonexistent').click raises "NoMethodError: > undefined method `click' for nil:NilClass"; the current way it > raises UnknownObjectException. > > It is indeed a major API change that would break things, but I think it > ends up being more natural and is worth the transition. > > Consider this example: >> http://gist.github.com/206839 >> > > I think that my way actually improves this example. You don't need the > loading? method at all; it is implicit in the return value of loading_div. > #save can simply use while !loading_div. > You'd probably want to change browser.button(:id, 'save') > to browser.button!(:id, 'save'), since you expect it to exist (since it gets > clicked without checking .exists?). That runs into the issue you mention of > adding !s all over the code. > > I think of the ! as your code asserting that it expects a thing to exist, > and expects the error if it doesn't. Before, it was implied that code always > expected an element to exist, and had to go out of its way calling .exists? > if it wasn't sure. That just wasn't consistent with how I used Watir. But > maybe my usage is not the norm. > > Ethan > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From jari.bakken at gmail.com Sat Oct 10 16:57:50 2009 From: jari.bakken at gmail.com (Jari Bakken) Date: Sat, 10 Oct 2009 22:57:50 +0200 Subject: [Wtr-development] container methods returning nil; bang-methods In-Reply-To: References: Message-ID: On Sat, Oct 10, 2009 at 10:12 PM, Ethan wrote: > For me at least - for my usage of Watir - it is not the case that it goes > against the principle of making common things easiest. In my case I am > testing a page and not certain of whether an element is on the page where I > am looking, and I always have to check .exists? before I continue. just > checking the return value of the container method would be more > straightforward. > This is in contrast with how the Watir unit tests tend to operate, where > they interact with static pages, and it is expected that elements are where > they are. My own usage and the unit tests are the only two usages of Watir I > am particularly aware of; I would be interested to know if other people's > usage is more similar to one or the other of those. Really? I think you're among the minority if you call exists? on on Watir elements more often than not. That makes me a bit curious about how your tests are set up. Do you have a framework where you identify what page you're on by looking for what elements exist? For my usage I bet around 97% of the time I know exactly what page I'm on, and what elements are on the page - if they're not there, I want the exception raised. The remaining 3% are most often JS manipulations like you mention below. This is really another discussion though - what is the default can easily be swapped if the team decides to. > The change to returning nil is only any different when an object doesn't > exist. In that case, it's still returning a value that does not correspond > to any element on the page: my way, it's nil; the current way, it's an > element that can't be located and will raise exception if used. >> >> the returned object is not useless -?it contains information about how to >> locate the element on the page. > > What use is this information? The element is not on the page, so knowing how > to locate it doesn't really do much good. > The exception to that (the only one I can think of) is where AJAX loads > elements onto a page - this is a discussion that I had with a coworker > regarding this change. The example was elements appearing in the dom due to > ajax calls, so say we do: The AJAX stuff is one use case. The page class from my gist is another: I want to separate how the element is located from how I interact with it. >> >> it breaks backwards?compatibility > >> >> Consider this example: >> >> http://gist.github.com/206839 > > I think that my way actually improves this example. You don't need the > loading? method at all; it is implicit in the return value of loading_div. > #save can simply use ?while !loading_div. > You'd probably want to change browser.button(:id, 'save') > to browser.button!(:id, 'save'), since you expect it to exist (since it gets > clicked without checking .exists?). That runs into the issue you mention of > adding !s all over the code. I _want_ the loading? method - I want to ask the page if it's loading, not if it has a loading div. That's the whole point of the page abstraction. I could do that with your changes as well, but if someone down the line (perhaps the page class itself) want to ask if the save_button exists, how can I do that cleanly? The 'lazy locate' feature of current API offers the flexibility to easily build this kind of abstraction around it. > I think of the ! as your code asserting that it expects a thing to exist, > and expects the error if it doesn't. Before, it was implied that code always > expected an element to exist, and had to go out of its way calling .exists? > if it wasn't sure. Yes - and I'd like to keep all of those decisions (does it exist or not, how will I interact with it) separate from how the element is located (which as we all know, can change rapidly). >That just wasn't consistent with how I used Watir. But > maybe my usage is not the norm. Perhaps it's my usage that's not the norm. I guess we'll agree to disagree, and wait for others to chip in ;) > Ethan > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From notethan at gmail.com Sat Oct 10 17:20:34 2009 From: notethan at gmail.com (Ethan) Date: Sat, 10 Oct 2009 17:20:34 -0400 Subject: [Wtr-development] Watir changes In-Reply-To: References: <7438EC0DB461E04182017BCB8DCC53AA052C403E@SECEXC004V.ad.mdsol.com> Message-ID: On Sat, Oct 10, 2009 at 11:08, Jari Bakken wrote: > Nice work, Ethan! Lots of changes, which makes it difficult to review > it all in detail, so here's some comments just based on your email: > > [discussion on returning nil/bang-method stuff that I switched to a new thread] > > > > Other user-facing changes, more minor to varying degrees: > > > > Specifying elements by attribute works on any attribute that's defined on > > the DOM. MissingWayOfFindingObjectException is no longer raised as it no > > longer applies; any specified attribute is looked for. > > This sounds good as well. What happens if the attribute doesn't exist > - i.e. browser.div(:im_doing_it_wrong, 'id') ? > Due to the fact that what methods and attributes exist on the DOM varies greatly from element to element, and also because there can be attributes on the dom that aren't actually valid html, I don't make any attempt to enumerate what is valid for each element. browser.div(:im_doing_it_wrong, 'id') will not locate an element, and will return nil (or, will return a nonexistent element, if we change that returns-nil thing back) - unless you actually do have in your html,

, in which case it should successfully find that. > > > > SelectList#options returns array of Options, not strings. > > SelectList#option_texts returns this instead. > > I agree with this change, this is more consistent. Are we happy with > option_texts and selected_option_texts as the method names? > > > for example: > > > > SelectList#getAllContents > > > > SelectList#getSelectedItems > > > > both return an array of strings; why they are called 'Contents' in one > and > > 'Items' in the other is not clear to me. I renamed these to: > > > > SelectList#option_texts > > > > SelectList#selected_option_texts > > > > those seeming like more sensible names (given the implementations are > > options.map(&:text) and selected_options.map(&:text)). > > > > Likewise, isSet? and getState are deprecated for the more ruby-like names > > set? or checked?. > > > > A lot of these changes were already made, in this commit: > > http://github.com/bret/watir/commit/3e5816fcd06568895c2fee1a3d5e1a5821c44a77 > . > > Deprecation warnings are nice though. > I hadn't seen that. cool. > > > Elements no longer respond to methods that do not apply to them. A Div > does > > not have a #value method, for example; nothing but a Label has a #for > > method. Only input elements have #disabled (actually, since writing that, > I > > added it back on IE, having learned that apparently in IE the disabled > > attribute causes javascript events not to fire on any element. it does > > nothing in Firefox). > > > > #inspect and #to_s are different. they generally convey the same > information > > as before, but they are each implemented once on Element and modified for > > each inheriting class, rather than being repeated on each inheriting > class. > > What does 'modified' vs 'repeated' mean in this context? > By not repeated, I just mean that there's no def inspect or def to_s on each class. By modified, I mean, for example: * * module InputElement inspect_these :name, :value, :type end The inspect_these method adds those attributes to a list of what gets inspected for InputElement (and things that inherit from InputElement). I also added a function that combined this with dom_wrap so that it can be put more concisely what attributes should both be inspected, have methods that point to their dom attributes, so that became: module InputElement dom_wrap_inspect :name, :value, :type end But I'm not sure, that may be a bit much and may negatively affect readability. > > > > show_#{element_name} (that is, show_forms, show_divs) prints out the > number > > of matched elements and the #to_s for each element, rather than being > > reimplemented to show different information than #inspect or #to_s. > > > > #rows and #cells are only implemented on Table and TBody (rather than > > Element as before). TableRow also has #cells. These refer to the #rows > and > > #cells methods present on the DOM, and don't use any > GetElementsByWhatever - > > so, they don't return rows/cells from nested tables. For other > Containers, > > #table_row and #table_cell exist, and do use GetElementsByWhatever, so do > > return nested stuff. #bodies is now #tbodies, as the former is likely to > be > > confused with the tag. > > > > #to_s behaves the same on table/tr/td elements as it does on every other > > element, rather than returning #text. > > > > #innerText is deprecated as it doesn't exist on firefox and #text does > what > > it does. #textContent is similarly deprecated. > > > > Image#height and #width return numbers rather than strings, as returned > by > > WIN32OLE. I am not sure why these were cast to strings previously. > > > > > > > > The way that attributes are matched causes whitespace to be handled > > differently. Much of whitespace_test.rb failed, but I think correctly so. > > #text should return the full text and not strip whitespace from ends; it > > certainly shouldn't change whitespace in the middle of the string. Regexp > > should be used if one wants to match a different string, including a > string > > that differs on whitespace, as I have done matching things in changes I > made > > to whitespace_test (see github). > > > > Agreed. I think replacing entities (e.g. ) is ok though. > For that, innerText (IE) and textContent (FF) already do replace entities like , so Watir doesn't need to. > > > > > > Internal changes common to both browsers: > > > > Moved a whole lot of code into commonwatir. Some functions were repeated > on > > every element class, of both browsers, such as #to_s (and related > > string_creator methods), #locate, and #initialize. These are all gone and > > replaced by a single method each on the Element module which every > element > > class includes. > > Sounds good. > > > > > Browser-specific classes were renamed to browser-specific class names. > > Not sure what this means. > > > The Firewatir namespace is gone; everything is in Watir namespace. > element > > classes are prefixed with FF (FFElement, FFTextField). > > Why? In a language that actually supports namespaces, prefixing class > names seems unnecessary. > > > > > > > changed Element classes to IE-prefixed (IEElement, IETextField). > > Again, I don't see why when Ruby has modules for this exact purpose. > I considered putting them in their own namespaces but I decided that would be too confusing. Say you have - Watir::TextField for common - Watir::IE::TextField - Watir::Firefox::TextField I think it would get confusing when you are in, say, the Watir::Firefox namespace, whether an unprefixed TextField is meant to refer to the common one or the firefox one. Maybe - Watir::Common::TextField - Watir::IE::TextField - Watir::Firefox::Textfield so that in any namespace you have to prefix the other's namespace. But that would break everything that checks stuff like foo.is_a?(Watir::TextField) - I named the common one after the existing IE one so that that would still work. (it still breaks backwards compatibility if code uses foo.class==Watir::TextField, but is_a? is generally recommended, so I figured this would be acceptable.) Another possibility is - Watir::TextField for common - IEWatir::TextField - FireWatir::TextField But I figured having separate browser-specific class names in one namespace was preferable to having identical class names in browser-specific namespaces. On Sat, Oct 10, 2009 at 11:50, Jari Bakken wrote: > > For documentation: I have moved quite a bit of repetition out to > > metaprogramming type stuff, which is nicer for maintaining, but rdoc > doesn't > > really handle it. > > I've looked through some of that now - to be honest I'm a little > scared by the code in this file: > > > http://github.com/ethan-medidata/watir/blob/master/commonwatir/lib/watir/elements/element.rb > > Perhaps it would be easier to just add some class methods to Element > (likely in a module, so that the common modules can be extended with > them), and use class instance variables instead of constants to store > the configuration. > > So the common element definitions would end up something like this: > http://gist.github.com/206929 I like this, I think I agree that this reads better. > I think this is better than using the ActiveSupport magic to add the > methods based on the class name. (ActiveSupport is a huge dependency, > and affects the load time a lot; which is ok for long-running > processes like Rails, but bad for Watir where a common use case is to > run short scripts over and over again). > I agree, I'm all in favor of dropping ActiveSupport dependency. > Right now it seems like almost all the Element modules include both > ContainerMethodsFromName and ElementModule, I think replacing this > with one extend() call and some class method calls in the class body > makes the code a lot easier to understand. > > Sometimes readability is more important than DRY. Agreed. I will put this stuff on my todo list. Ethan -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Sat Oct 10 18:16:25 2009 From: notethan at gmail.com (Ethan) Date: Sat, 10 Oct 2009 18:16:25 -0400 Subject: [Wtr-development] container methods returning nil; bang-methods In-Reply-To: References: Message-ID: On Sat, Oct 10, 2009 at 16:57, Jari Bakken wrote: > On Sat, Oct 10, 2009 at 10:12 PM, Ethan wrote: > > For me at least - for my usage of Watir - it is not the case that it goes > > against the principle of making common things easiest. In my case I am > > testing a page and not certain of whether an element is on the page where > I > > am looking, and I always have to check .exists? before I continue. just > > checking the return value of the container method would be more > > straightforward. > > This is in contrast with how the Watir unit tests tend to operate, where > > they interact with static pages, and it is expected that elements are > where > > they are. My own usage and the unit tests are the only two usages of > Watir I > > am particularly aware of; I would be interested to know if other people's > > usage is more similar to one or the other of those. > > Really? I think you're among the minority if you call exists? on on > Watir elements more often than not. That makes me a bit curious about > how your tests are set up. Do you have a framework where you identify > what page you're on by looking for what elements exist? For my usage I > bet around 97% of the time I know exactly what page I'm on, and what > elements are on the page - if they're not there, I want the exception > raised. The remaining 3% are most often JS manipulations like you > mention below. > > This is really another discussion though - what is the default can > easily be swapped if the team decides to. > > > The change to returning nil is only any different when an object doesn't > > exist. In that case, it's still returning a value that does not > correspond > > to any element on the page: my way, it's nil; the current way, it's an > > element that can't be located and will raise exception if used. > >> > >> the returned object is not useless - it contains information about how > to > >> locate the element on the page. > > > > What use is this information? The element is not on the page, so knowing > how > > to locate it doesn't really do much good. > > The exception to that (the only one I can think of) is where AJAX loads > > elements onto a page - this is a discussion that I had with a coworker > > regarding this change. The example was elements appearing in the dom due > to > > ajax calls, so say we do: > > The AJAX stuff is one use case. The page class from my gist is > another: I want to separate how the element is located from how I > interact with it. > > >> > >> it breaks backwards compatibility > > > >> > >> Consider this example: > >> > >> http://gist.github.com/206839 > > > > I think that my way actually improves this example. You don't need the > > loading? method at all; it is implicit in the return value of > loading_div. > > #save can simply use while !loading_div. > > You'd probably want to change browser.button(:id, 'save') > > to browser.button!(:id, 'save'), since you expect it to exist (since it > gets > > clicked without checking .exists?). That runs into the issue you mention > of > > adding !s all over the code. > > I _want_ the loading? method - I want to ask the page if it's loading, > not if it has a loading div. That's the whole point of the page > abstraction. I could do that with your changes as well, but if someone > down the line (perhaps the page class itself) want to ask if the > save_button exists, how can I do that cleanly? The 'lazy locate' > feature of current API offers the flexibility to easily build this > kind of abstraction around it. > > > I think of the ! as your code asserting that it expects a thing to exist, > > and expects the error if it doesn't. Before, it was implied that code > always > > expected an element to exist, and had to go out of its way calling > .exists? > > if it wasn't sure. > > Yes - and I'd like to keep all of those decisions (does it exist or > not, how will I interact with it) separate from how the element is > located (which as we all know, can change rapidly). > > > >That just wasn't consistent with how I used Watir. But > > maybe my usage is not the norm. > > Perhaps it's my usage that's not the norm. I guess we'll agree to > disagree, and wait for others to chip in ;) > > I think that fundamentally it comes down to a question of how Watir expects to be used. Currently it expects to be asked for elements on the page in the browser that exist, and it will return elements on the assumption that they exist and are ready to be used. The way my project uses Watir, we are more asking Watir whether these elements that we specify exist, and if they don't exist, we go on to try something else. Basically it's whether Watir expects to be used like "give me these elements that exist" vs used like "give me these elements if they exist". The former makes sense for you, as you point out you generally don't call exists? and you do expect that the element is there as specified. For me the latter makes sense, as I always call exists? - hence the big API change. I suppose which direction Watir itself goes should depend on what would benefit the greatest number of users the most - whether most users use it expecting existence, or whether they check the existence before using. I don't know which one is the case, but it's looking like my project's usage of Watir is more atypical than I had thought. Can we get more people to weigh in? (Damn, I wish I hadn't changed all those tests before this discussion. Changing the implementation is easy enough now, just a few lines in common element.rb, but switching all the tests back and forth, huge hassle. Ah well, my own fault.) Ethan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.koops at gmail.com Sat Oct 10 17:41:06 2009 From: tim.koops at gmail.com (tim.koops at gmail.com) Date: Sat, 10 Oct 2009 21:41:06 +0000 Subject: [Wtr-development] container methods returning nil; bang-methods In-Reply-To: Message-ID: <0016367b6cb4d2d62004759b8d49@google.com> Initially as a user I just expected it to work this way... unless browser.div(:id, 'body').button(:id, 'save') ... But it didn't take long through the examples to learn about the exists? method. I primarily rely on Waiter to do my syncing between pages, often just looking for text rather than page elements Watir::Waiter.wait_until{ browser.html.include?("domloaded") } My understanding is that I could change that block to be Watir::Waiter.wait_until{ browser.div(:id, 'body').button(:id, 'save').exists? } and would achieve the same goal no? On 11/10/2009 7:50am, Bret Pettichord wrote: > Ethan, > Thanks for your thoughtful comments. > Originally, I wanted exists? to work this way: > browser.div(:id, 'body').button(:id, 'save').exists? > would return false if either the div or the button didn't exist. We've > never implemented it to work this way, but I think it would still be a > good idea and more in line with the expectations and needs of our typical > users. I would welcome a patch that made Watir work this way. Your > proposal would not make this possible. > As you note, the current implementation does provide better error > reporting that what we'd get with your proposal. Very early versions of > Watir, in fact, worked as you suggest -- it is the "natural" and easiest > way of implementing it. But we added support for the current, > less-natural behavior because it allowed us to give more helpful error > messages to our users. > Bret > On Sat, Oct 10, 2009 at 3:12 PM, Ethan notethan at gmail.com> wrote: > I'm breaking this off into a separate thread as it is the most major > change I made, and the most subject to discussion. (Same Ethan here, but > at home instead of at work.) > On Sat, Oct 10, 2009 at 3:22 AM, Ethan wrote: > The most major user-facing change is that I have made Container methods > named after elements (such as #text_field, #div) return nil if the > specified element does not exist. The previous practice of returning an > element that did not exist, and then calling exists? to check if it > exists, seemed unproductive to me; returning nil rather than a > non-existent (and therefore pretty useless) object seems more natural. > I have also added corresponding bang-methods (#text_field!, #div!) that > error with Watir::Exception::UnknownObjectException if the specified > element does not exist. These are useful when you expect that an element > will be where you are looking, and it not being there is, well, > exceptional. This seems more logical than raising UnknownObjectException > when trying to use any method on a nonexistent object - error when > instantiating an element, if it is expected to exist, rather than when > using it later on. > Jari Bakken wrote: > This is a mistake in my opinion. The returned object is not useless - it > contains information about how to locate the element on the page. I don't > see any real benefits to changing this, AND it breaks backwards > compatibility. There are some benefits to the way it's currently working > though, especially when writing abstractions around Watir objects. > Consider this example: > http://gist.github.com/206839 > One of the benefits of Watir over Selenium++ IMO have always been that > it's more object-oriented - and the 'lazy locate' is definitely part of > what makes the above example easy to write. > Ethan wrote: > I have also added corresponding bang-methods (#text_field!, #div!) that > error with Watir::Exception::UnknownObjectException if the specified > element does not exist. These are useful when you expect that an element > will be where you are looking, and it not being there is, well, > exceptional. This seems more logical than raising UnknownObjectException > when trying to use any method on a nonexistent object - error when > instantiating an element, if it is expected to exist, rather than when > using it later on. > Jari Bakken wrote: > This goes against API design princible of making "common things easy and > rare things possible" - in most cases you want the exception raised, so > that should be the default syntax. I would have to add exclamation marks > all over my code. Also this is tied to the previous point - ie these > methods are only needed if the nil change is accepted (which I'm against). > For me at least - for my usage of Watir - it is not the case that it goes > against the principle of making common things easiest. In my case I am > testing a page and not certain of whether an element is on the page where > I am looking, and I always have to check .exists? before I continue. just > checking the return value of the container method would be more > straightforward. > This is in contrast with how the Watir unit tests tend to operate, where > they interact with static pages, and it is expected that elements are > where they are. My own usage and the unit tests are the only two usages > of Watir I am particularly aware of; I would be interested to know if > other people's usage is more similar to one or the other of those. > The change to returning nil is only any different when an object doesn't > exist. In that case, it's still returning a value that does not > correspond to any element on the page: my way, it's nil; the current way, > it's an element that can't be located and will raise exception if used. > the returned object is not useless - it contains information about how to > locate the element on the page. > What use is this information? The element is not on the page, so knowing > how to locate it doesn't really do much good. > The exception to that (the only one I can think of) is where AJAX loads > elements onto a page - this is a discussion that I had with a coworker > regarding this change. The example was elements appearing in the dom due > to ajax calls, so say we do: > javascript_button=browser.button(:id, 'foo') # say this button causes a > table to pop into existence when clickedjavascript_button.click > table=browser.table :id, 'newly_existing_table' > that will fail if the #click calls to something that returns > before 'newly_existing_table' pops into existence, as with an ajax call > or a setTimeout. > to make it work the old way, it would be something like: > table=browser.table :id, 'newly_existing_table'until table.exists? > sleep 1end > my way, it would be something like: > until table=browser.table :id, 'newly_existing_table' sleep 1 > end > Still, the latter seems more natural to me. > it breaks backwards compatibility > That is a major sticking point, it does break compatibility when elements > are not found. > One possibility is defining nil.exists? => false. My project does this > (though I would prefer to remove reliance on it), and perhaps Watir > including this would improve transitioning (hypothetically, if this ends > up being the way things are done). > But the exception raised on usage is different. Calling, say, > browser.text_field(:id, 'nonexistent').click raises "NoMethodError: > undefined method `click' for nil:NilClass"; the current way it raises > UnknownObjectException. > It is indeed a major API change that would break things, but I think it > ends up being more natural and is worth the transition. > Consider this example: > http://gist.github.com/206839 > I think that my way actually improves this example. You don't need the > loading? method at all; it is implicit in the return value of > loading_div. #save can simply use while !loading_div. > You'd probably want to change browser.button(:id, 'save') to > browser.button!(:id, 'save'), since you expect it to exist (since it gets > clicked without checking .exists?). That runs into the issue you mention > of adding !s all over the code. > I think of the ! as your code asserting that it expects a thing to exist, > and expects the error if it doesn't. Before, it was implied that code > always expected an element to exist, and had to go out of its way > calling .exists? if it wasn't sure. That just wasn't consistent with how > I used Watir. But maybe my usage is not the norm. > Ethan > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.koops at gmail.com Sat Oct 10 17:41:05 2009 From: tim.koops at gmail.com (tim.koops at gmail.com) Date: Sat, 10 Oct 2009 21:41:05 +0000 Subject: [Wtr-development] container methods returning nil; bang-methods In-Reply-To: Message-ID: <0016e64be580c01f3e04759b8dc4@google.com> Initially as a user I just expected it to work this way... unless browser.div(:id, 'body').button(:id, 'save') ... But it didn't take long through the examples to learn about the exists? method. I primarily rely on Waiter to do my syncing between pages, often just looking for text rather than page elements Watir::Waiter.wait_until{ browser.html.include?("domloaded") } My understanding is that I could change that block to be Watir::Waiter.wait_until{ browser.div(:id, 'body').button(:id, 'save').exists? } and would achieve the same goal no? On 11/10/2009 7:50am, Bret Pettichord wrote: > Ethan, > Thanks for your thoughtful comments. > Originally, I wanted exists? to work this way: > browser.div(:id, 'body').button(:id, 'save').exists? > would return false if either the div or the button didn't exist. We've > never implemented it to work this way, but I think it would still be a > good idea and more in line with the expectations and needs of our typical > users. I would welcome a patch that made Watir work this way. Your > proposal would not make this possible. > As you note, the current implementation does provide better error > reporting that what we'd get with your proposal. Very early versions of > Watir, in fact, worked as you suggest -- it is the "natural" and easiest > way of implementing it. But we added support for the current, > less-natural behavior because it allowed us to give more helpful error > messages to our users. > Bret > On Sat, Oct 10, 2009 at 3:12 PM, Ethan notethan at gmail.com> wrote: > I'm breaking this off into a separate thread as it is the most major > change I made, and the most subject to discussion. (Same Ethan here, but > at home instead of at work.) > On Sat, Oct 10, 2009 at 3:22 AM, Ethan wrote: > The most major user-facing change is that I have made Container methods > named after elements (such as #text_field, #div) return nil if the > specified element does not exist. The previous practice of returning an > element that did not exist, and then calling exists? to check if it > exists, seemed unproductive to me; returning nil rather than a > non-existent (and therefore pretty useless) object seems more natural. > I have also added corresponding bang-methods (#text_field!, #div!) that > error with Watir::Exception::UnknownObjectException if the specified > element does not exist. These are useful when you expect that an element > will be where you are looking, and it not being there is, well, > exceptional. This seems more logical than raising UnknownObjectException > when trying to use any method on a nonexistent object - error when > instantiating an element, if it is expected to exist, rather than when > using it later on. > Jari Bakken wrote: > This is a mistake in my opinion. The returned object is not useless - it > contains information about how to locate the element on the page. I don't > see any real benefits to changing this, AND it breaks backwards > compatibility. There are some benefits to the way it's currently working > though, especially when writing abstractions around Watir objects. > Consider this example: > http://gist.github.com/206839 > One of the benefits of Watir over Selenium++ IMO have always been that > it's more object-oriented - and the 'lazy locate' is definitely part of > what makes the above example easy to write. > Ethan wrote: > I have also added corresponding bang-methods (#text_field!, #div!) that > error with Watir::Exception::UnknownObjectException if the specified > element does not exist. These are useful when you expect that an element > will be where you are looking, and it not being there is, well, > exceptional. This seems more logical than raising UnknownObjectException > when trying to use any method on a nonexistent object - error when > instantiating an element, if it is expected to exist, rather than when > using it later on. > Jari Bakken wrote: > This goes against API design princible of making "common things easy and > rare things possible" - in most cases you want the exception raised, so > that should be the default syntax. I would have to add exclamation marks > all over my code. Also this is tied to the previous point - ie these > methods are only needed if the nil change is accepted (which I'm against). > For me at least - for my usage of Watir - it is not the case that it goes > against the principle of making common things easiest. In my case I am > testing a page and not certain of whether an element is on the page where > I am looking, and I always have to check .exists? before I continue. just > checking the return value of the container method would be more > straightforward. > This is in contrast with how the Watir unit tests tend to operate, where > they interact with static pages, and it is expected that elements are > where they are. My own usage and the unit tests are the only two usages > of Watir I am particularly aware of; I would be interested to know if > other people's usage is more similar to one or the other of those. > The change to returning nil is only any different when an object doesn't > exist. In that case, it's still returning a value that does not > correspond to any element on the page: my way, it's nil; the current way, > it's an element that can't be located and will raise exception if used. > the returned object is not useless - it contains information about how to > locate the element on the page. > What use is this information? The element is not on the page, so knowing > how to locate it doesn't really do much good. > The exception to that (the only one I can think of) is where AJAX loads > elements onto a page - this is a discussion that I had with a coworker > regarding this change. The example was elements appearing in the dom due > to ajax calls, so say we do: > javascript_button=browser.button(:id, 'foo') # say this button causes a > table to pop into existence when clickedjavascript_button.click > table=browser.table :id, 'newly_existing_table' > that will fail if the #click calls to something that returns > before 'newly_existing_table' pops into existence, as with an ajax call > or a setTimeout. > to make it work the old way, it would be something like: > table=browser.table :id, 'newly_existing_table'until table.exists? > sleep 1end > my way, it would be something like: > until table=browser.table :id, 'newly_existing_table' sleep 1 > end > Still, the latter seems more natural to me. > it breaks backwards compatibility > That is a major sticking point, it does break compatibility when elements > are not found. > One possibility is defining nil.exists? => false. My project does this > (though I would prefer to remove reliance on it), and perhaps Watir > including this would improve transitioning (hypothetically, if this ends > up being the way things are done). > But the exception raised on usage is different. Calling, say, > browser.text_field(:id, 'nonexistent').click raises "NoMethodError: > undefined method `click' for nil:NilClass"; the current way it raises > UnknownObjectException. > It is indeed a major API change that would break things, but I think it > ends up being more natural and is worth the transition. > Consider this example: > http://gist.github.com/206839 > I think that my way actually improves this example. You don't need the > loading? method at all; it is implicit in the return value of > loading_div. #save can simply use while !loading_div. > You'd probably want to change browser.button(:id, 'save') to > browser.button!(:id, 'save'), since you expect it to exist (since it gets > clicked without checking .exists?). That runs into the issue you mention > of adding !s all over the code. > I think of the ! as your code asserting that it expects a thing to exist, > and expects the error if it doesn't. Before, it was implied that code > always expected an element to exist, and had to go out of its way > calling .exists? if it wasn't sure. That just wasn't consistent with how > I used Watir. But maybe my usage is not the norm. > Ethan > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- > Bret Pettichord > Lead Developer, Watir, www.watir.com > Blog, www.io.com/~wazmo/blog > Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Sat Oct 10 18:35:36 2009 From: bret at pettichord.com (Bret Pettichord) Date: Sat, 10 Oct 2009 17:35:36 -0500 Subject: [Wtr-development] Watir changes In-Reply-To: References: <7438EC0DB461E04182017BCB8DCC53AA052C403E@SECEXC004V.ad.mdsol.com> Message-ID: On Sat, Oct 10, 2009 at 4:20 PM, Ethan wrote: > > >> > Other user-facing changes, more minor to varying degrees: >> > >> > Specifying elements by attribute works on any attribute that's defined >> on >> > the DOM. MissingWayOfFindingObjectException is no longer raised as it >> no >> > longer applies; any specified attribute is looked for. >> >> This sounds good as well. What happens if the attribute doesn't exist >> - i.e. browser.div(:im_doing_it_wrong, 'id') ? >> > > Due to the fact that what methods and attributes exist on the DOM varies > greatly from element to element, and also because there can be attributes on > the dom that aren't actually valid html, I don't make any attempt to > enumerate what is valid for each element. > browser.div(:im_doing_it_wrong, 'id') will not locate an element, and will > return nil (or, will return a nonexistent element, if we change that > returns-nil thing back) - unless you actually do have in your html,

im_doing_it_wrong="id">, in which case it should successfully find that. > FireWatir works as you suggest and I don't like it. I really like my testing tools to fail loudly and this approach causes it to fail quietly, and makes it hard to debug my tests. I do like the idea of making it easier to use other attributes, though. By not repeated, I just mean that there's no def inspect or def to_s on each > class. By modified, I mean, for example: > * > * > > module InputElement > > inspect_these :name, :value, :type > > end > > i like this. The inspect_these method adds those attributes to a list of what gets > inspected for InputElement (and things that inherit from InputElement). > I also added a function that combined this with dom_wrap so that it can be > put more concisely what attributes should both be inspected, have methods > that point to their dom attributes, so that became: > > module InputElement > > dom_wrap_inspect :name, :value, :type > > end > > > But I'm not sure, that may be a bit much and may negatively affect > readability. > Yes. We used the more verbose approach because it allowed the Rdoc to pick up our methods. I considered putting them in their own namespaces but I decided that would > be too confusing. Say you have > > - Watir::TextField for common > - Watir::IE::TextField > - Watir::Firefox::TextField > > I think it would get confusing when you are in, say, the Watir::Firefox > namespace, whether an unprefixed TextField is meant to refer to the common > one or the firefox one. Maybe > > - Watir::Common::TextField > - Watir::IE::TextField > - Watir::Firefox::Textfield > > I like this. BTW, this is a big change and really needs to be discussed in the context of how we want to structure Watir 2.0. > so that in any namespace you have to prefix the other's namespace. But that > would break everything that checks stuff like foo.is_a?(Watir::TextField) - > I named the common one after the existing IE one so that that would still > work. (it still breaks backwards compatibility if code uses > foo.class==Watir::TextField, but is_a? is generally recommended, so I > figured this would be acceptable.) > > Another possibility is > > - Watir::TextField for common > - IEWatir::TextField > - FireWatir::TextField > > But I figured having separate browser-specific class names in one namespace > was preferable to having identical class names in browser-specific > namespaces. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Sat Oct 10 19:58:26 2009 From: notethan at gmail.com (Ethan) Date: Sat, 10 Oct 2009 19:58:26 -0400 Subject: [Wtr-development] Watir changes In-Reply-To: References: <7438EC0DB461E04182017BCB8DCC53AA052C403E@SECEXC004V.ad.mdsol.com> Message-ID: On Sat, Oct 10, 2009 at 18:35, Bret Pettichord wrote: > > On Sat, Oct 10, 2009 at 4:20 PM, Ethan wrote: > >> >> >>> > Other user-facing changes, more minor to varying degrees: >>> > >>> > Specifying elements by attribute works on any attribute that's defined >>> on >>> > the DOM. MissingWayOfFindingObjectException is no longer raised as it >>> no >>> > longer applies; any specified attribute is looked for. >>> >>> This sounds good as well. What happens if the attribute doesn't exist >>> - i.e. browser.div(:im_doing_it_wrong, 'id') ? >>> >> >> Due to the fact that what methods and attributes exist on the DOM varies >> greatly from element to element, and also because there can be attributes on >> the dom that aren't actually valid html, I don't make any attempt to >> enumerate what is valid for each element. >> browser.div(:im_doing_it_wrong, 'id') will not locate an element, and >> will return nil (or, will return a nonexistent element, if we change that >> returns-nil thing back) - unless you actually do have in your html,