> 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, > [email protected] <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. [email protected] http://groups.google.com/group/watir-general [email protected] --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
