Very well said. Thx Jari. :) -c
On Wed, Jan 27, 2010 at 2:29 PM, Jari Bakken <[email protected]> wrote: > On Wed, Jan 27, 2010 at 7:38 PM, Ethan <[email protected]> wrote: > > > > 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). > > The main advantage to me is the fact that in WebDriver, the technology > used to control the various browsers is completely separate from the > user-facing client library. The core, browser-specific implementation > of the WebDriver API isn't tied to one programming language, which > means there's a larger community of clever people who hack on the core > parts and solve the browser-specific problems (which are not trivial). > > Another important benefit is that WebDriver takes a native approach to > automating the browsers, which means it can choose the best approach > for the particular browser used - not necessarily rely on the > JavaScript DOM implementation, which does vary between browsers and > also has other constraints (like dealing with prompts or alerts, > window switching, cross-domain limitations etc.). WebDriver will also > use native, OS-level events where available (Windows and Linux at the > moment) - so clicks and key presses will be a lot more realistic than > synthesized JS events. The fact that the Selenium project (which is > purely JS/DOM-based, and also among the most successful autoamtion > tools, despite its unattractive API) has decided to merge with > WebDriver, should be a strong indication that the native approach has > a lot of validity. > > In Firefox and Chrome, this means using their extension mechanisms; > for IE, the driver is implemented in C++; for Opera, it will (when > released) use the same protocol as their built-in developer tools. One > can also issue commands using a JSON-over-HTTP interface, which is > used to drive browsers on iPhone and Android or on a remote machine. > All of this is of course is nothing a Watir user would need to bother > with. The WebDriver API is intentionally kept small and concise for > exactly this reason, making it the perfect building block for > higher-level tools (like Watir). > > > 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.) > > You're right, it's not needed. You can definitely use WebDriver > directly if you're starting from scratch and/or like that API better. > As mentioned by Charley (and others), the strength of Watir is really > its API and the ease of use - not the underlying tech. So the question > is: can I use my favorite API with the best available tech as the > backend? That's the main motivation for doing the watir-webdriver > project. > > Of course, instead of building on the work being done by the > WebDriver/Selenium team we could try to do it on our own; based on the > existing implementation, make a generalized core and write some > browser-specific code where needed. That would be valid if our > technology, expertise or level of activity was vastly better than > theirs. It's not. So consolidating these efforts makes a lot of sense > to me. > > I hope I don't come off as trying to belittle your work - the 1.X code > base was in dire need of some refactoring last time I looked, and from > what I've seen of your fork (some time back), the design changes make > a lot of sense. For me personally though, what route the official > Watir project decides to take is honestly not a big concern, I'll be > chugging along on the watir-webdriver code until some superior > technology comes along. :) > _______________________________________________ > Wtr-development mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/wtr-development >
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
