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]
> <javascript:>> 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] <javascript:>
>> http://groups.google.com/group/watir-general
>> [email protected] <javascript:>
>>
>> ---
>> 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] <javascript:>.
>> 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.
