> > Instead of #click, what happens if you do #href instead? Do you see the > difference in the results?
This comparison is no way related to what I am telling! I am saying something which selenium has the capability to automatically perform which we don't have to take care from our level(from WATIR) So your problem comes with usage of b.element() ? Then tell me how to achieve the same with standard WATIR API? by using visible: true? It's not exactly equivalent, it does the iteration between all the links and chooses the visible one. Along those lines, we could add better support for browser.a(link_text: > 'foo') to match what Selenium does. Yes, that's what I was about to say at my last mail, that seems to be good idea for me as well. On Wednesday, October 25, 2017 at 7:53:15 PM UTC+5:30, Titus Fortner wrote: > > Instead of #click, what happens if you do #href instead? Do you see the > difference in the results? > > Regardless of whether you understand the reasoning, I'm asking that you > not tell Watir users to use the element method. If there is something that > can't be solved without the element method, then we need to fix it. > > Along those lines, we could add better support for browser.a(link_text: > 'foo') to match what Selenium does. > Feel free to make a PR, or raise an issue and I'll get to it before the > next major release. > > Titus > > > On Wednesday, October 25, 2017 at 7:15:09 AM UTC-5, [email protected] > wrote: >> >> I don't understand what you mean by " you don't care about the resulting >> lack of encapsulation"? Care to explain? >> >> What's wrong with telling the users the way it works? I am confusing >> anything, I am pretty clear about what I talk >> >> I am telling If they use >> >> b.link(text: 'something').click >> >> it would form the xpath and it might miss to click the expected link if >> some other link which matches these xpath which were hidden >> >> but when they use >> b.element(link: 'something').click >> >> it would exactly point to the required link and receives the click >> >> b.element() also has the advatange of WATIR over simply calling >> driver.find_element() because it has 'element_call' before it actually >> interacts the element . So I am gaining the advantages of WATIR even when I >> use b.element() as well. >> >> I completely agree with you point that xpath is the good idea to the >> driver but bad idea to the users, there are many people to whom I am >> promoting WATIR for two reasons, >> >> 1)xpath formation >> >> 2) programming level waiting for an element(not from the driver level >> waiting which is happening in selenium) >> >> So I support for xpath creation of WATIR but I am opposing when people >> tend to use xpath when we can locate through any others locators which are >> available in selenium because of it's brittle nature and visibility problem >> if it's link. >> >> >> >> On Wednesday, October 25, 2017 at 5:19:31 PM UTC+5:30, Titus Fortner >> wrote: >> >>> We actually had a long discussion at the Ruby test code hackathon in >>> Toronto last month about the proper behavior of the #text and #text_content >>> methods and how they relate to the text locator (which handles String and >>> RegExp values differently). I came into it arguing for changing the text >>> locator to only find visible text, but after a lengthy considerations of >>> backward compatibility and the fundamentally unique nature of text nodes as >>> it relates to the DOM, especially considering the difficulties of dealing >>> with nested text nodes with various possibilities for hidden . It was >>> decided to keep the current text locator behavior for String values and to >>> adjust the text locator behavior for RegExp values to match. This provides >>> more flexibility and backward compatibility at the expense of being >>> potentially confusing for things with multiple matches. >>> >>> All of this being said, the correct response when using Watir is: >>> >>> browser.a(text: 'something', visible: true).click` >>> >>> There are several ways to accomplish this, but this is what fits our >>> API. Feel free to use any other way you want, >>> but it isn't helpful to tell other users to do things that encourages >>> them to work against rather than with our API. >>> >>> I get that you've found what you consider is a clever way to use Watir >>> and save a couple extra wire calls, and >>> that you don't care about the resulting lack of encapsulation. Good on >>> you. >>> This mailing list is not the right forum for you to push this idea, so >>> please stop. >>> >>> Thank you for your understanding. >>> >>> >>> >>> >>> >>> >>> On Wednesday, October 25, 2017 at 2:30:36 AM UTC-5, >>> [email protected] 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. >>>> >>>> On Tuesday, October 24, 2017 at 8:22:36 PM UTC+5:30, Titus Fortner >>>> wrote: >>>>> >>>>> If you want to use Watir without its powerful element location API, >>>>> and use only the element method and only Selenium locators, you are more >>>>> than welcome to do that. >>>>> But stop telling other users that it's the right way to do it or that >>>>> it's better, because it isn't. >>>>> >>>>> Watir provides an easy way for the user to combine multiple location >>>>> strategies to uniquely identify an element without needing to use XPath. >>>>> What Watir sends to the driver is irrelevant to the user. >>>>> >>>>> XPath for the user => Bad >>>>> XPath for the driver => Good >>>>> >>>>> Separating what the user knows and what the driver knows is the whole >>>>> point, and your comments are only confusing the issue. >>>>> >>>>> >>>>> >>>>> On Tuesday, October 24, 2017 at 4:39:48 AM UTC-5, >>>>> [email protected] wrote: >>>>>> >>>>>> yes, that's what I am saying xpath usage must be the last one. If we >>>>>> could use available selenium-webdriver locators then we need to prefer >>>>>> that >>>>>> one. >>>>>> >>>>>> On Monday, October 23, 2017 at 7:28:06 PM UTC+5:30, Titus Fortner >>>>>> wrote: >>>>>>> >>>>>>> The only reasons not to use xpath are that it is hard to read, and >>>>>>> difficult to write such that it is not brittle. Neither of these apply >>>>>>> to >>>>>>> how Watir implements its location system. >>>>>> >>>>>> >>>>>>> >>>>>>> -- -- 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.
