As I move more and more code to commonwatir, I am ending up with numerous
browser-specific stub classes that look like
module Watir
class FFTable < FFElement
include Watir::Table
end
end
(and the same with IE)
I'm thinking of restructuring to eliminate browser-specific classes, and
replace them with browser-specific modules where necessary. The new
structure I am thinking goes something like this:
class Watir::Element (common)
class Watir::FileField < Watir::Element (common)
module Watir::Firefox::Element
module Watir::Firefox::FileField - this exists only if there is actually
code that is browser-specific for this class. which is true for FileField,
but there would not exist any Watir::Firefox::Table.
And then, the browser-specific stuff would get dynamically added on
initialization, along the lines of:
class Watir::FileField
def initialize
if browser_class == Watir::Firefox
extend Watir::Firefox::Element
end
# or, more generally, just `extend browser_class::Element`
if browser_class.const_defined?('FileField')
extend browser_class::FileField
end
end
end
browser_class, there, would come from the container in some manner.
I think this would help clean things up a bit, and this way elements all get
instantiated with the same class regardless of browser (and the name of the
class would be the same as Watir has used in the past, in IE).
I'm a bit of a ways off from actually implementing this, but I thought I
would see what thoughts people have on it.
-Ethan
On Thu, Oct 22, 2009 at 10:09, Ethan <[email protected]> wrote:
>
>
> On Thu, Oct 22, 2009 at 00:18, Bret Pettichord <[email protected]>wrote:
>
>> On Sat, Oct 10, 2009 at 6:58 PM, Ethan <[email protected]> wrote:
>>
>>> On Sat, Oct 10, 2009 at 18:35, Bret Pettichord <[email protected]>wrote:
>>>
>>>>
>>>> On Sat, Oct 10, 2009 at 4:20 PM, Ethan <[email protected]> wrote:
>>>>
>>>>>
>>>>> I considered putting them in their own namespaces but I decided that
>>>>> would be too confusing. Say you have
>>>>>
>>>>> - Watir::TextField for common
>>>>> - Watir::IE::TextField
>>>>> - Watir::Firefox::TextField
>>>>>
>>>>> I think it would get confusing when you are in, say, the Watir::Firefox
>>>>> namespace, whether an unprefixed TextField is meant to refer to the common
>>>>> one or the firefox one.
>>>>>
>>>>
>> I'm not too worried about this. We can always use this syntax for
>> references to avoid any possible misunderstanding:
>>
>> ::Watir::Textfield
>> ::Watir::IE::Textfield
>>
>> and just agree not to have unprefixed TextField in our source.
>>
>>
>>
>>> Maybe
>>>>>
>>>>> - Watir::Common::TextField
>>>>> - Watir::IE::TextField
>>>>> - Watir::Firefox::Textfield
>>>>>
>>>>> I like this.
>>>>
>>>> BTW, this is a big change and really needs to be discussed in the
>>>> context of how we want to structure Watir 2.0.
>>>>
>>>>
>>>>> so that in any namespace you have to prefix the other's namespace. But
>>>>> that would break everything that checks stuff like
>>>>> foo.is_a?(Watir::TextField) - I named the common one after the existing IE
>>>>> one so that that would still work. (it still breaks backwards
>>>>> compatibility
>>>>> if code uses foo.class==Watir::TextField, but is_a? is generally
>>>>> recommended, so I figured this would be acceptable.)
>>>>>
>>>>
>> This is a good argument for using Watir::TextField instead of
>> Watir::Common::TextField
>>
>>
>>>
>>>>> Another possibility is
>>>>>
>>>>> - Watir::TextField for common
>>>>> - IEWatir::TextField
>>>>> - FireWatir::TextField
>>>>>
>>>>> But I figured having separate browser-specific class names in one
>>>>> namespace was preferable to having identical class names in
>>>>> browser-specific
>>>>> namespaces.
>>>>>
>>>>
>> I agree with this point
>>
>>
>>> I don't know which one of those I prefer, they all have their pros and
>>> cons. I am inclined toward one of the first two, as breaking existing
>>> foo.is_a?(Watir::TextField) seems like a bigger negative than having
>>> different names (FFTextField and TextField) or ambiguity in some namespace.
>>>
>>
>> I think i agree that not breaking x.is_a? is a good idea. (Not sure at
>> this point whether I'm agreeing with myself or not.)
>>
>>
>>> • Watir::TextField
>>> • Watir::IETextField
>>> • Watir::FFTextField
>>> all in the same top namespace, no ambiguity referring to TextField, but
>>> prefixes mean class-specific ones aren't consistently named TextField.
>>>
>>>
>>> • Watir::TextField
>>> • Watir::IE::TextField
>>> • Watir::Firefox::TextField
>>> all in the same top namespace, all consistently named TextField, but
>>> ambiguous in browser namespace.
>>>
>>
>> So now i am leaning towards this one.
>>
>>
>>> • Watir::Common::TextField
>>> • Watir::IE::TextField
>>> • Watir::Firefox::Textfield
>>> all in the same top namespace, consistent names, no ambiguity, but breaks
>>> existing code checking for Watir::TextField.
>>> Bret Pettichord says: I like this.
>>>
>>>
>>> • Watir::TextField for common
>>> • IEWatir::TextField
>>> • FireWatir::TextField
>>> different top-level namespace, so no ambiguity, all consistently named
>>> TextField.
>>>
>>>
>> I think i would like get this restructuring in for 1.7.0, along with some
>> restructuring of how things are broken into gems. (Actually, i think i would
>> like to start using git submodules: can someone recommend a place for me to
>> learn how to use them?)
>>
>> Bret
>>
>>
>
> Okay, sounds good to me - I'm on board with
>
> • Watir::TextField
> • Watir::IE::TextField
> • Watir::Firefox::TextField
>
> Ethan
>
>
_______________________________________________
Wtr-development mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wtr-development
