Nice work, Hugh! A few comments to the spreadsheet:
* removing #cell{,s} (and #row{,s}, which are missing from the spreadsheet)
from Watir::Container was a deliberate choice in watir-webdriver. See this
issue [1] and especially this gist [2]
* Browser#driver returns the underlying Selenium::WebDriver::Driver
instance, and is specific to watir-webdriver.
* Browser#browser and Browser#assert_exists is part of the shared protocol
between Watir::Browser and Watir::Element in watir-webdriver, and can be
considered an implementation detail.
* element{,s}_by_xpath is deprecated and was removed from watir-webdriver
in 0.5.1.
[1] https://github.com/watir/watir-webdriver/issues/2
[2] https://gist.github.com/565553
On Sun, Feb 12, 2012 at 10:18 PM, Hugh McGowan <colinsda...@gmail.com>wrote:
> Hi all,
>
> I instantiated both browsers and compared the methods on each browser
> instance to get the public methods available. I removed methods from the
> list that were unimportant. What's left is a comprehensive look at the
> basic API for both drivers.
>
>
>
> https://docs.google.com/spreadsheet/ccc?key=0AncOJVyN5MMMdHVQQ3pKWElnZ3RDZEc4QzdneTVHbmc
>
>
> Since I'm looking at this from the view of getting Watir-IE to be API
> compatible with Watir WebDriver, I've coded it as follows:
>
> For Webdriver,(first column):
> * items in blue are things we should implement but not necessary for
> 3.0. Everything we would add here would not change the API
> * items in red I'm not sure about or don't think we need to implement
> in watir-ie
>
> For Watir (second column):
> * items in blue are places I'm proposing we deviate from webdriver for
> the moment and potentially port these to webdriver if it makes sense.
> * items in red are things we should make private or deprecate.
>
> Overall for watir I think we should:
> * deprecate all methods that are specific to IE-window handling
> (minimize, maximize, etc). Let people use browser.rautomation to make these
> calls
> * remove all of the show * methods. Modern browsers have great dev
> tools so this is obsolete
> * remove all of the camel-case aliases for methods and alternate
> methods that call the same thing
> * deprecate methods that don't add value (#contains_text for example)
> * Watir automatically creates methods when subclassed from Element
> which is convenient but adds methods for things that shouldn't be in the
> API (for example #radio_check_common). Find a better way to handle this to
> clean up the exposed API
>
> It seems to me that before we release 3.0 we need to
> * clean up the watir tests (I've started this and while there are a lot
> of test fixes there are a few failures that will likely need code changes)
> * make the watirspec tests that fail for implemented features pass (fix
> things like tables and xpath that we've implemented, don't worry about
> unimplemented features)
> * clean up the methods in red from the spreadsheet to make us closer to
> the watir-webdriver API. Make it one big API change and not trickle it in.
> * optionally look at the methods attached to the major input elements
> in the same way we did here for the browser (text_field, radio, link,
> checkbox, select_list, button)
>
> I think we can continue to go with pre-releases and release code regularly
> until we're ready. I don't think it's that much work to fix up these things
> and will be easier on users to have a big API change and then little
> feature adds as we approach webdriver's core set of features. I'm happy to
> do this work - I just want to make sure we're doing the right thing here.
>
> Thoughts?
>
> Thanks!
> Hugh
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
_______________________________________________
Wtr-development mailing list
Wtr-development@rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-development
