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 <rajagopa...@gmail.com>
>> 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/'
>>>>> @driver=@b.driver
>>>>> 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.
>>>
>>> watir-...@googlegroups.com
>>> http://groups.google.com/group/watir-general
>>> watir-genera...@googlegroups.com
>>>
>>> ---
>>> 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 watir-genera...@googlegroups.com.
>>> 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.
watir-general@googlegroups.com
http://groups.google.com/group/watir-general
watir-general+unsubscr...@googlegroups.com
---
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 watir-general+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
