From bret at pettichord.com Thu Feb 1 09:36:57 2007 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 1 Feb 2007 08:36:57 -0600 Subject: [Wtr-development] Watir 2.0 Structure Proposal In-Reply-To: References: Message-ID: On 1/31/07, Bob Cotton wrote: > > 1. A unified API. At AWTA, Bret and I had a discussion about the > external API for a unified Watir. We agreed that we need a single API > for all drivers. This means that some external configuration mechanism > would be necessary. > > We thought API would look something like this: > > require 'watir' > browser = Watir.create_browser > browser.link(...).click # etc > > The same API would work for all browser drivers. The way i see it, this would create a "default" browser. Or you could give Watir.create_browser an argument that would allow it it know what kind of browser to create. The default behaviour could be configured with a config file or with command line arguments. 2. Dynamic configuration. Here are two approaches for dynamically > mixing in the driver specific parts into this API: > > 1. At "require" time > 2. Post "creation" time > > #1, at require time, would dynamically mix in the driver specific > modules when the module was required. i.e. when Ruby first "sees" > the code. Please, please no. This is just too much magic and is too confusing for people to understand. This means we would have two different classes with the same name. Confusing. > #2, post "creation" time, we would create an instance of a "Browser" > object, then mix the proper driver specific modules into *that* > instance. This is shown in the file > watir-2.0-skeleton/lib/watir_runtime_config.rb This could work, but wouldn't it be simpler just to have a separate class for each browser driver? The configuration could be in an external YAML file, or parameters > passed on the command line. An external file would work better for > the Selenium driver, as there could be several items to configure. I like this idea. #2 has the advantage that you could have multiple instances of the > "Browser" live at the same time, each using a browser driver. To me the main advantage is understandability, although we'd also get this as a bonus. > 3. Module structure: > A suggested module structure: > 1. Watir - The top-level module > > 2. Watir::BrowserDriver - The containing module for browser > specific sub-modules, e.g. > > Watir::BrowserDriver::IEWatir (what are we calling this, BTW?) > Watir::BrowserDriver::FireWatir > Watir::BrowserDriver::SafariWatir > Watir::BrowserDriver::MineralWatir > > 3. Watir::BrowserDriver::XXX The module for browser specific > code. This would be the browser specific portions of what > resides in the Watir::IE class, or in Watir::FireWatir class. > > 4. Watir::BrowserDriver::XXX::Element This module holds the driver > specific code for the Element base class. All (most) > sub-classes of Element should be driver neutral It seems to me that the BrowserDriver module is superflous. Couldn't we collapse the hierarchy by a level. 4. Directory structure. See the .zip file > > There is code to follow along. > > There are two .zip files. > > http://www.testarchitecture.com/watir-2.0/watir-2.0-skeleton.zip > > http://www.testarchitecture.com/watir-2.0/watir-2.0-skeleton-firewatir.zip > > One with just the skeleton structure, and a WatirConfig class that > does load a YAML file and will configure the Watir module. This code > will load and execute. > > cd watir-2.0-skeleton > irb -Ilib -rwatir > Hello - This is FireWatir included into Watir::BrowserDriver > irb(main):001:0> b = Watir::Browser.new > => # > irb(main):002:0> b.driver > => "FireWatir" > > > In the other I put some of the FireWatir code (only because it was > already factored out) in this structure just as an example. IT DOES > NOT WORK. > > > Thoughts? I won't have a chance to look at the code until this weekend, but i'm very happy to know you've been thinking about this and pleased to see your proposal. Bret -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-development/attachments/20070201/7981edfd/attachment-0001.html From dave at obtiva.com Thu Feb 1 15:53:55 2007 From: dave at obtiva.com (Dave Hoover) Date: Thu, 1 Feb 2007 14:53:55 -0600 Subject: [Wtr-development] Watir 2.0 Structure Proposal In-Reply-To: References: Message-ID: <11c8704e0702011253u4a88a5bbl575351affdd939c0@mail.gmail.com> On 1/31/07, Bob Cotton wrote: > Thoughts? I think this sounds reasonable. It seems as though the first step would be to restructure Watir::IE to conform to these ideas in order to get feedback from the bulk of the existing Watir users. Once that feedback has been incorporated, the rest of the drivers could integrate into the new structure. I think this would minimize a lot of the rework that would come if this initial structure needs to be modified. --Dave From bret at pettichord.com Fri Feb 2 15:17:46 2007 From: bret at pettichord.com (Bret Pettichord) Date: Fri, 2 Feb 2007 14:17:46 -0600 Subject: [Wtr-development] Watir 2.0 Structure Proposal In-Reply-To: <11c8704e0702011253u4a88a5bbl575351affdd939c0@mail.gmail.com> References: <11c8704e0702011253u4a88a5bbl575351affdd939c0@mail.gmail.com> Message-ID: On 2/1/07, Dave Hoover wrote: > > On 1/31/07, Bob Cotton wrote: > > Thoughts? > > I think this sounds reasonable. It seems as though the first step > would be to restructure Watir::IE to conform to these ideas in order > to get feedback from the bulk of the existing Watir users. Once that > feedback has been incorporated, the rest of the drivers could > integrate into the new structure. I think this would minimize a lot > of the rework that would come if this initial structure needs to be > modified. > > --Dave We are close to release Watir 1.5. After that i plan to move forward with the restructuring of the code towards pulling the code bases back together. Bret -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-development/attachments/20070202/b76b2feb/attachment.html From bob.cotton at rallydev.com Fri Feb 2 18:07:48 2007 From: bob.cotton at rallydev.com (Bob Cotton) Date: Fri, 02 Feb 2007 16:07:48 -0700 Subject: [Wtr-development] Watir 2.0 Structure Proposal In-Reply-To: (Bret Pettichord's message of "Thu, 1 Feb 2007 08:36:57 -0600") References: Message-ID: "Bret Pettichord" writes: > The way i see it, this would create a "default" browser. Or you could give > Watir.create_browser an argument that would allow it it know what kind of > browser to create. The default behaviour could be configured with a config > file or with command line arguments. > >> 2. Dynamic configuration. Here are two approaches for dynamically >> mixing in the driver specific parts into this API: >> >> 1. At "require" time >> 2. Post "creation" time >> >> #1, at require time, would dynamically mix in the driver specific >> modules when the module was required. i.e. when Ruby first "sees" >> the code. > > Please, please no. This is just too much magic and is too confusing for > people to understand. This means we would have two different classes with > the same name. Confusing. The code for this is actually not that confusing: module Watir module BrowserDriver include WatirConfig.new.browser_driver # uses yml file to find end # the correct module class Browser include BrowserDriver end end And the only people who have to understand it is us. The externally facing API for Browser would be exposed in the Browser class (and rdoc). AND it would not reference any driver specific behavior. >> #2, post "creation" time, we would create an instance of a "Browser" >> object, then mix the proper driver specific modules into *that* >> instance. This is shown in the file >> watir-2.0-skeleton /lib/watir_runtime_config.rb > > This could work, but wouldn't it be simpler just to have a separate class > for each browser driver? It may be for the Browser class, I'm not sure yet. Let me show you where I got the idea. In the FireWatir code, Angrez factored out the Firefox specific methods into the Element superclass (MozillaBaseElement.rb). He then implemented all the Element classes as subclasses of that Element class (in htmlelements.rb). It seemed to me that all subclasses of Element were written in a Firefox agnostic way. When I saw that, it occured to me that we could extract the contents of MozillaBaseElement.rb into a Watir::FireWatir::Element module. Do the same for each of the drivers, then mix that into the Element class. for example: module Watir::FireWatir::Element # FireWatir specific element stuff here end class Element include FireWatir::Element # <-- done dynamically (not shown) end class Table < Element # driver independent implementation of table end If all subclasses of element are written using methods from Element, for which driver specific implementations has been mixed in, they would not be concerned with driver specific issues. An alternative would be sub-class of Table, for example, for each driver, if necessary. The idea stands inheritance on its head. Instead of the putting the common stuff in a base class, you put the common stuff in the sub-class and mix-in the specific. Will it work? Don't know. Will it work for the methods of Browser, don't know. Glad to hear that 1.5 is getting close. -Bob From bret at pettichord.com Thu Feb 1 09:36:57 2007 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 1 Feb 2007 08:36:57 -0600 Subject: [Wtr-development] Watir 2.0 Structure Proposal In-Reply-To: References: Message-ID: On 1/31/07, Bob Cotton wrote: > > 1. A unified API. At AWTA, Bret and I had a discussion about the > external API for a unified Watir. We agreed that we need a single API > for all drivers. This means that some external configuration mechanism > would be necessary. > > We thought API would look something like this: > > require 'watir' > browser = Watir.create_browser > browser.link(...).click # etc > > The same API would work for all browser drivers. The way i see it, this would create a "default" browser. Or you could give Watir.create_browser an argument that would allow it it know what kind of browser to create. The default behaviour could be configured with a config file or with command line arguments. 2. Dynamic configuration. Here are two approaches for dynamically > mixing in the driver specific parts into this API: > > 1. At "require" time > 2. Post "creation" time > > #1, at require time, would dynamically mix in the driver specific > modules when the module was required. i.e. when Ruby first "sees" > the code. Please, please no. This is just too much magic and is too confusing for people to understand. This means we would have two different classes with the same name. Confusing. > #2, post "creation" time, we would create an instance of a "Browser" > object, then mix the proper driver specific modules into *that* > instance. This is shown in the file > watir-2.0-skeleton/lib/watir_runtime_config.rb This could work, but wouldn't it be simpler just to have a separate class for each browser driver? The configuration could be in an external YAML file, or parameters > passed on the command line. An external file would work better for > the Selenium driver, as there could be several items to configure. I like this idea. #2 has the advantage that you could have multiple instances of the > "Browser" live at the same time, each using a browser driver. To me the main advantage is understandability, although we'd also get this as a bonus. > 3. Module structure: > A suggested module structure: > 1. Watir - The top-level module > > 2. Watir::BrowserDriver - The containing module for browser > specific sub-modules, e.g. > > Watir::BrowserDriver::IEWatir (what are we calling this, BTW?) > Watir::BrowserDriver::FireWatir > Watir::BrowserDriver::SafariWatir > Watir::BrowserDriver::MineralWatir > > 3. Watir::BrowserDriver::XXX The module for browser specific > code. This would be the browser specific portions of what > resides in the Watir::IE class, or in Watir::FireWatir class. > > 4. Watir::BrowserDriver::XXX::Element This module holds the driver > specific code for the Element base class. All (most) > sub-classes of Element should be driver neutral It seems to me that the BrowserDriver module is superflous. Couldn't we collapse the hierarchy by a level. 4. Directory structure. See the .zip file > > There is code to follow along. > > There are two .zip files. > > http://www.testarchitecture.com/watir-2.0/watir-2.0-skeleton.zip > > http://www.testarchitecture.com/watir-2.0/watir-2.0-skeleton-firewatir.zip > > One with just the skeleton structure, and a WatirConfig class that > does load a YAML file and will configure the Watir module. This code > will load and execute. > > cd watir-2.0-skeleton > irb -Ilib -rwatir > Hello - This is FireWatir included into Watir::BrowserDriver > irb(main):001:0> b = Watir::Browser.new > => # > irb(main):002:0> b.driver > => "FireWatir" > > > In the other I put some of the FireWatir code (only because it was > already factored out) in this structure just as an example. IT DOES > NOT WORK. > > > Thoughts? I won't have a chance to look at the code until this weekend, but i'm very happy to know you've been thinking about this and pleased to see your proposal. Bret -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at obtiva.com Thu Feb 1 15:53:55 2007 From: dave at obtiva.com (Dave Hoover) Date: Thu, 1 Feb 2007 14:53:55 -0600 Subject: [Wtr-development] Watir 2.0 Structure Proposal In-Reply-To: References: Message-ID: <11c8704e0702011253u4a88a5bbl575351affdd939c0@mail.gmail.com> On 1/31/07, Bob Cotton wrote: > Thoughts? I think this sounds reasonable. It seems as though the first step would be to restructure Watir::IE to conform to these ideas in order to get feedback from the bulk of the existing Watir users. Once that feedback has been incorporated, the rest of the drivers could integrate into the new structure. I think this would minimize a lot of the rework that would come if this initial structure needs to be modified. --Dave From bret at pettichord.com Fri Feb 2 15:17:46 2007 From: bret at pettichord.com (Bret Pettichord) Date: Fri, 2 Feb 2007 14:17:46 -0600 Subject: [Wtr-development] Watir 2.0 Structure Proposal In-Reply-To: <11c8704e0702011253u4a88a5bbl575351affdd939c0@mail.gmail.com> References: <11c8704e0702011253u4a88a5bbl575351affdd939c0@mail.gmail.com> Message-ID: On 2/1/07, Dave Hoover wrote: > > On 1/31/07, Bob Cotton wrote: > > Thoughts? > > I think this sounds reasonable. It seems as though the first step > would be to restructure Watir::IE to conform to these ideas in order > to get feedback from the bulk of the existing Watir users. Once that > feedback has been incorporated, the rest of the drivers could > integrate into the new structure. I think this would minimize a lot > of the rework that would come if this initial structure needs to be > modified. > > --Dave We are close to release Watir 1.5. After that i plan to move forward with the restructuring of the code towards pulling the code bases back together. Bret -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.cotton at rallydev.com Fri Feb 2 18:07:48 2007 From: bob.cotton at rallydev.com (Bob Cotton) Date: Fri, 02 Feb 2007 16:07:48 -0700 Subject: [Wtr-development] Watir 2.0 Structure Proposal In-Reply-To: (Bret Pettichord's message of "Thu, 1 Feb 2007 08:36:57 -0600") References: Message-ID: "Bret Pettichord" writes: > The way i see it, this would create a "default" browser. Or you could give > Watir.create_browser an argument that would allow it it know what kind of > browser to create. The default behaviour could be configured with a config > file or with command line arguments. > >> 2. Dynamic configuration. Here are two approaches for dynamically >> mixing in the driver specific parts into this API: >> >> 1. At "require" time >> 2. Post "creation" time >> >> #1, at require time, would dynamically mix in the driver specific >> modules when the module was required. i.e. when Ruby first "sees" >> the code. > > Please, please no. This is just too much magic and is too confusing for > people to understand. This means we would have two different classes with > the same name. Confusing. The code for this is actually not that confusing: module Watir module BrowserDriver include WatirConfig.new.browser_driver # uses yml file to find end # the correct module class Browser include BrowserDriver end end And the only people who have to understand it is us. The externally facing API for Browser would be exposed in the Browser class (and rdoc). AND it would not reference any driver specific behavior. >> #2, post "creation" time, we would create an instance of a "Browser" >> object, then mix the proper driver specific modules into *that* >> instance. This is shown in the file >> watir-2.0-skeleton /lib/watir_runtime_config.rb > > This could work, but wouldn't it be simpler just to have a separate class > for each browser driver? It may be for the Browser class, I'm not sure yet. Let me show you where I got the idea. In the FireWatir code, Angrez factored out the Firefox specific methods into the Element superclass (MozillaBaseElement.rb). He then implemented all the Element classes as subclasses of that Element class (in htmlelements.rb). It seemed to me that all subclasses of Element were written in a Firefox agnostic way. When I saw that, it occured to me that we could extract the contents of MozillaBaseElement.rb into a Watir::FireWatir::Element module. Do the same for each of the drivers, then mix that into the Element class. for example: module Watir::FireWatir::Element # FireWatir specific element stuff here end class Element include FireWatir::Element # <-- done dynamically (not shown) end class Table < Element # driver independent implementation of table end If all subclasses of element are written using methods from Element, for which driver specific implementations has been mixed in, they would not be concerned with driver specific issues. An alternative would be sub-class of Table, for example, for each driver, if necessary. The idea stands inheritance on its head. Instead of the putting the common stuff in a base class, you put the common stuff in the sub-class and mix-in the specific. Will it work? Don't know. Will it work for the methods of Browser, don't know. Glad to hear that 1.5 is getting close. -Bob From bret at pettichord.com Thu Feb 1 09:36:57 2007 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 1 Feb 2007 08:36:57 -0600 Subject: [Wtr-development] Watir 2.0 Structure Proposal In-Reply-To: References: Message-ID: On 1/31/07, Bob Cotton wrote: > > 1. A unified API. At AWTA, Bret and I had a discussion about the > external API for a unified Watir. We agreed that we need a single API > for all drivers. This means that some external configuration mechanism > would be necessary. > > We thought API would look something like this: > > require 'watir' > browser = Watir.create_browser > browser.link(...).click # etc > > The same API would work for all browser drivers. The way i see it, this would create a "default" browser. Or you could give Watir.create_browser an argument that would allow it it know what kind of browser to create. The default behaviour could be configured with a config file or with command line arguments. 2. Dynamic configuration. Here are two approaches for dynamically > mixing in the driver specific parts into this API: > > 1. At "require" time > 2. Post "creation" time > > #1, at require time, would dynamically mix in the driver specific > modules when the module was required. i.e. when Ruby first "sees" > the code. Please, please no. This is just too much magic and is too confusing for people to understand. This means we would have two different classes with the same name. Confusing. > #2, post "creation" time, we would create an instance of a "Browser" > object, then mix the proper driver specific modules into *that* > instance. This is shown in the file > watir-2.0-skeleton/lib/watir_runtime_config.rb This could work, but wouldn't it be simpler just to have a separate class for each browser driver? The configuration could be in an external YAML file, or parameters > passed on the command line. An external file would work better for > the Selenium driver, as there could be several items to configure. I like this idea. #2 has the advantage that you could have multiple instances of the > "Browser" live at the same time, each using a browser driver. To me the main advantage is understandability, although we'd also get this as a bonus. > 3. Module structure: > A suggested module structure: > 1. Watir - The top-level module > > 2. Watir::BrowserDriver - The containing module for browser > specific sub-modules, e.g. > > Watir::BrowserDriver::IEWatir (what are we calling this, BTW?) > Watir::BrowserDriver::FireWatir > Watir::BrowserDriver::SafariWatir > Watir::BrowserDriver::MineralWatir > > 3. Watir::BrowserDriver::XXX The module for browser specific > code. This would be the browser specific portions of what > resides in the Watir::IE class, or in Watir::FireWatir class. > > 4. Watir::BrowserDriver::XXX::Element This module holds the driver > specific code for the Element base class. All (most) > sub-classes of Element should be driver neutral It seems to me that the BrowserDriver module is superflous. Couldn't we collapse the hierarchy by a level. 4. Directory structure. See the .zip file > > There is code to follow along. > > There are two .zip files. > > http://www.testarchitecture.com/watir-2.0/watir-2.0-skeleton.zip > > http://www.testarchitecture.com/watir-2.0/watir-2.0-skeleton-firewatir.zip > > One with just the skeleton structure, and a WatirConfig class that > does load a YAML file and will configure the Watir module. This code > will load and execute. > > cd watir-2.0-skeleton > irb -Ilib -rwatir > Hello - This is FireWatir included into Watir::BrowserDriver > irb(main):001:0> b = Watir::Browser.new > => # > irb(main):002:0> b.driver > => "FireWatir" > > > In the other I put some of the FireWatir code (only because it was > already factored out) in this structure just as an example. IT DOES > NOT WORK. > > > Thoughts? I won't have a chance to look at the code until this weekend, but i'm very happy to know you've been thinking about this and pleased to see your proposal. Bret -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at obtiva.com Thu Feb 1 15:53:55 2007 From: dave at obtiva.com (Dave Hoover) Date: Thu, 1 Feb 2007 14:53:55 -0600 Subject: [Wtr-development] Watir 2.0 Structure Proposal In-Reply-To: References: Message-ID: <11c8704e0702011253u4a88a5bbl575351affdd939c0@mail.gmail.com> On 1/31/07, Bob Cotton wrote: > Thoughts? I think this sounds reasonable. It seems as though the first step would be to restructure Watir::IE to conform to these ideas in order to get feedback from the bulk of the existing Watir users. Once that feedback has been incorporated, the rest of the drivers could integrate into the new structure. I think this would minimize a lot of the rework that would come if this initial structure needs to be modified. --Dave From bret at pettichord.com Fri Feb 2 15:17:46 2007 From: bret at pettichord.com (Bret Pettichord) Date: Fri, 2 Feb 2007 14:17:46 -0600 Subject: [Wtr-development] Watir 2.0 Structure Proposal In-Reply-To: <11c8704e0702011253u4a88a5bbl575351affdd939c0@mail.gmail.com> References: <11c8704e0702011253u4a88a5bbl575351affdd939c0@mail.gmail.com> Message-ID: On 2/1/07, Dave Hoover wrote: > > On 1/31/07, Bob Cotton wrote: > > Thoughts? > > I think this sounds reasonable. It seems as though the first step > would be to restructure Watir::IE to conform to these ideas in order > to get feedback from the bulk of the existing Watir users. Once that > feedback has been incorporated, the rest of the drivers could > integrate into the new structure. I think this would minimize a lot > of the rework that would come if this initial structure needs to be > modified. > > --Dave We are close to release Watir 1.5. After that i plan to move forward with the restructuring of the code towards pulling the code bases back together. Bret -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.cotton at rallydev.com Fri Feb 2 18:07:48 2007 From: bob.cotton at rallydev.com (Bob Cotton) Date: Fri, 02 Feb 2007 16:07:48 -0700 Subject: [Wtr-development] Watir 2.0 Structure Proposal In-Reply-To: (Bret Pettichord's message of "Thu, 1 Feb 2007 08:36:57 -0600") References: Message-ID: "Bret Pettichord" writes: > The way i see it, this would create a "default" browser. Or you could give > Watir.create_browser an argument that would allow it it know what kind of > browser to create. The default behaviour could be configured with a config > file or with command line arguments. > >> 2. Dynamic configuration. Here are two approaches for dynamically >> mixing in the driver specific parts into this API: >> >> 1. At "require" time >> 2. Post "creation" time >> >> #1, at require time, would dynamically mix in the driver specific >> modules when the module was required. i.e. when Ruby first "sees" >> the code. > > Please, please no. This is just too much magic and is too confusing for > people to understand. This means we would have two different classes with > the same name. Confusing. The code for this is actually not that confusing: module Watir module BrowserDriver include WatirConfig.new.browser_driver # uses yml file to find end # the correct module class Browser include BrowserDriver end end And the only people who have to understand it is us. The externally facing API for Browser would be exposed in the Browser class (and rdoc). AND it would not reference any driver specific behavior. >> #2, post "creation" time, we would create an instance of a "Browser" >> object, then mix the proper driver specific modules into *that* >> instance. This is shown in the file >> watir-2.0-skeleton /lib/watir_runtime_config.rb > > This could work, but wouldn't it be simpler just to have a separate class > for each browser driver? It may be for the Browser class, I'm not sure yet. Let me show you where I got the idea. In the FireWatir code, Angrez factored out the Firefox specific methods into the Element superclass (MozillaBaseElement.rb). He then implemented all the Element classes as subclasses of that Element class (in htmlelements.rb). It seemed to me that all subclasses of Element were written in a Firefox agnostic way. When I saw that, it occured to me that we could extract the contents of MozillaBaseElement.rb into a Watir::FireWatir::Element module. Do the same for each of the drivers, then mix that into the Element class. for example: module Watir::FireWatir::Element # FireWatir specific element stuff here end class Element include FireWatir::Element # <-- done dynamically (not shown) end class Table < Element # driver independent implementation of table end If all subclasses of element are written using methods from Element, for which driver specific implementations has been mixed in, they would not be concerned with driver specific issues. An alternative would be sub-class of Table, for example, for each driver, if necessary. The idea stands inheritance on its head. Instead of the putting the common stuff in a base class, you put the common stuff in the sub-class and mix-in the specific. Will it work? Don't know. Will it work for the methods of Browser, don't know. Glad to hear that 1.5 is getting close. -Bob