Re-rendering an entire page for each entry on a field is ridiculous
regardless of the industry. I get legacy apps and business or security
requirements, etc, etc, but this isn't 2002 any longer.
You are more than welcome to avoid the clear call by using #send_keys
instead of #set
On Sunday, March 26, 2017 at 11:35:45 PM UTC-5, Raja gopalan wrote:
>
> Why? It's an insurance application, each and every entry need a
> calculation So after enter the text field and pressing the tab key it
> refreshes because background calculation is essential, It's one of the
> famous insurance application. Have you heard of 'IDIT'?
>
> And not only that, @element.clear slows down the process, but writing
> @element.send_keys [:control,"a"],*args doesn't slow down the process
> because [:control,"a"] one of the key it doesn't require a big process like
> @element.clear. Both does the same Job perfectly.
>
> What we might be willing to do is to provide a command that will enter
> text by JavaScript. I'm curious if that would solve your problem.
>
>
> what JavaScript code you are talking about? Is it
>
> document.getElementById("something").value = 232
>
> Is this one?
>
> On Sunday, March 26, 2017 at 3:02:07 PM UTC-7, Titus Fortner wrote:
>>
>> No, it does not make sense to do that kind of workaround to a basic
>> WebDriver call. A website that refreshes when making a clear call to a text
>> field sounds like a nightmare to test, but that one is on whoever decided
>> that could possibly be a good website design choice. :)
>>
>> What we might be willing to do is to provide a command that will enter
>> text by JavaScript. I'm curious if that would solve your problem.
>>
>> On Sun, Mar 26, 2017 at 12:32 PM, Raja gopalan <[email protected]>
>> wrote:
>>
>>> I completely agree, WATIR does it's extraordinary performance in the
>>> case of stale element reference error, the only reason is because it
>>> continue to invoke the find_element until it finds the element and I know
>>> that's the reason WATIR avoids implicit wait. That's excellent. But you are
>>> not caring certain places which falls into the infinite loop which I
>>> explained earlier, For an example,
>>>
>>> Consider this following code
>>>
>>> def set(*args)
>>> element_call(:wait_for_writable) do
>>> @element.clear
>>> @element.send_keys(*args)
>>> end
>>> end
>>>
>>>
>>> What my application does is, it refreshes the page after the clearing
>>> the element, So after @element.clear,( since page got refreshed), @element
>>> object is stale now, So @element.send_keys throws the error but it's been
>>> caught by the given block below
>>>
>>> begin
>>> send exist_check
>>> yield
>>> rescue Selenium::WebDriver::Error::StaleElementReferenceError
>>> retry
>>> ensure
>>> Wait.timer.reset! unless already_locked
>>> end
>>>
>>> So it is retrying, but what happens is, once again it starts from the
>>> beginning, So when it executes @element.clear, it once again goes to stale
>>> state, So it falls into the infinite loop and it never comes out. So what
>>> you would have done here is,
>>>
>>> you could have written the code like given below
>>>
>>> def set(*args)
>>> element_call(:wait_for_writable) do
>>> @element.send_keys([:control,"a"],*args)
>>> end
>>> end
>>>
>>>
>>> Now the problem solved because choosing the entire cell content and then
>>> writing on it automatically does the clearing Job. So the element doesn't
>>> go stale in this case.
>>>
>>>
>>>
>>>
>>> On Friday, March 24, 2017 at 12:25:36 PM UTC-7, Titus Fortner wrote:
>>>>
>>>> Yes, Watir is slower. Think of Selenium as a "Do What I Say" tool. If
>>>> you can enumerate exactly what you need using its low level commands then
>>>> you can be very performant. Watir is a "Do What I Mean" tool. Watir's goal
>>>> is not speed, but ease of writing, ease of maintenance, consistency of
>>>> results, and usefulness of error messages for debugging.
>>>>
>>>> There are many advantages to using Watir over Selenium directly which I
>>>> need to spend time enumerating in a blog post at some point, but the two
>>>> most important things that Watir does right now is automatically handle
>>>> Stale Element Reference errors (the bane of many test automation suites),
>>>> and automatically wait for the site's condition to be synchronized with
>>>> what is expected of the test based on the Watir code. There are many other
>>>> conveniences that may not always be needed but are provided by default so
>>>> that no user has to do extra work to handle it when it is necessary.
>>>>
>>>> Watir can slow things down a little or a lot depending on what you are
>>>> trying to do. I have some ideas to increase performance in some
>>>> situations,
>>>> but again, my focus is primarily on making it easy for people who don't
>>>> know all the details of their website's implementation to get consistent
>>>> results.
>>>>
>>>> Titus
>>>>
>>>>
>>>> On Thursday, March 23, 2017 at 12:16:00 PM UTC-5, Raja gopalan wrote:
>>>>>
>>>>> Titus, I stongly believe checking enabled? present? writable? methods
>>>>> are unnecessary calls by WATIR because we know what kind of field we are
>>>>> going to interact so these calls to every element slows down the process
>>>>> So
>>>>> what I did was, I have CALLED the driver out of WATIR and started writing
>>>>> selenium code and wherever I want the help of WATIR help like
>>>>> b.table.rows.each, I will write watir code and also If I know there are
>>>>> certain element starts to appear after the click then I write watir code,
>>>>> So I am mixing the selenium code and WATIR code as shown below,
>>>>>
>>>>> For an example, look at the code below and see how I have mixed the
>>>>> selenium code and WATIR CODE
>>>>>
>>>>> require 'watir'
>>>>>
>>>>> class Cable
>>>>>
>>>>> def initialize
>>>>> caps = Selenium::WebDriver::Remote::Capabilities.firefox(marionette:
>>>>> false)
>>>>> @b=Watir::Browser.new :firefox, desired_capabilities: caps
>>>>> @b.goto 'smcnet.in/'
>>>>> @[email protected]
>>>>> end
>>>>>
>>>>> def call
>>>>> @driver.find_element(:id, 'username').send_keys 'raja'
>>>>> @driver.find_element(:id, 'password').send_keys ''
>>>>> @driver.find_element(:xpath, "//*[@value='Log In']").click
>>>>> @driver.find_element(link: 'My Plan').click
>>>>> @b.element(xpath: "//span[normalize-space(.)='usage details']").click
>>>>> # WATIR CODE
>>>>> puts @b.div(:text, 'MB Used').following_sibling.span.text
>>>>> # WATIR CODE
>>>>> puts @b.div(:text, 'Days Remaining').following_sibling.span.text
>>>>> # WATIR CODE
>>>>> @driver.find_element(link: 'Hi, RAJAGOPALAN M').click
>>>>> @driver.find_element(:xpath, '//li[3]/a').click
>>>>> # @driver.quit
>>>>> end
>>>>> end
>>>>>
>>>>>
>>>>> On Thursday, March 23, 2017 at 10:06:26 AM UTC-7, Titus Fortner wrote:
>>>>>>
>>>>>> Yes, #present? is a combination of #exists? and #visible?
>>>>>>
>>>>>> Also, with Watir 6, you are less likely to need to make this call
>>>>>> explicitly in the code. Taking actions on an element will automatically
>>>>>> wait for element to be present if necessary.
>>>>>>
>>>>> --
>>> --
>>> 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.
