Sorry, no, these changes are not available in 6.10.1. There are still changes I want to do for the simplify_locator branch. However, if the current state solves your problem, I can see if I get something merged in sooner.
Justin On Wednesday, December 13, 2017 at 1:42:05 AM UTC-5, [email protected] wrote: > > This change available in recent water 6.10.1? > > On Tuesday, December 12, 2017 at 11:39:51 PM UTC+5:30, Justin Ko wrote: >> >> Rajagopalan, would you be able to see if the changes I have made in >> https://github.com/jkotests/watir/tree/simplify_locator fixes the >> performance problem for :visible_text? >> >> I think the problem is where we filter elements: >> >> def filter_elements_by_locator(elements, visible = nil, visible_text = >> nil, idx = nil, tag_name: nil, filter: :first) >> elements.select! { |el| visible == el.displayed? } unless visible.nil? >> elements.select! { |el| visible_text === el.text } unless visible_text. >> nil? >> elements.select! { |el| element_validator.validate(el, {tag_name: >> tag_name}) } unless tag_name.nil? >> filter == :first ? elements[idx || 0] : elements >> end >> >> >> We apply the filter to every element found, even if you just want the >> first one. The changes I have in progress switch this to be lazy - ie we >> would only need to inspect the first link that matches. For a page with a >> lot of links, I believe this would increase performance a lot. >> >> Justin >> >> >> On Tuesday, December 12, 2017 at 12:56:46 PM UTC-5, rajagopalan madasami >> wrote: >>> >>> I am using watir over selenium for two reasons, one reason is waiting >>> timings are maintained by local language binding but selenium is >>> maintaining timing from driver level , since selenium uses the timing from >>> driver level it differs from Firefox to Chrome, but since WATIR is >>> maintaining timing from local language binding it doesn't matter whether I >>> use Chrome or Firefox. Another reason is stale element problem, WATIR >>> relocates the element when element goes to stale other than that I don't >>> use any other features of WATIR because everything else is time consuming >>> like xpah formation. So if you simply allow element () to access selenium >>> locators directly it would be useful for me rather than unnecessary >>> deprecating what word extraordinary. >>> >>> On 12-Dec-2017 11:06 PM, "Titus Fortner" <[email protected]> wrote: >>> >>>> Hey Chuck, >>>> >>>> Especially with Watir 6, there are some good synchronization reasons to >>>> prefer Watir over default selenium, even if not taking advantage of the >>>> improved encapsulation of the subclasses or the more advanced locator >>>> strategies. Though, not so many that it might not be worth it for him to >>>> roll his own at that point. Depends on how much else in the Watir >>>> ecosystem >>>> he is relying on. >>>> >>>> Titus >>>> >>>> >>>> >>>> >>>> On Tuesday, December 12, 2017 at 11:20:28 AM UTC-6, Chuck van der >>>> Linden wrote: >>>>> >>>>> bah... need to be able to edit... I confused using .link method of >>>>> watir with the :link locator type of Selenium... please disregard the >>>>> confusion over that sentence. >>>>> >>>>> Point being however that you seem wedded to directly using .element >>>>> and selenium selection methods, so the question of why even use Watir as >>>>> opposed to Selenium, given your preferences, still exists. >>>>> >>>>> On Tuesday, December 12, 2017 at 9:17:10 AM UTC-8, Chuck van der >>>>> Linden wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Monday, December 11, 2017 at 10:29:52 PM UTC-8, >>>>>> [email protected] wrote: >>>>>>> >>>>>>> Can you please pay a little attention to the ongoing conversation? >>>>>>> The conversation is not about using element() or using link() function, >>>>>>> the >>>>>>> conversation is about performance issue while I use visible text. I am >>>>>>> ready to use visible text If it does the good performance but it's not >>>>>>> doing it, I am trying to click a link which takes minutes to click that >>>>>>> link but when I use link locator it clicks instantly. >>>>>>> >>>>>> >>>>>> You say that, yet every code example I see from you uses .element >>>>>> >>>>>> Then we have statements like this: >>>>>> >>>>>>> Yes, I agree using b.link() increases the performance, But I >>>>>>> completely against the idea of not using the link: locator of selenium. >>>>>> >>>>>> >>>>>> (given the sentence makes no sense if parsed using the double >>>>>> negative (in which case you would already be using .link, which you are >>>>>> not), I presume that 'not' in the above is a typo) >>>>>> >>>>>> So despite people telling you to use .link, you seem insistent on >>>>>> using .element. which is basically the same as using raw Webdriver >>>>>> instead >>>>>> of Watir. So frankly I don't think my question is that out of line. If >>>>>> you insist on using .element, and are as you stated 'completely against >>>>>> the >>>>>> idea' of using the watir API, then why use Watir and not just use >>>>>> webdriver >>>>>> directly? >>>>>> >>>>>> In terms of performance: >>>>>> As Titus asked earlier, can you provide a code example that >>>>>> demonstrates the performance difference you are claiming to see? not a >>>>>> discussion of code, but actual code against an actual site. >>>>>> >>>>> -- >>>> -- >>>> 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. >>>> >>> -- -- 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.
