From michael at developsense.com Mon May 1 14:16:29 2006 From: michael at developsense.com (Michael Bolton) Date: Mon, 1 May 2006 14:16:29 -0400 Subject: [Wtr-core] Gem vs. .exe In-Reply-To: Message-ID: <06b601c66d4b$5e580780$6601a8c0@Koko> I don't understand the reason for the depth of the paths that we're using. Bret has said that Watir goes into c:/ruby/lib/ruby/1.8/site-lib. Why? Something seems really haphazard about the organization of gems altogether. I see stuff in C:\ruby\lib\ruby\gems\1.8\gems\watir-1.5.0.934 This seems deficient, in that we have two instances of "ruby" in the path, and two instances of "gems" on the path, but only one instance each of "1.8" and "lib"--couldn't we throw a couple more 1.8s and libs in there too, for balance? <-joke Seriously: - I agree that we should make the gem the installer. - why not include unit tests, user guides, API docs, and examples in the gem, or in a separate gem? Are gems not able to do things that one-click installers can do? ---Michael B. _____ From: wtr-core-bounces at rubyforge.org [mailto:wtr-core-bounces at rubyforge.org] On Behalf Of Bret Pettichord Sent: April 28, 2006 2:49 PM To: wtr-core at rubyforge.org Subject: Re: [Wtr-core] Gem vs. .exe First some additional facts: 1. The behavior you are seeing hasn't changed from Watir 1.4.1. 2. The one-click installer actually puts files in two locations: "bonus files" in c:/program files/watir and the library in c:/ruby/lib/ruby/1.8/site-lib (or something like that). The bonus files are the unit tests, user guide & api docs, and the examples. The one-click also installs some menu links. 3. The gem only installs the library, the unit tests and the api docs. Here's where i think we stand with the installers. Please let me know whether there is disagreement on these points. 1. The gem tends to be the more popular install option, but some people prefer the one-click. 2. It is confusing that the one-click and the gem install the (same) watir library in different locations. It is easy to get a situation where someone installed one version using one installer and then a newer one using a newer installer, and now isn't getting the version they expected when they require 'watir'. (I'm not sure which one trumps the other, nor whether this depends on how rubygems is installed in your system -- some testing of this would be welcome.) 3. We still get intermittent reports of errors with the one-click installer that we can't track down. In fact, originally the one-click installer was the main way to install Watir, then when the Gem thing came out we started using that. The one-click installer was really designed around the needs of the Scripting For Testers class -- easy to install from CD with no internet access. The gem concept is based on internet access, on the other hand, which is really the largest use case for our users. So here's is what i'm thinking we should do going forward... 1. Encourage the gem as the main installer for Watir. 2. Deprecate the one-clicker. If we keep it, we should probably make more consistent with the gem, perhaps even be a wrapper around the gem. But i'm not keen to sign up for this this, and i'm not really sure any one else is either. I recently updated the rakefile to automatically build the one-click installer -- assuming you have NSIS installed. I would leave this here so people could create one-click installers on their own, but would stop releasing it. (This is what i mean by deprecate.) 3. Release the "bonus files" that were in the one-clicker, but not the gem as a separate zip file. Contents: user guide & examples. This would also include pointers to the API docs and unit tests that would be in the gem. This is a little more complicated that the one-clicker, but in the end better because it would be teaching users how to get API docs for any gem, not just Watir. 4. Delete install.rb -- These was a precursor to the one-click installer and is broken and confuses people. Thoughts? Depending on the feedback i get on this, then I'll know how to answer Michael's questions. Bret On 4/28/06, Michael Bolton wrote: I note that when I install the gem, the Watir files go by default into c:/ruby/lib/ruby/gems/1.8/gems/watir-1.5.0.934 With the one-click install, I note that the default is in C:\Program Files\Watir The structure of the two installations seems quite different. In particular, the one-click installer includes examples where the gem installation doesn't. There are other differences in the directory structure. Before I put things into Jira, is this something about which I should expect big changes shortly? Is it worth testing? Or would you like me to track the discrepancies? ---Michael B. DevelopSense: Software Testing in Plain English Web Site: http://www.developsense.com Newsletter: addme at developsense.com Blog: http://www.developsense.com/blog.html _______________________________________________ Wtr-core mailing list Wtr-core at rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-core -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060501/ae35fcf8/attachment.htm From bret at pettichord.com Mon May 1 15:42:41 2006 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 1 May 2006 14:42:41 -0500 Subject: [Wtr-core] Gem vs. .exe In-Reply-To: <06b601c66d4b$5e580780$6601a8c0@Koko> References: <06b601c66d4b$5e580780$6601a8c0@Koko> Message-ID: For questions about the directory structure of Ruby and gems, i suggest you ask comp.lang.ruby. I'm sure there are people out there who relish their knowledge of this kind of arcana. For our purposes, the short answer is that we are following conventions. API docs and unit tests are in fact included in our gems. Gems are designed for Ruby libraries. NSIS (the one-click technology) is designed for anything. So yes, it can do lots more (e.g. update registry). Bret On 5/1/06, Michael Bolton wrote: > > I don't understand the reason for the depth of the paths that we're > using. Bret has said that Watir goes into c:/ruby/lib/ruby/1.8/site-lib. > Why? > > Something seems really haphazard about the organization of gems > altogether. I see stuff in > > C:\ruby\lib\ruby\gems\1.8\gems\watir-1.5.0.934 > > This seems deficient, in that we have two instances of "ruby" in the path, > and two instances of "gems" on the path, but only one instance each of " > 1.8" and "lib"--couldn't we throw a couple more 1.8s and libs in there > too, for balance? <-joke > > Seriously: > > - I agree that we should make the gem the installer. > - why not include unit tests, user guides, API docs, and examples in the > gem, or in a separate gem? Are gems not able to do things that one-click > installers can do? > > ---Michael B. > > > > ------------------------------ > *From:* wtr-core-bounces at rubyforge.org [mailto: > wtr-core-bounces at rubyforge.org] *On Behalf Of *Bret Pettichord > *Sent:* April 28, 2006 2:49 PM > > *To:* wtr-core at rubyforge.org > *Subject:* Re: [Wtr-core] Gem vs. .exe > > First some additional facts: > > 1. The behavior you are seeing hasn't changed from Watir 1.4.1. > 2. The one-click installer actually puts files in two locations: "bonus > files" in c:/program files/watir and the library in > c:/ruby/lib/ruby/1.8/site-lib (or something like that). The bonus files are > the unit tests, user guide & api docs, and the examples. The one-click also > installs some menu links. > 3. The gem only installs the library, the unit tests and the api docs. > > Here's where i think we stand with the installers. Please let me know > whether there is disagreement on these points. > > 1. The gem tends to be the more popular install option, but some people > prefer the one-click. > 2. It is confusing that the one-click and the gem install the (same) watir > library in different locations. It is easy to get a situation where someone > installed one version using one installer and then a newer one using a newer > installer, and now isn't getting the version they expected when they require > 'watir'. (I'm not sure which one trumps the other, nor whether this depends > on how rubygems is installed in your system -- some testing of this would be > welcome.) > 3. We still get intermittent reports of errors with the one-click > installer that we can't track down. > > In fact, originally the one-click installer was the main way to install > Watir, then when the Gem thing came out we started using that. The one-click > installer was really designed around the needs of the Scripting For Testers > class -- easy to install from CD with no internet access. The gem concept is > based on internet access, on the other hand, which is really the largest use > case for our users. > > So here's is what i'm thinking we should do going forward... > > 1. Encourage the gem as the main installer for Watir. > 2. Deprecate the one-clicker. If we keep it, we should probably make more > consistent with the gem, perhaps even be a wrapper around the gem. But i'm > not keen to sign up for this this, and i'm not really sure any one else is > either. I recently updated the rakefile to automatically build the one-click > installer -- assuming you have NSIS installed. I would leave this here so > people could create one-click installers on their own, but would stop > releasing it. (This is what i mean by deprecate.) > 3. Release the "bonus files" that were in the one-clicker, but not the gem > as a separate zip file. Contents: user guide & examples. This would also > include pointers to the API docs and unit tests that would be in the gem. > This is a little more complicated that the one-clicker, but in the end > better because it would be teaching users how to get API docs for any gem, > not just Watir. > 4. Delete install.rb -- These was a precursor to the one-click installer > and is broken and confuses people. > > Thoughts? Depending on the feedback i get on this, then I'll know how to > answer Michael's questions. > > Bret > > On 4/28/06, Michael Bolton wrote: > > > > I note that when I install the gem, the Watir files go by default into > > > > c:/ruby/lib/ruby/gems/1.8/gems/watir-1.5.0.934 > > > > With the one-click install, I note that the default is in > > > > C:\Program Files\Watir > > > > The structure of the two installations seems quite different. In > > particular, the one-click installer includes examples where the gem > > installation doesn't. There are other differences in the directory > > structure. > > > > Before I put things into Jira, is this something about which I should > > expect > > big changes shortly? Is it worth testing? Or would you like me to > > track > > the discrepancies? > > > > ---Michael B. > > > > DevelopSense: Software Testing in Plain English > > Web Site: http://www.developsense.com > > Newsletter: addme at developsense.com > > Blog: http://www.developsense.com/blog.html > > _______________________________________________ > > Wtr-core mailing list > > Wtr-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-core > > > > > _______________________________________________ > Wtr-core mailing list > Wtr-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-core > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060501/0ccb4c94/attachment-0001.htm From paul.rogers at shaw.ca Sun May 7 14:10:45 2006 From: paul.rogers at shaw.ca (Paul Rogers) Date: Sun, 07 May 2006 12:10:45 -0600 Subject: [Wtr-core] STARWEST proposals due May 1-- anyone want to teach SfT? In-Reply-To: <72799cd70604271234s24ae5319v2bd9db74c1beb1c6@mail.gmail.com> Message-ID: <01ed01c67201$8f6f07f0$6600a8c0@NewDell> Did anyone reply to this? I might be interested. I'll have to think about it. Know what the deadline is? Paul -----Original Message----- From: wtr-core-bounces at rubyforge.org [mailto:wtr-core-bounces at rubyforge.org] On Behalf Of Chris McMahon Sent: 27 April 2006 13:35 To: wtr-core at rubyforge.org Subject: [Wtr-core] STARWEST proposals due May 1-- anyone want to teach SfT? Hi... I just got a reminder email from the SQE people. I'm going to have taught Scripting for Testers at STAREAST and at Agile2006, and I'm really not interested in teaching it at STARWEST in the fall. Anyone else want to? It's a good class with Bret's open-source class materials. Decent stipend and expenses, too. http://www.sqe.com/starwest/speak.asp Anyone think we should ask on the general list also? -Chris _______________________________________________ Wtr-core mailing list Wtr-core at rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-core From christopher.mcmahon at gmail.com Sun May 7 20:19:50 2006 From: christopher.mcmahon at gmail.com (Chris McMahon) Date: Sun, 7 May 2006 17:19:50 -0700 Subject: [Wtr-core] STARWEST proposals due May 1-- anyone want to teach SfT? In-Reply-To: <01ed01c67201$8f6f07f0$6600a8c0@NewDell> References: <72799cd70604271234s24ae5319v2bd9db74c1beb1c6@mail.gmail.com> <01ed01c67201$8f6f07f0$6600a8c0@NewDell> Message-ID: <72799cd70605071719p32150097y153604ee8c496e9b@mail.gmail.com> On 5/7/06, Paul Rogers wrote: > Did anyone reply to this? I might be interested. I'll have to think > about it. Know what the deadline is? May 1 :) -Chris PS You could probably get in if you hurry hurry hurry. From paul.rogers at shaw.ca Sun May 7 21:37:01 2006 From: paul.rogers at shaw.ca (Paul Rogers) Date: Sun, 07 May 2006 19:37:01 -0600 Subject: [Wtr-core] STARWEST proposals due May 1-- anyone want to teach SfT? In-Reply-To: <72799cd70605071719p32150097y153604ee8c496e9b@mail.gmail.com> Message-ID: <000401c6723f$e79537e0$6600a8c0@NewDell> Well, I sure feel stupid ;-) Not sure if I have enough time for hurry this week. -----Original Message----- From: wtr-core-bounces at rubyforge.org [mailto:wtr-core-bounces at rubyforge.org] On Behalf Of Chris McMahon Sent: 07 May 2006 18:20 To: wtr-core at rubyforge.org Subject: Re: [Wtr-core] STARWEST proposals due May 1-- anyone want to teach SfT? On 5/7/06, Paul Rogers wrote: > Did anyone reply to this? I might be interested. I'll have to think > about it. Know what the deadline is? May 1 :) -Chris PS You could probably get in if you hurry hurry hurry. _______________________________________________ Wtr-core mailing list Wtr-core at rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-core From bret at pettichord.com Mon May 8 11:35:32 2006 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 8 May 2006 10:35:32 -0500 Subject: [Wtr-core] STARWEST proposals due May 1-- anyone want to teach SfT? In-Reply-To: <000401c6723f$e79537e0$6600a8c0@NewDell> References: <72799cd70605071719p32150097y153604ee8c496e9b@mail.gmail.com> <000401c6723f$e79537e0$6600a8c0@NewDell> Message-ID: If you are interested, i suggest that you immediately send SQE a note telling them you would like to do it and asking them if there is still time to submit a proposal. They've been very eager to have this class in the past. I'm also not sure that they'll really need a detailed proposal to make a decision if you are planning to base the class on the same Scripting101 materials that we've used before. Bret On 5/7/06, Paul Rogers wrote: > > Well, I sure feel stupid ;-) Not sure if I have enough time for hurry > this week. > > -----Original Message----- > From: wtr-core-bounces at rubyforge.org > [mailto:wtr-core-bounces at rubyforge.org] On Behalf Of Chris McMahon > Sent: 07 May 2006 18:20 > To: wtr-core at rubyforge.org > Subject: Re: [Wtr-core] STARWEST proposals due May 1-- anyone want to > teach SfT? > > > On 5/7/06, Paul Rogers wrote: > > Did anyone reply to this? I might be interested. I'll have to think > > about it. Know what the deadline is? > > May 1 > > :) > > -Chris > > PS You could probably get in if you hurry hurry hurry. > > _______________________________________________ > Wtr-core mailing list > Wtr-core at rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-core > > _______________________________________________ > Wtr-core mailing list > Wtr-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-core > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060508/2643d849/attachment.htm From christopher.mcmahon at gmail.com Mon May 8 19:40:36 2006 From: christopher.mcmahon at gmail.com (Chris McMahon) Date: Mon, 8 May 2006 16:40:36 -0700 Subject: [Wtr-core] anyone have a high-res version of the Watir logo? Message-ID: <72799cd70605081640i9e43412m68b4769b2a13e579@mail.gmail.com> I only found the little one that used to be on the wiki. -Chris From bret at pettichord.com Mon May 8 23:42:44 2006 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 8 May 2006 22:42:44 -0500 Subject: [Wtr-core] anyone have a high-res version of the Watir logo? In-Reply-To: <72799cd70605081640i9e43412m68b4769b2a13e579@mail.gmail.com> References: <72799cd70605081640i9e43412m68b4769b2a13e579@mail.gmail.com> Message-ID: Have you checked the logos in SVN? Jonathan Kohl originally commissioned the logo from Jacinda Scott and may know how to get in touch with her. On 5/8/06, Chris McMahon wrote: > > I only found the little one that used to be on the wiki. > -Chris > > _______________________________________________ > Wtr-core mailing list > Wtr-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-core > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060508/0ab97934/attachment.htm From paul.rogers at shaw.ca Mon May 8 23:42:56 2006 From: paul.rogers at shaw.ca (Paul Rogers) Date: Mon, 08 May 2006 21:42:56 -0600 Subject: [Wtr-core] STARWEST proposals due May 1-- anyone want to teach SfT? In-Reply-To: References: <72799cd70605071719p32150097y153604ee8c496e9b@mail.gmail.com> <000401c6723f$e79537e0$6600a8c0@NewDell> Message-ID: thanks - Ive sent them a note. I'll let you know what happens Thanks Paul -------------- next part -------------- _______________________________________________ Wtr-core mailing list Wtr-core at rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-core From bret at pettichord.com Wed May 10 10:23:36 2006 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 10 May 2006 09:23:36 -0500 Subject: [Wtr-core] WATIR: future of this project In-Reply-To: <20060510101208.28625.qmail@web25711.mail.ukl.yahoo.com> References: <20060510101208.28625.qmail@web25711.mail.ukl.yahoo.com> Message-ID: Cameron, I'm glad you are happy with Watir. Thank you for sharing your experiences. We are actively working on Watir 1.5. We are moving the project over to OpenQA.org, which is why our site on Rubyforge.org appears to be dormant. You should subscribe to the wtr-general mailing list at Rubyforge, which is still very active. And please look at our new wiki site where you'll find updated infromation about Watir, including development builds of 1.5. http://wiki.openqa.org/display/WTR/Project+Home Please put your suggestions and bug reports in our new Jira bug tracking system on OpenQA.org. Bret On 5/10/06, Cameron Smith wrote: > > Hi Bret, I am a SW engineer running a project in > Mozambique. We have had a very positive experience > with Watir, which we decided to use from the get-go on > our project. That is, any developer making/changing > a feature, will not only alter the code and the > UnitTests, but also the Watir tests. > > This gives us enormous confidence and flexibility in > refactoring core internal functionality, and adding > new features rapidly. > > However there are several aspects of Watir which could > be improved and/or fixed. Before we consider either > submitting feature requests, or doing them ourselves, > I checked wtr.rubyforge.net to look at the project's > recent activity. > > And it seems that the project has effectively been > dormant since v1.4.1 last year. All I would like to > do with this email, is confirm what the status of the > project is? If it is in fact relatively dormant, that > will help us make the decision to make our own > localized version of Watir. If not, I'd be happy to > write up the bugs and feature requests and submit them > to the feature tracker. > > In any case, very well done to all you guys for such > an excellent tool. VERY rarely have I invested so > little time setting up a tool on a project and got > such a large return. > > keep up the good work, > Cameron Smith, > Maputo, > Mozambique > > > > ___________________________________________________________ > Yahoo! Photos ? NEW, now offering a quality print service from just 7p a > photo http://uk.photos.yahoo.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060510/6dd74d77/attachment.htm From bret at pettichord.com Sun May 14 20:27:54 2006 From: bret at pettichord.com (Bret Pettichord) Date: Sun, 14 May 2006 19:27:54 -0500 Subject: [Wtr-core] Win32API to DL? In-Reply-To: <446776BE.2060206@tower-mt.com> References: <446776BE.2060206@tower-mt.com> Message-ID: I agree that it is good to move from Win32API to DL. Bret On 5/14/06, David Schmidt wrote: > > Bret, > > The WET code uses DL instead of Win32API and though I was able to convert > the one call I used, the methods WET uses to enumerate windows is a bit more > complicated as it involves setting up a callback which is called for every > window. > > In the Pickaxe book I found the following under Win32API: > > *"As the DL library is newer, this may be a sign that the original > Win32API may be phased out over time." > > *What do you think about converting over to using the DL library for all > our Windows calls? Check out the WinUtils.rb file from WET to see how > that would look compared to our current Win32API version. > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060514/7084e63e/attachment-0001.htm From bret at pettichord.com Wed May 17 20:03:52 2006 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 17 May 2006 19:03:52 -0500 Subject: [Wtr-core] Interesting problems creating/testing method_name In-Reply-To: <446B95C9.5010606@tower-mt.com> References: <446B57F6.2010103@tower-mt.com> <446B95C9.5010606@tower-mt.com> Message-ID: David, I got your IM message. I don't have a strong preference about the tests. Please let me know when the code is ready and then i will review it. Yesterday, I was trying to encourage you to take on a style of development, where you did a small amount of coding, finished it with tests and then we could review it and commit it to trunk. You've said that you prefer more of a big bang approach. That is fine, but it means that you will be going off on a limb farther before you get substansive review and you risk going in a direction that i'm unhappy with. It also takes on the risk that trunk will have moved further from your branch point, thus making the merge more difficult. In retrospect, i think it might have been better for you simply to extend the eval_in_spawned_process to cover the classes that you needed (Frames?) rather than try and create very general support. It could always have been generalized later. In fact, if you are still bogged down with this, you might consider this approach. I appreciate your work very much, but am concerned that the high value work (both to you and others) is being delayed because you started with code changes that were not needed to make your tests pass (thus untested and unnecessary for the immediate purpose) that seemed easy to you at the time, but when you realized were more involved were reluctant to back away from. I'm including other members of the wtr-core team in this discussion, as i suspect some of them may benefit from it, or have suggestions. We are discussing David's work in branch/modal-dialog, which includes many enhancements and fixes, including much-improved support for modal web dialogs. Bret On 5/17/06, David Schmidt wrote: > > Have you been getting my IM's today? How about the changes to > to_identifier, the new method_name code and the new tests? I didn't > know whether you wanted lots of tests with few asserts each, or one test > with many asserts. Which do you prefer? > > BTW, the method below basically *does* the metaclass programming though > with a different syntax. The tricky part that was difficult to get > around was that this isn't a class adding new methods, it's a module. > This changes the value of "self" to be the module ("Container") instead > of the class that you're extending ("IE" in this case). > > David > > Bret Pettichord wrote: > > I think the right way to do this would be to use a meta-class -- that > > would put the method on the class itself, without having it flow to > > the instances. > > > > http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html > > > > I can put this in when the code is ready for my review. > > > > Bret > > > > On 5/17/06, * David Schmidt* > > wrote: > > > > Bret, > > > > This is just for your information to let you know how the > method_name > > method is written, and why. Last night I re-factored > > to_identifier and > > created a method called module_name in Container which can be > > overridden > > in any class. This works fine, so we can do things like: > > > > ie = IE.attach(...) > > ie.method_name -> "ie" > > ie.button(:id, 'blat').method_name -> "button" > > ie.popup(...).method_name -> "popup" > > > > etc. > > > > However, this is a real pain to test, because we need to instantiate > > each element in order to test method_name for every class. > > > > I tried to make this a class method by defining it as "def > > self.method_name" and then I can test the overridden classes like: > > > > PopUp.method_name -> "popup" > > TableCell.method_name -> "cell" > > > > But the method in container becomes Container::method_name instead > of > > ::method_name so it fails for any class that doesn't override > > method_name. ( i.e., "IE.method_name" fails). I tried overriding > > method_name in the IE class, and then calling > Container::method_name, > > but the "self" in method_name became "Container" instead of the real > > class. *sigh*. > > > > Next iteration I got help from my cohort here who is a Ruby expert. > > After going through a number of iterations I finally came up with > the > > following code. By putting this into Container I was able to get > the > > class method working consistently for testing *and* also have it > work > > for instantiated class objects. > > > > def self.included(base) > > base.extend(ClassMethods) > > base.send(:include, ClassMethods) > > end > > > > module ClassMethods > > def method_name > > self.methods_class_name.sub('Watir::', ''). > > gsub(/::/, '/'). > > gsub(/([A-Z]+)([A-Z][a-z])/,'\1_\2'). > > gsub(/([a-z\d])([A-Z])/,'\1_\2'). > > tr("-", "_"). > > downcase > > end > > def methods_class_name > > if Class == self.class > > self.to_s > > else > > self.class.to_s > > end > > end > > end > > > > Now testing works without having to instantiate each class: > > > > IE.method_name -> "ie" > > PopUp.method_name -> "popup" > > > > but the *same* code is run for an instantiated class: > > > > ie = IE.new > > IE.method_name -> "ie" > > ie.method_name -> "ie" > > b = ie.button(:id, 'nosuch') > > b.method_name -> "button" > > > > I'll have the new test done quickly, and will also fully document > what > > this new code does, and why, in the source file. > > > > David > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060517/b6ba376c/attachment.htm From davids at tower-mt.com Thu May 18 15:42:16 2006 From: davids at tower-mt.com (David Schmidt) Date: Thu, 18 May 2006 12:42:16 -0700 Subject: [Wtr-core] Interesting problems creating/testing method_name In-Reply-To: References: <446B57F6.2010103@tower-mt.com> <446B95C9.5010606@tower-mt.com> Message-ID: <446CCE18.2060405@tower-mt.com> Bret Pettichord wrote: > David, > > I got your IM message. I don't have a strong preference about the > tests. Please let me know when the code is ready and then i will > review it. Since most of the method_name tests are alike I left them all in one test, which runs REAL fast: C:\Documents and Settings\davids\My Documents\Rails\modal_dialog>unittests\method_names_test.rb Loaded suite C:/Documents and Settings/davids/My Documents/Rails/modal_dialog/unittests/method_names_test Started . Finished in 0.015 seconds. 1 tests, 55 assertions, 0 failures, 0 errors I've started working on the to_identifier tests and with those I used a separate test for each element type and :how since I'm opening different web pages so I can instantiate a Watir object for each "how" and verify that the to_identify properly identifies each object. Check it out if you like and let me know if you see anything I'm missing. > Yesterday, I was trying to encourage you to take on a style of > development, where you did a small amount of coding, finished it with > tests and then we could review it and commit it to trunk. You've said > that you prefer more of a big bang approach. That is fine, but it > means that you will be going off on a limb farther before you get > substansive review and you risk going in a direction that i'm unhappy > with. It also takes on the risk that trunk will have moved further > from your branch point, thus making the merge more difficult. The only difference between what I've been doing and what you're saying here is that you want each small change merged to trunk more often while I'm making fixes as I find problems as I also have a work project that's depending on some of these fixed. The click_no_wait code working for frames is required for my work project and that required the changes to eval_in_spawned_process and the addition of the to_identifier and method_name methods. I have code depending on Frame.html which required the simple fix of moving some methods from IE to Container. Lastly, I added the modal_dialog/ModalDialog to give us the capability to get full access to the modal dialogs. These are all things I had to do for my work project, but I wanted to contribute back to the community, especially with the modal dialog support which has driven so many of us crazy. I've also been working on adding tests for everything I've changed/added, even for fixes on things I didn't originally add or break. > In retrospect, i think it might have been better for you simply to > extend the eval_in_spawned_process to cover the classes that you > needed (Frames?) rather than try and create very general support. It > could always have been generalized later. In fact, if you are still > bogged down with this, you might consider this approach. I'm not quite certain what you're referring to here. The change to eval_in_spawned_process was to take out the fixed string to connect to "Watir::IE.attach(:title, '#{title}');", which doesn't work when a user is running concurrent IE's, and the to_identifier method creates a string which starts with "IE.attach(:hwnd, ) which will connect to the exact window calling eval_in_spawned_process. I also added the "include Watir;" so that to_identifier wouldn't have to add it. Eval_in_spawned_process is working fine. > I appreciate your work very much, but am concerned that the high value > work (both to you and others) is being delayed because you started > with code changes that were not needed to make your tests pass (thus > untested and unnecessary for the immediate purpose) that seemed easy > to you at the time, but when you realized were more involved were > reluctant to back away from. Delayed? I feel I've added quite a bit of *working* code and tests in the five days I've been contributing to this project. The only reason I didn't want to "back out" my changes was that we're on a test branch so there's NO risk leaving things in, even when we have a problem. I really don't see your down side, because if you don't like the changes you just don't merge to trunk. We can even edit patches or create side branches if required. So far, the only task that wasn't necessary to get my code to run was the refactoring of to_identify to let each object generate it's own part of the string instead of generating the entire string in one function call, and I did that because *you* requested it. I've been trying to follow *all* of your requests, except for not checking in new code to the test branch, even though it doesn't affect anyone. The only reason we had problems the other day was because all the tests were passing on my systems, and only failing on yours (which shows that my tests WERE there and did their job). We later identified the difference between our two systems and fixed the code so that the tests now pass on your system too, which validated the test process. I've worked on very large development teams, where we had 20+ developers working on the *same* monolithic program for an embedded system. Each engineer had multiple branches and merges and partial merges were a regular occurrence, especially approaching releases. I don't have many things left before we can start looking to merge back to trunk, and some of those could be deferred too. I'd like to get regexp :title searches for modal dialogs and I want to complete the to_identifier tests to make sure any object will work with eval_in_spawned_process (modal_page doesn't work right now). Method_name works now, both as a class method (for testing) and as an instance method for normal use, and I'm testing every class that includes method_name, even classes that don't expose a method (though I commented those). Method name is also properly overridden for all but the modal_page class (which inherits from IE instead of including Container). Check out my commit logs and let me know what you want from me. Perhaps another branch called "modal_dialog_testing" where we merge small changes from the modal_dialogs branch so you can evaluate smaller changes before merging to trunk? Just let me know what you want, as I'm trying to contribute here. It's just that backing things out of a test branch doesn't make any sense, especially when it's *working* code! I'd also invite the other core members to check out from branches/modal_dialog and try out the new code and tests. Also check out the log messages and let me know where I can do better. David > I'm including other members of the wtr-core team in this discussion, > as i suspect some of them may benefit from it, or have suggestions. We > are discussing David's work in branch/modal-dialog, which includes > many enhancements and fixes, including much-improved support for modal > web dialogs. > > Bret > > On 5/17/06, *David Schmidt* > wrote: > > Have you been getting my IM's today? How about the changes to > to_identifier, the new method_name code and the new tests? I didn't > know whether you wanted lots of tests with few asserts each, or > one test > with many asserts. Which do you prefer? > > BTW, the method below basically *does* the metaclass programming > though > with a different syntax. The tricky part that was difficult to get > around was that this isn't a class adding new methods, it's a module. > This changes the value of "self" to be the module ("Container") > instead > of the class that you're extending ("IE" in this case). > > David > > Bret Pettichord wrote: > > I think the right way to do this would be to use a meta-class -- > that > > would put the method on the class itself, without having it flow to > > the instances. > > > > > http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html > > > > > I can put this in when the code is ready for my review. > > > > Bret > > > > On 5/17/06, * David Schmidt* > > >> wrote: > > > > Bret, > > > > This is just for your information to let you know how the > method_name > > method is written, and why. Last night I re-factored > > to_identifier and > > created a method called module_name in Container which can be > > overridden > > in any class. This works fine, so we can do things like: > > > > ie = IE.attach(...) > > ie.method_name -> "ie" > > ie.button(:id, 'blat').method_name -> "button" > > ie.popup(...).method_name -> "popup" > > > > etc. > > > > However, this is a real pain to test, because we need to > instantiate > > each element in order to test method_name for every class. > > > > I tried to make this a class method by defining it as "def > > self.method_name" and then I can test the overridden classes > like: > > > > PopUp.method_name -> "popup" > > TableCell.method_name -> "cell" > > > > But the method in container becomes Container::method_name > instead of > > ::method_name so it fails for any class that doesn't > override > > method_name. ( i.e., "IE.method_name " fails). I tried > overriding > > method_name in the IE class, and then calling > Container::method_name, > > but the "self" in method_name became "Container" instead of > the real > > class. *sigh*. > > > > Next iteration I got help from my cohort here who is a Ruby > expert. > > After going through a number of iterations I finally came up > with the > > following code. By putting this into Container I was able > to get the > > class method working consistently for testing *and* also > have it work > > for instantiated class objects. > > > > def self.included(base) > > base.extend(ClassMethods) > > base.send(:include, ClassMethods) > > end > > > > module ClassMethods > > def method_name > > self.methods_class_name.sub('Watir::', ''). > > gsub(/::/, '/'). > > gsub(/([A-Z]+)([A-Z][a-z])/,'\1_\2'). > > gsub(/([a-z\d])([A-Z])/,'\1_\2'). > > tr("-", "_"). > > downcase > > end > > def methods_class_name > > if Class == self.class > > self.to_s > > else > > self.class.to_s > > end > > end > > end > > > > Now testing works without having to instantiate each class: > > > > IE.method_name -> "ie" > > PopUp.method_name -> "popup" > > > > but the *same* code is run for an instantiated class: > > > > ie = IE.new > > IE.method_name -> "ie" > > ie.method_name -> "ie" > > b = ie.button(:id, 'nosuch') > > b.method_name -> "button" > > > > I'll have the new test done quickly, and will also fully > document what > > this new code does, and why, in the source file. > > > > David > > > > > > > From bret at pettichord.com Sat May 20 15:05:06 2006 From: bret at pettichord.com (Bret Pettichord) Date: Sat, 20 May 2006 14:05:06 -0500 Subject: [Wtr-core] Interesting problems creating/testing method_name In-Reply-To: <446CCE18.2060405@tower-mt.com> References: <446B57F6.2010103@tower-mt.com> <446B95C9.5010606@tower-mt.com> <446CCE18.2060405@tower-mt.com> Message-ID: David, Last night i merged your modal dialog changes in to trunk. I see no reason to have two classes (ModalPage and ModalDialog) for the same object. I plan to merge these two classes together, although they are both in trunk at the moment. Thank you for your contributions. Since your requirement is that click_no_wait work in frames, i suggest that we get that right first, and then worry how (and whether) to generalize that further at a later date. I am concerned about the maintenance costs of the approach that you've used. I do not consider it to be meta-programming in the sense of the article that i referenced. For me, the easiest way to move forward would be to create a branch (or patch) that only included the tests and code to extend click_no_wait to frames, without many of the other changes that you have in the modal branch. You also should note that the modal branch is deviating further from trunk. I've also committed fixes from several other contributors in the past week. You may want to consider merging trunk into the modal branch to narrow the gap going forward. A general concern i have about many of the minor changes you've made is that you've moved methods e.g. to the Container class, but do not have tests of them for most of the classes that inherit this. You have rejected some of my suggestions because your code is "working", but in the absence of these tests, i consider this to be unproven. I created a new module PageContainer which is intended for classes that host entire html pages: IE, Frames, Modals. In some cases the methods that you were attaching to Container can more safely be put here. For me, the best approach is to make changes in a specific area. Make sure they are well tested, and then commit them to trunk. Next we can look at generalizing those changes or moving on to perhaps related areas. For example, right now, i am still digesting how to use the Modal Dialog code the best way. I also believe that once we have working code, it is pretty easy to modify interfaces and refactor the implementation, which is why i like to get working (i.e. tested) code as soon as possible. You've asked for suggestions and i've given them. In many cases, you responded with why you like your approach better. That is fine, but this is how i work. It is very difficult for me to review code when there are lots of changes to different areas, each with different levels of testing. I get contributions from lots of of different people, so i hope you can understand why i work this way. Please let me know when you have specific, tested changes that are complete and ready to be committed to trunk. I will be happy to review them. Bret On 5/18/06, David Schmidt wrote: > > Bret Pettichord wrote: > > David, > > > > I got your IM message. I don't have a strong preference about the > > tests. Please let me know when the code is ready and then i will > > review it. > Since most of the method_name tests are alike I left them all in one > test, which runs REAL fast: > > C:\Documents and Settings\davids\My > Documents\Rails\modal_dialog>unittests\method_names_test.rb > Loaded suite C:/Documents and Settings/davids/My > Documents/Rails/modal_dialog/unittests/method_names_test > Started > . > Finished in 0.015 seconds. > > 1 tests, 55 assertions, 0 failures, 0 errors > > I've started working on the to_identifier tests and with those I used a > separate test for each element type and :how since I'm opening different > web pages so I can instantiate a Watir object for each "how" and verify > that the to_identify properly identifies each object. Check it out if > you like and let me know if you see anything I'm missing. > > Yesterday, I was trying to encourage you to take on a style of > > development, where you did a small amount of coding, finished it with > > tests and then we could review it and commit it to trunk. You've said > > that you prefer more of a big bang approach. That is fine, but it > > means that you will be going off on a limb farther before you get > > substansive review and you risk going in a direction that i'm unhappy > > with. It also takes on the risk that trunk will have moved further > > from your branch point, thus making the merge more difficult. > The only difference between what I've been doing and what you're saying > here is that you want each small change merged to trunk more often while > I'm making fixes as I find problems as I also have a work project that's > depending on some of these fixed. The click_no_wait code working for > frames is required for my work project and that required the changes to > eval_in_spawned_process and the addition of the to_identifier and > method_name methods. I have code depending on Frame.html which required > the simple fix of moving some methods from IE to Container. Lastly, I > added the modal_dialog/ModalDialog to give us the capability to get full > access to the modal dialogs. > > These are all things I had to do for my work project, but I wanted to > contribute back to the community, especially with the modal dialog > support which has driven so many of us crazy. > > I've also been working on adding tests for everything I've > changed/added, even for fixes on things I didn't originally add or break. > > In retrospect, i think it might have been better for you simply to > > extend the eval_in_spawned_process to cover the classes that you > > needed (Frames?) rather than try and create very general support. It > > could always have been generalized later. In fact, if you are still > > bogged down with this, you might consider this approach. > I'm not quite certain what you're referring to here. The change to > eval_in_spawned_process was to take out the fixed string to connect to > "Watir::IE.attach(:title, '#{title}');", which doesn't work when a user > is running concurrent IE's, and the to_identifier method creates a > string which starts with "IE.attach(:hwnd, ) which will connect to > the exact window calling eval_in_spawned_process. I also added the > "include Watir;" so that to_identifier wouldn't have to add it. > Eval_in_spawned_process is working fine. > > I appreciate your work very much, but am concerned that the high value > > work (both to you and others) is being delayed because you started > > with code changes that were not needed to make your tests pass (thus > > untested and unnecessary for the immediate purpose) that seemed easy > > to you at the time, but when you realized were more involved were > > reluctant to back away from. > Delayed? I feel I've added quite a bit of *working* code and tests in > the five days I've been contributing to this project. The only reason I > didn't want to "back out" my changes was that we're on a test branch so > there's NO risk leaving things in, even when we have a problem. I > really don't see your down side, because if you don't like the changes > you just don't merge to trunk. We can even edit patches or create side > branches if required. So far, the only task that wasn't necessary to > get my code to run was the refactoring of to_identify to let each object > generate it's own part of the string instead of generating the entire > string in one function call, and I did that because *you* requested it. > I've been trying to follow *all* of your requests, except for not > checking in new code to the test branch, even though it doesn't affect > anyone. > > The only reason we had problems the other day was because all the tests > were passing on my systems, and only failing on yours (which shows that > my tests WERE there and did their job). We later identified the > difference between our two systems and fixed the code so that the tests > now pass on your system too, which validated the test process. > > I've worked on very large development teams, where we had 20+ developers > working on the *same* monolithic program for an embedded system. Each > engineer had multiple branches and merges and partial merges were a > regular occurrence, especially approaching releases. > > I don't have many things left before we can start looking to merge back > to trunk, and some of those could be deferred too. I'd like to get > regexp :title searches for modal dialogs and I want to complete the > to_identifier tests to make sure any object will work with > eval_in_spawned_process (modal_page doesn't work right now). > > Method_name works now, both as a class method (for testing) and as an > instance method for normal use, and I'm testing every class that > includes method_name, even classes that don't expose a method (though I > commented those). Method name is also properly overridden for all but > the modal_page class (which inherits from IE instead of including > Container). > > Check out my commit logs and let me know what you want from me. Perhaps > another branch called "modal_dialog_testing" where we merge small > changes from the modal_dialogs branch so you can evaluate smaller > changes before merging to trunk? Just let me know what you want, as I'm > trying to contribute here. It's just that backing things out of a test > branch doesn't make any sense, especially when it's *working* code! > > I'd also invite the other core members to check out from > branches/modal_dialog and try out the new code and tests. Also check > out the log messages and let me know where I can do better. > > David > > I'm including other members of the wtr-core team in this discussion, > > as i suspect some of them may benefit from it, or have suggestions. We > > are discussing David's work in branch/modal-dialog, which includes > > many enhancements and fixes, including much-improved support for modal > > web dialogs. > > > > Bret > > > > On 5/17/06, *David Schmidt* > > wrote: > > > > Have you been getting my IM's today? How about the changes to > > to_identifier, the new method_name code and the new tests? I didn't > > know whether you wanted lots of tests with few asserts each, or > > one test > > with many asserts. Which do you prefer? > > > > BTW, the method below basically *does* the metaclass programming > > though > > with a different syntax. The tricky part that was difficult to get > > around was that this isn't a class adding new methods, it's a > module. > > This changes the value of "self" to be the module ("Container") > > instead > > of the class that you're extending ("IE" in this case). > > > > David > > > > Bret Pettichord wrote: > > > I think the right way to do this would be to use a meta-class -- > > that > > > would put the method on the class itself, without having it flow > to > > > the instances. > > > > > > > > http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html > > > > > > > > I can put this in when the code is ready for my review. > > > > > > Bret > > > > > > On 5/17/06, * David Schmidt* > > > > >> wrote: > > > > > > Bret, > > > > > > This is just for your information to let you know how the > > method_name > > > method is written, and why. Last night I re-factored > > > to_identifier and > > > created a method called module_name in Container which can be > > > overridden > > > in any class. This works fine, so we can do things like: > > > > > > ie = IE.attach(...) > > > ie.method_name -> "ie" > > > ie.button(:id, 'blat').method_name -> "button" > > > ie.popup(...).method_name -> "popup" > > > > > > etc. > > > > > > However, this is a real pain to test, because we need to > > instantiate > > > each element in order to test method_name for every class. > > > > > > I tried to make this a class method by defining it as "def > > > self.method_name" and then I can test the overridden classes > > like: > > > > > > PopUp.method_name -> "popup" > > > TableCell.method_name -> "cell" > > > > > > But the method in container becomes Container::method_name > > instead of > > > ::method_name so it fails for any class that doesn't > > override > > > method_name. ( i.e., "IE.method_name " fails). I tried > > overriding > > > method_name in the IE class, and then calling > > Container::method_name, > > > but the "self" in method_name became "Container" instead of > > the real > > > class. *sigh*. > > > > > > Next iteration I got help from my cohort here who is a Ruby > > expert. > > > After going through a number of iterations I finally came up > > with the > > > following code. By putting this into Container I was able > > to get the > > > class method working consistently for testing *and* also > > have it work > > > for instantiated class objects. > > > > > > def self.included(base) > > > base.extend(ClassMethods) > > > base.send(:include, ClassMethods) > > > end > > > > > > module ClassMethods > > > def method_name > > > self.methods_class_name.sub('Watir::', ''). > > > gsub(/::/, '/'). > > > gsub(/([A-Z]+)([A-Z][a-z])/,'\1_\2'). > > > gsub(/([a-z\d])([A-Z])/,'\1_\2'). > > > tr("-", "_"). > > > downcase > > > end > > > def methods_class_name > > > if Class == self.class > > > self.to_s > > > else > > > self.class.to_s > > > end > > > end > > > end > > > > > > Now testing works without having to instantiate each class: > > > > > > IE.method_name -> "ie" > > > PopUp.method_name -> "popup" > > > > > > but the *same* code is run for an instantiated class: > > > > > > ie = IE.new > > > IE.method_name -> "ie" > > > ie.method_name -> "ie" > > > b = ie.button(:id, 'nosuch') > > > b.method_name -> "button" > > > > > > I'll have the new test done quickly, and will also fully > > document what > > > this new code does, and why, in the source file. > > > > > > David > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060520/f6378022/attachment-0001.htm From davids at tower-mt.com Sat May 20 23:11:48 2006 From: davids at tower-mt.com (David Schmidt) Date: Sat, 20 May 2006 20:11:48 -0700 Subject: [Wtr-core] Interesting problems creating/testing method_name In-Reply-To: References: <446B57F6.2010103@tower-mt.com> <446B95C9.5010606@tower-mt.com> <446CCE18.2060405@tower-mt.com> Message-ID: <446FDA74.3060105@tower-mt.com> An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060520/5bd59dca/attachment.htm From davids at tower-mt.com Mon May 22 14:28:24 2006 From: davids at tower-mt.com (David Schmidt) Date: Mon, 22 May 2006 11:28:24 -0700 Subject: [Wtr-core] Interesting problems creating/testing method_name In-Reply-To: References: <446B57F6.2010103@tower-mt.com> <446B95C9.5010606@tower-mt.com> <446CCE18.2060405@tower-mt.com> Message-ID: <447202C8.7060103@tower-mt.com> (Resending without HTML for wtr-core) Bret, I have to admit to being very confused. After stressing so hard about having tests for everything complete before any item gets merged back to trunk the modal dialog changes are merged in without any discussion. In fact, I have more changes on my local system and I wasn't even asked to commit to bring the branch up to date. At NO point have I urged moving my branch back to trunk without having the tests complete and before having some open group discussion. I also don't understand your comments about click_no_wait. It's working fine on the modal_dialog branch though I'm still writing tests to cover all of the pieces that contribute to making click_no_wait work everywhere. Click_no_wait works from frames and from within modal dialogs, even from modal dialogs *within* modal dialogs, which I checked manually after you told me that you have such a situation. In my last e-mail I mentioned that once tests had been completed and the code checked over we could do partial merges to trunk if necessary, but why was this done so quickly? More comments inline below. Bret Pettichord wrote: > David, > > Last night i merged your modal dialog changes in to trunk. I see no > reason to have two classes (ModalPage and ModalDialog) for the same > object. I plan to merge these two classes together, although they are > both in trunk at the moment. As you and the others decide which version you prefer, let me tell why I created my own class rather than use the ModalPage version and what I've found writing tests for them both since then. Since a modal dialog is created using it's own URL, it most closely resembles a Frame or the base IE object. Unlike the IE object though, it doesn't have a WebBrowser component, though it does have a DOM Document. A modal dialog does have it's own window handle (HWND), though it cannot be directly retrieved from the base IE object. I decided that the modal dialog most closely resembles Frames, and should include the Container module because a modal dialog may contain frames or any other container (including other modal dialogs!). Since the ModalPage class and related command didn't conflict with my ModalDialog, I just left both in. In testing, I did find some difficulties getting the ModalPage class working from within Frames or other ModalDialogs. ModalPage inherits from IE, unlike Frames and ModalDialogs, and attempts to keep a WebBrowser item (IE.ie). However, since a modal dialog doesn't have a WebBrowser object, ModalPage just saves another copy of the IE.ie object. This make it a bit more difficult to track the HWND of the modal dialog, which is required to support modal dialogs spawned by other modal dialogs. I found the ModalDialog much easier to support and extend as it acts just like any other container and doesn't need to be instantiated differently. For example, the following Watir code works fine to find a modal dialog from within a frame and access objects within: ie = IE.attach(, ) modal = ie.frame(, ).modal_dialog # An IE instance can only have ONE child modal at a time modal.text_field(:text, 'Fill me').set('new data') modal.button(:id, 'OK').click > Thank you for your contributions. > > Since your requirement is that click_no_wait work in frames, i suggest > that we get that right first, and then worry how (and whether) to > generalize that further at a later date. I am concerned about the > maintenance costs of the approach that you've used. I do not consider > it to be meta-programming in the sense of the article that i referenced. > > For me, the easiest way to move forward would be to create a branch > (or patch) that only included the tests and code to extend > click_no_wait to frames, without many of the other changes that you > have in the modal branch. As part of the modal dialog changes I found that many things weren't working from the current Frame object. Click_no_wait(), html() and text() (and some other methods like "show_frames" were all failing within frames and modal dialogs, and the reason was that those functions were implemented in the IE class and Frame and ModalDialog are no longer inherited from IE, though they all mix in the Container module. The easy fix for all but click_no_wait was to move those methods from the IE class to the Container module so they'd be available to any container. This worked, and the previous functionality was restored. (Frame.html had failed in code I tried under Watir 1.5) The problem was a bit more difficult for click_no_wait(). In order to do a non-blocking click the click must be performed from another process (where it *will* still block) which allows the primary process to continue without blocking. This is done by spawning off a small Ruby script which sets the search path, requires Watir and then instantiates a Watir element and performs the click on that element. In order for this to work, we must re-create the Watir commands/classes from our current object. To do this, I wrote the method to_identifier() which re-creates the Watir structure in one string. For example, to_identifier() output for a button located inside a frame might look like "IE.attach(:hwnd, ).frame(:id, 'main_frame').button(:text, \"clickme\")". (Note that I also added the :hwnd "how" to the IE class which allows us to make SURE we're clicking in the right window from the background process, even if multiple, concurrent IE windows are open with the same title.) The 1.5 tree made it quite easy to implement the to_identifier() class because now each container was saving the "how" and "what" values used for their instantiation. One thing that was missing was a way to determine the method used to instantiate that class. Most of the methods were the "underline" versions of their class names. I.E, class "ModalDialog" used the method "modal_dialog" and class "TextField" used method "text_field". For these I used some code from Ruby on Rails and created a method named "method_name" in the Container module. For those classes where the method name didn't conform to this (like method "cell" for class "TableCell") I simply overode the method_name method in the particular class. method_names_test.rb tests *every* class which inherits the method_names method, even a few which can't be directly instantiated (which tests explain) and makes sure that the proper method actually exists with the name from method_names(). Loaded suite C:/Documents and Settings/davids/My Documents/Rails/modal_dialog/unittests/method_names_test Started . Finished in 0.0 seconds. 1 tests, 55 assertions, 0 failures, 0 errors to_identifier_test is still being worked on, because in it I attempt to test *every* "how" value for every element. This is done by navigating to one of the test HTML pages, instantiating an object from that page and then making sure that to_identifier can properly re-create the string used to select that object. I'm actively working on these tests, and they *have* found some problems so they're doing their job. > You also should note that the modal branch is deviating further from > trunk. I've also committed fixes from several other contributors in > the past week. You may want to consider merging trunk into the modal > branch to narrow the gap going forward. I was always planning on merging trunk to my working branch and running all tests before merging back to trunk. > A general concern i have about many of the minor changes you've made > is that you've moved methods e.g. to the Container class, but do not > have tests of them for most of the classes that inherit this. You have > rejected some of my suggestions because your code is "working", but in > the absence of these tests, i consider this to be unproven. I'm not sure of what "rejections" you are referring to? You said you wanted tests for all I'm adding, and I'm writing them, and have currently added over 100 new asserts, 92 of them in two totally new tests. My fix of moving methods from IE to Container was required to get my own work scripts working again. After all, I'm working on a piece of production code and I have to get that running. I *did* resist "backing out" changes I'd made in the modal_dialog branch when you were unable to run tests I'd run successfully. This was because we needed to fix the problem, not yank code from a branch that nobody but the two of us was using. We did just this, when you found the problem which didn't occur on my machine and came up with a fix. I can't think of anything else that I've "rejected". I re-factored to_identify at your request, I implemented method_name() the way you wanted, with overide methods in non-conforming classes, and I've been working to write every test you've asked for, even for things that weren't working when I started contributing. I've worked on them every day for the last two weeks, including my weekends and evenings. In the mean time, my work code is working with no problems, with multiple modal pages containing input and reporting elements, click_no_wait's and all the nested frames using Frame.html(). > I created a new module PageContainer which is intended for classes > that host entire html pages: IE, Frames, Modals. In some cases the > methods that you were attaching to Container can more safely be put here. Sounds reasonable. However, since more elements can use the html() and text() methods I'd argue that they belong in Container because in most cases the implementation is document.outerHTML. The ModalDialog class though *should* be moved to PageContainer since modal dialog's do load new URLs and can use the check_for_http_error method there. > For me, the best approach is to make changes in a specific area. Make > sure they are well tested, and then commit them to trunk. Next we can > look at generalizing those changes or moving on to perhaps related areas. In what ways aren't my changes generalized already? Click_no_wait worked fine, using to_identifier() and method_name(). I don't know of any elements where it worked before and it doesn't work now. It still doesn't work for *every* element, but I'm working on that. It's still better than before though, and will keep getting better. > For example, right now, i am still digesting how to use the Modal > Dialog code the best way. I also believe that once we have working > code, it is pretty easy to modify interfaces and refactor the > implementation, which is why i like to get working ( i.e. tested) code > as soon as possible. It's working. It's tested. "as soon as possible"? Look at how much I've gotten working in under two weeks, *with* tests and a full time job and family. My tests even found a problem not occurring on my machine and together we fixed the problem. Exactly *how* was I supposed to fix a problem which I couldn't re-create? I've felt that you've resented me ever since that point, but I don't see why? Have you found other actual problems with my code other than the one we fixed the other day? Tell me what's *wrong* with the code and let's discuss it and let me fix the code. If you want more tests, then let me finish them. > You've asked for suggestions and i've given them. In many cases, you > responded with why you like your approach better. That is fine, but > this is how i work. It is very difficult for me to review code when > there are lots of changes to different areas, each with different > levels of testing. I get contributions from lots of of different > people, so i hope you can understand why i work this way. Am I not allowed to disagree at all with your suggestions? I've listened to every one, and in most cases implemented things the way you wanted. The only "approach" we seem to disagree on is that I'm making too many changes. However, all those changes have been necessary to get my code working for my job. They all work, and I've been writing tests for them all. I've even done as you asked and written tests FIRST for some functions not yet implemented, but now I see that you've disabled them when you moved them to trunk? > Please let me know when you have specific, tested changes that are > complete and ready to be committed to trunk. I will be happy to review > them. Which is what I had planned, at your request. So why the sudden merge to trunk *without* even informing me first or without any group discussion on them? You wanted tests before merge, but then while I'm working to do exactly what you requested I find that some of my code gets merged. Look, if you don't want my help, I'll just stop contributing. If folks want my fixes I'll just post them to the mailing list and perhaps get a bit more time in with my family. > Bret I'd also be interested in hearing from some of the other contributors. I'm committing to the modal_dialog branch (https://svn.openqa.org/svn/watir/branches/modal_dialog/watir) and I'd be happy to discuss what I've been working on. In particular, the click_no_wait()->to_identifier()->method_name() calls to support click_no_wait in containers and the ModalDialog class to instantiate modal dialogs and interact with their DOM just like any other Watir element. The only tests which are failing for this new code are a test for a feature I've not yet implemented (TDD), a test which fails for Bret's ModalPage which I haven't fixed yet because ModalPage doesn't include module Container, and I've seen some inconsistencies with the way table bodies are implemented. In particular, try running modal_dialog_test.rb, to_identifier_test.rb and method_name_test.rb. I have more tests written for to_identifier so let me know if you want those committed for review. Now, back to writing tests... David Schmidt davids at tower-mt.com From davids at tower-mt.com Mon May 22 14:56:50 2006 From: davids at tower-mt.com (David Schmidt) Date: Mon, 22 May 2006 11:56:50 -0700 Subject: [Wtr-core] Cause of "frame error in waitreadyState" found. Message-ID: <44720972.7070201@tower-mt.com> Bret, I've found the cause of the "frame error in waitreadyState" (http://rubyforge.org/pipermail/wtr-general/2006-May/006027.html) but I'm not sure how best to handle the problem. This problem is now occurring every execution for one of my scrapers. The problem is that IE#wait (and IE#check_for_http_error) are both accessing a frame's document when it isn't ready for some reason. This could be caused by checking too early, or perhaps one of the frames is loading a new URL after first loading which leaves the document (temporarily?) unavailable. The problem can be caught by wrapping the frame.document accesses in a begin/rescue, but I'm not sure whether we should just retry the access until it succeeds or abort the current wait. If it's just checking too quickly, then retrying is the solution (with timeout). However, if a frame is loading a *new* frame then this could be a sign that the entire wait should be restarted. I'm trying a few fixes now and I'll let you know what solution seems to work best and send you a patch against trunk. David Schmidt davids at tower-mt.com From bret at pettichord.com Mon May 22 18:21:14 2006 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 22 May 2006 17:21:14 -0500 Subject: [Wtr-core] Spy Smith Message-ID: I recently spoke with Tobias Mayer, the author of SpySmith. Many of you probably recall that I've been a big fan of this tool as an aid to Watir scripting. (Although more recently, i must say that i'm finding the IE dev toolbar to be perhaps more useful.) I think Tobias is on this list. Anyhow, Tobias was considering adapting SpySmith so that instead of just reporting HTML, it would also report Watir syntax. More recently, other affairs have demanded his attention and he's had to abandon this project. However, he's offered to make the SpySmith source code available via open source. It is C++ code. His plan was to separate the core event loop into a DLL and then programs could be written in other languages to use this. He was going to write the new code in C#, but i suspect that Ruby or other languages could also be used. Any one interested in taking over his code base? You can contact him directly at tobias at qualityforge.com. I've also suggested that he deposit the code in source forge and see what happens. Any other suggestions? Bret -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060522/a138e56c/attachment.htm From Mark_Cain at rl.gov Mon May 22 19:06:15 2006 From: Mark_Cain at rl.gov (Cain, Mark) Date: Mon, 22 May 2006 16:06:15 -0700 Subject: [Wtr-core] Interesting problems creating/testing method_name In-Reply-To: <447202C8.7060103@tower-mt.com> Message-ID: Would this fix include frames like: $ie.frame(:index, 8).frame(:index, 1).image(:src, /open_comment_icon.gif/i).click_no_wait --Mark I'd also be interested in hearing from some of the other contributors. I'm committing to the modal_dialog branch (https://svn.openqa.org/svn/watir/branches/modal_dialog/watir) and I'd be happy to discuss what I've been working on. In particular, the click_no_wait()->to_identifier()->method_name() calls to support click_no_wait in containers and the ModalDialog class to instantiate modal dialogs and interact with their DOM just like any other Watir element. The only tests which are failing for this new code are a test for a feature I've not yet implemented (TDD), a test which fails for Bret's ModalPage which I haven't fixed yet because ModalPage doesn't include module Container, and I've seen some inconsistencies with the way table bodies are implemented. In particular, try running modal_dialog_test.rb, to_identifier_test.rb and method_name_test.rb. I have more tests written for to_identifier so let me know if you want those committed for review. Now, back to writing tests... David Schmidt davids at tower-mt.com _______________________________________________ Wtr-core mailing list Wtr-core at rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-core -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060522/612b4794/attachment.htm From bret at pettichord.com Mon May 22 20:30:20 2006 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 22 May 2006 19:30:20 -0500 Subject: [Wtr-core] Cause of "frame error in waitreadyState" found. In-Reply-To: <44720972.7070201@tower-mt.com> References: <44720972.7070201@tower-mt.com> Message-ID: This sounds like a bug we fixed a couple of days ago. http://svn.openqa.org/fisheye/changelog/watir?cs=1002 On 5/22/06, David Schmidt wrote: > > Bret, > > I've found the cause of the "frame error in waitreadyState" > (http://rubyforge.org/pipermail/wtr-general/2006-May/006027.html ) but > I'm not sure how best to handle the problem. > > This problem is now occurring every execution for one of my scrapers. > The problem is that IE#wait (and IE#check_for_http_error) are both > accessing a frame's document when it isn't ready for some reason. This > could be caused by checking too early, or perhaps one of the frames is > loading a new URL after first loading which leaves the document > (temporarily?) unavailable. > > The problem can be caught by wrapping the frame.document accesses in a > begin/rescue, but I'm not sure whether we should just retry the access > until it succeeds or abort the current wait. If it's just checking too > quickly, then retrying is the solution (with timeout). However, if a > frame is loading a *new* frame then this could be a sign that the entire > wait should be restarted. > > I'm trying a few fixes now and I'll let you know what solution seems to > work best and send you a patch against trunk. > > David Schmidt > davids at tower-mt.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060522/ad6a5be9/attachment.htm From tobias at qualityforge.com Thu May 25 20:57:30 2006 From: tobias at qualityforge.com (Quality Forge) Date: Thu, 25 May 2006 17:57:30 -0700 (PDT) Subject: [Wtr-core] Spy Smith In-Reply-To: Message-ID: <20060526005730.21996.qmail@web31807.mail.mud.yahoo.com> Hi all, If anyone is interested in taking over this source code, please contact me at spysmith at qualityforge.com not at the tobias email which is slowly being engulfed by mega-spam from Eastern Europe, which will no doubt consume any sensible email. Cheers. Tobias Bret Pettichord wrote: I recently spoke with Tobias Mayer, the author of SpySmith. Many of you probably recall that I've been a big fan of this tool as an aid to Watir scripting. (Although more recently, i must say that i'm finding the IE dev toolbar to be perhaps more useful.) I think Tobias is on this list. Anyhow, Tobias was considering adapting SpySmith so that instead of just reporting HTML, it would also report Watir syntax. More recently, other affairs have demanded his attention and he's had to abandon this project. However, he's offered to make the SpySmith source code available via open source. It is C++ code. His plan was to separate the core event loop into a DLL and then programs could be written in other languages to use this. He was going to write the new code in C#, but i suspect that Ruby or other languages could also be used. Any one interested in taking over his code base? You can contact him directly at tobias at qualityforge.com. I've also suggested that he deposit the code in source forge and see what happens. Any other suggestions? Bret _______________________________________________ Wtr-core mailing list Wtr-core at rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-core -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060525/854c812d/attachment.htm