Making a single wire call is not a heavy function. Watir makes it easy to avoid what your site is making difficult with #send_keys, but the default behavior for #set will continue to include the W3C specification supported means for clearing a field.
(also of note, your code example is not platform independent) On Mon, Mar 27, 2017 at 1:35 PM, Raja gopalan <[email protected]> wrote: > 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. > -- -- 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.
