> > I'd be very interested to hear what you think are significant > shortcomings of the WebDriver approach. > > Basically it seems to me to add an unnecessary layer of complexity. Watir can talk to a browser - firefox, for example - directly through an extension (JSSH). or it can talk to another piece of software (webdriver) which in turn talks to firefox through some other piece of software (FirefoxDriver, I think?). Why is the latter advantageous?
One argument is that the other piece of software moves browser-specific implementation stuff out of watir's code. But, really, the DOM is not too terribly different from browser to browser; if you have the same access to the DOM, much of the implementation is the same (which is why I have been able to move so much code from firewatir and ie-watir to commonwatir). It seems like a lot of the point of watir itself has been to move browser-specific implementation stuff to where users don't have to worry about it; if webdriver does this, why is watir needed at all? (apart from familiarity with its api and code that it would be a pain to migrate, I guess.) I do not mean the above to be very strong or definitive reasons - more preliminary impressions, as am not too well-informed as to the details of how webdriver/selenium talk to browsers. I do not intend to be bashing a thing that I do not know very well. I would be quite interested to know what advantage using webdriver provides, if you want to explain. I do plan to look more closely into webdriver and selenium, and if reasons to use them are compelling, then possibly looking into moving my own work in that direction as well.
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
