> You realize you are effectively trying to 'mansplain' to one of the > developers of Watir why not to use a majority of the Watir API? If you > are just going to use b.element all the time, instead of making use of the > Watir API and object model, then what is even the point of using Watir? > why not just use nakid Webdriver?
I am not sure how my message is reaching you this way! I seriously wonder! I have never asked to b.element() all the time, only when it's required! As I explained, b.element(link: 'something').click the aforementioned code would click the visible link, how do you achieve by standard WATIR api? there is a way you could write b.link(text: 'something', visible: 'true').click but the above code would perform the iteration to find out the visible link. So why not someone can simply use the code which I mentioned? b.element() is NOT completely equivalent to driver.find_element(), it does element_call before it interacts the element, it waits for exists? visible? enabled? before it interacts the element, but if you use driver.find_element() plainly then it's waiting is depending upon which native driver you are using. So b.element() uses WATIR advantages here. I'm only a water user and ex 'support sherif', not a committer, so my > opinion may not hold as much Weight as Titus's, but my approach has always > been to use the method/object (one begets the other) closest to the HTML > element type I am dealing with. So if I am working with a div, I use > b.div etc. I only use b.element as a last resort. I honestly don't care > how watir casts my selections and if it's sending xpath to the driver or > not, I'm happy to use the API as intended as this for me results in the > cleanest easiest to read code.. That said, I avoid actual xpath in how I > specify selections, where I prefer to use watir's native selectors, or css > selectors and only use xpath if nothing else will work. (because I find > xpath hard for humans to read, and often brittle if long paths are given) I usually select the code according to the usuage, for an example, If you use b.element(id: 'something').click it would no way differ from the below code b.div(id: 'something').click because WATIR coverts the both of the above code into driver.find_element(id: 'something').click So if you use b.div() or b.element() it doesn't differ much in any way But there is a difference when you pass the locators which are not in selenium webdriver's list and it's specific to WATIR for an example, If you write b.element(text: 'something').click this absolutely differ from the following code b.div(text: 'something').click WATIR coverts the first one into driver.find_element(xpath: "//*[normalize-space()='something']).click and it converts the second one into driver.find_element(xpath: "//div[noramlize-space()='something']).click Do you feel the difference? And also WATIR does the tremendous difference while forming xpath in some other places when we have long path but I am not going write about that here since you are not much interested in xpath and how WATIR converts at the back. On Thursday, October 26, 2017 at 4:50:33 AM UTC+5:30, Chuck van der Linden wrote: > > On Wednesday, October 25, 2017 at 12:30:36 AM UTC-7, > rajagopal...@gmail.com <javascript:> wrote: >> >> Please reject my last mail, I was wrong about b.link(link_text: >> 'something').click >> >> Read this one, I have explained the advantage of link: over xpath: >> b.element(text: 'something').click >> >> >> It would create the selenium equivalent of >> >> driver.find_element(xpath: "//*[noramlize-space()='something']").click >> >> It would perfectly work if this xpath matches only one, but there are >> more and rest of them are hidden it would choose to click the first one, >> not the one which is visible, but If you write the below code >> >> b.element(link: 'something').click >> >> It would write the selenium equivalent of >> >> driver.find_element(link: 'something').click >> >> >> it would perfectly choose the visible one by rejecting all the invisible >> one, >> >> >> You may say to me that I could achieve the same by passing 'visible: >> true' as the second parameter, but WATIR does here is, it iterates over all >> the links before it chooses the visible one. >> >> So using link: over xpath: has many advantages, That's why I said we need >> to go for xpath when we can't use any other available locators. >> >>> >>>>> > > > I'm only a water user and ex 'support sherif', not a committer, so my > opinion may not hold as much Weight as Titus's, but my approach has always > been to use the method/object (one begets the other) closest to the HTML > element type I am dealing with. So if I am working with a div, I use > b.div etc. I only use b.element as a last resort. I honestly don't care > how watir casts my selections and if it's sending xpath to the driver or > not, I'm happy to use the API as intended as this for me results in the > cleanest easiest to read code.. That said, I avoid actual xpath in how I > specify selections, where I prefer to use watir's native selectors, or css > selectors and only use xpath if nothing else will work. (because I find > xpath hard for humans to read, and often brittle if long paths are given) > -- -- Before posting, please read http://watir.com/support. In short: search before you ask, be nice. watir-general@googlegroups.com http://groups.google.com/group/watir-general watir-general+unsubscr...@googlegroups.com --- You received this message because you are subscribed to the Google Groups "Watir General" group. To unsubscribe from this group and stop receiving emails from it, send an email to watir-general+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
