{"action":"closed","issue":{"url":"https://api.github.com/repos/cheezy/page-object/issues/241","labels_url":"https://api.github.com/repos/cheezy/page-object/issues/241/labels{/name}","comments_url":"https://api.github.com/repos/cheezy/page-object/issues/241/comments","events_url":"https://api.github.com/repos/cheezy/page-object/issues/241/events","html_url":"https://github.com/cheezy/page-object/issues/241","id":41314502,"number":241,"title":"Refactor page-object to use watir-webdriver internally","user":{"login":"daneandersen","id":4837260,"avatar_url":"https://avatars.githubusercontent.com/u/4837260?v=3","gravatar_id":"","url":"https://api.github.com/users/daneandersen","html_url":"https://github.com/daneandersen","followers_url":"https://api.github.com/users/daneandersen/followers","following_url":"https://api.github.com/users/daneandersen/following{/other_user}","gists_url":"https://api.github.com/users/daneandersen/gists{/gist_id}","starred_url":"https://api.github.com/users/daneandersen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/daneandersen/subscriptions","organizations_url":"https://api.github.com/users/daneandersen/orgs","repos_url":"https://api.github.com/users/daneandersen/repos","events_url":"https://api.github.com/users/daneandersen/events{/privacy}","received_events_url":"https://api.github.com/users/daneandersen/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2014-08-27T18:24:45Z","updated_at":"2015-04-22T00:43:44Z","closed_at":"2015-04-22T00:43:44Z","body":"It was proposed in another issue to switch page object to using watir-webdriver internally for everything in order to simplify the code and fix behaviors not functioning in selenium. This was a good idea but didn't belong in that issue, so I am breaking it out.\r\n\r\nThe api could remain the same by conditionally:\r\n - returning Selenium::WebDriver instead of Watir::Browser\r\n - returning selenium elements instead of waitr elements\r\nbased on whether a Selenium::WebDriver or a Watir::Browser was initially passed in.\r\n\r\nThe end values of this refactor would be a simplification of the code base, as well as making all functionality the same for those using watir-webdriver and selenium.\r\n\r\nThere are also no added costs to the users because watir-webdriver is already a dependency of page-object, whether or not you are using it.\r\n\r\n\r\n\r\nConversation that lead to this issue:\r\n\r\n jkotests commented\r\n> @cheezy, given that this is a solved problem in Watir-WebDriver, I tried to implement their solution in the SeleniumWebDriver::PageObject. However, after only achieving partial success, it got me questioning the value of the PageObject internally supporting both Watir and Selenium.\r\n\r\n> Why not just use Watir-WebDriver internally?\r\n\r\n> I could only think of 2 use cases where someone would care about Watir vs Selenium:\r\n\r\n> When initializing the page object, someone might have a Watir::Browser or a Selenium::WebDriver.\r\nWhen the PageObject does not have a particular method, someone might need to interact with the underlying browser or element.\r\nWatir would be able to support both of these use cases - ie a Watir::Browser can be created from a Selenium::WebDriver, as well as you can get the underlying Selenium browser/element from a Watir browser/element.\r\n \r\n> Switching to only using Watir internally would address this iframe issue, as well as significantly reduce the code base.\r\n \r\n> Would doing this make sense or is the idea too far fetched? If the idea seems reasonable, I would be happy to help make the changes.\r\n\r\n\r\n\r\n daneandersen commented\r\n> @jkotests, at first I was thinking that might not be a viable solution, but then I realized that because watir-wedriver is a dependency of page-object, people are already biting off the cost of having that gem. In essence, there would be no cost to them to use watir-webdriver internally.\r\n \r\n> The only concern I have is people that want to use the selenium elements directly and would not want to have to deal with watir elements. Not to mention the amount of code that would fail with such changes if someone was to try to update.\r\n \r\n> It seems to me you could support both watir-webdriver and selenium, but internally use watir-webdriver. Then the big difference would be if someone configured their system to use selenium webdriver, the elements could return the selenium element instead of the watir element. Which type of element to return could also be gathered from whether a Selenium::WebDriver or a Watir::Browser is passed in, essentially leaving the api the same.\r\n\r\n\r\n\r\n jkotests commented\r\n> @daneandersen, yes that was what I was thinking, but worded poorly in the prior comment. The API would not change:\r\n \r\n> Page objects could still be initialized by passing in a Watir::Browser or Selenium::WebDriver.\r\nPageObject#browser would continue to return a Watir::Browser or Selenium::WebDriver (based on the object that was passed in during initialization).\r\nElement#element would similarly still return a Watir::Element or Selenium::WebDriver::Element (based on the object that was passed in during initialization).\r\nAssuming this is the only way people are interacting with the native Watir/Selenium elements, there would be no change to them.\r\n\r\n> When doing the changes:\r\n\r\n> We would need to be careful to ensure that the same values are returned for other methods - for example attribute returns nil for Selenium and \"\" for Watir.\r\nWe would also have to decide what to do with exceptions. Do we expect to get Selenium vs Watir exceptions? Would it be a big issue if Selenium users were getting Watir exceptions? Perhaps we should be raising PageObject exceptions instead."}}