Why do you want to execute such heavy function instead of passing a another 
key that would clear your text box? [:control,"a"]

On Monday, March 27, 2017 at 8:43:43 AM UTC-7, Titus Fortner wrote:
>
> 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.

Reply via email to