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 [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
