ok On Monday, March 27, 2017 at 2:18:04 PM UTC-7, Titus Fortner wrote: > > 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] > <javascript:>> 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] <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.
