Thank you Titus! On Monday, August 14, 2017 at 7:47:23 PM UTC+5:30, Titus Fortner wrote: > > That definitely needs to be updated. Watir 6+ makes the use of selenium's > implicit wait functionality completely unnecessary / actively bad for the > reasons you describe. > > > > On Aug 14, 2017 9:04 AM, <[email protected] <javascript:>> wrote: > > And other thing I want to point it out here is implicit wait. > > Here you have talked about implicit and explicit wait > > http://watir.com/docs/waiting/ > > > You have mentioned about the implicit wait here, but this is not implicit > wait at all for WATIR, WATIR has nothing to do with implicit wait, WATIR is > completely closing this implicit wait to make sure that the following > function works properly > > exists? > visible? > present? > enabled? > > The above function has to work at the moment program reaches to the line > where it's written, If "exists?" method is called, then WATIR should not > wait implicitly until the element exists because that's meaningless, But If > you give implicit wait here, then when the 'exists?' function is called, it > would implicitely wait until time you have given, then it throw true or > false. That's meaningless. WATIR does closes this implicit wait perfectly > for this reason, but If we still touch the implicit wait of selenium, it > clearly spoils out the the way WATIR gets executed. > > for an example, > > If you write > > b.element(id: 'something').exists? > > It will first invoke > > driver.find_element(id: 'something') > > when the exists? method is called, So it would wait implicitly until the > element exists then it will tell you whether it's true or false. > > then it call exists? method, so it spoils the WATIR structure. > > > On Sunday, August 13, 2017 at 1:56:42 AM UTC+5:30, Titus Fortner wrote: >> >> I see what you are saying. Having an "under the hood" page. We could also >> reference Alex's Watizzle implementation. >> I don't think we'd want that on the main location page, because for most >> people it matters the what of the things you can do, not as much the how of >> its implementation. >> >> Also, for reference, we've added logging that allows you to better see >> what the underlying xpath translation is: >> `Watir.loger.level = :debug` and it will show each translation. >> >> >> On Saturday, August 12, 2017 at 2:30:35 PM UTC-5, Raja gopalan wrote: >>> >>> *"Yes, I have written about my desire for users not to need to know >>>> XPath before: http://watir.com/watir-6-2/#adjacent-element-location >>>> <http://watir.com/watir-6-2/#adjacent-element-location>"* >>> >>> >>> Yes, I have read that, but that doesn't detail much, I am talking about >>> explaining what kind of xpath a particular WATIR code would form, So that >>> it would be useful, for an example, >>> >>> If I write >>> >>> b.span(id: 'something').click >>> >>> This one doesn't form any xpath >>> >>> But this one >>> >>> b.span(text: 'something').click >>> >>> and >>> >>> b.element(text: 'something').click >>> >>> creates the below two selenium code with xpath respectively. >>> >>> driver.find_element(xpath: "//span[normalize-space()='something']).click >>> >>> and >>> >>> driver.find_element(xpath: "//*[normalize-space()='something']).click >>> >>> >>> So one who knows what WATIR does behind the scene can write the better >>> code. And this should be explained in detail. >>> >>> >>> >>> On Sunday, August 13, 2017 at 12:23:32 AM UTC+5:30, Titus Fortner wrote: >>>> >>>> Yes, I have written about my desire for users not to need to know XPath >>>> before: http://watir.com/watir-6-2/#adjacent-element-location >>>> That framing did not end up in the documentation updates I just made, >>>> but likely deserves to be added. >>>> >>>> Ideally that one page on element location gets split out into 10 pages >>>> (one for each of the unique Watir locators), with thorough exploration of >>>> examples and working code. >>>> https://github.com/watir/watir.github.io/issues/101 >>>> >>>> I'm tentatively thinking about pulling in all of the html code we use >>>> in our watirspecs onto the website, in order to have static pages to write >>>> examples with. We could then copy and paste a lot of existing code in the >>>> specs. >>>> >>>> >>>> >>>> >>>> On Saturday, August 12, 2017 at 11:12:54 AM UTC-5, Raja gopalan wrote: >>>>> >>>>> >>>>> Hi Titus, >>>>> >>>>> I read your recent document addition in WATIR site, it's looks great >>>>> for a new comer. but, >>>>> >>>>> I believe one of the biggest area WATIR has the advantage over >>>>> Selenium is, It's capacity to eliminate the xpath conversation, but how >>>>> and >>>>> when it happened, it's not explained anywhere, I debugged the WATIR code >>>>> and understand it by myself. So a newcomer might not be aware of such an >>>>> wonderful feature. >>>>> >>>>> For an example, >>>>> >>>>> WATIR has never go for framing the xpath if the received locator is >>>>> available in selenium but it goes to create the xpath if the given >>>>> locator >>>>> is not available in selenium. And I believe this has to be explained. For >>>>> an example, there are some key points has to explained which I cited >>>>> below, >>>>> >>>>> If I write this code >>>>> >>>>> b.span(id: 'something').click >>>>> >>>>> >>>>> it's completely equivalent to writing >>>>> >>>>> b.element(id: 'something').click >>>>> >>>>> >>>>> calling span() function useless in this place because as soon as WATIR >>>>> sees the id it immediately goes to call the find_element function >>>>> directly >>>>> by taking id locator like given below >>>>> >>>>> driver.find_element(id: 'something').click >>>>> >>>>> So wrapping up using span is useless here, I agree there are certain >>>>> places it's useful when someone wants to call specific function, so in >>>>> this >>>>> case the required receiver is important like >>>>> >>>>> b.element(id: 'something').send_keys 'hi' >>>>> >>>>> With the above code one can't call set function, unless he calls the >>>>> text_field() function like >>>>> >>>>> b.text_field(id: 'something').set 'hi' >>>>> >>>>> >>>>> But in most of the cases it's not useful to call such a specific >>>>> function, but you may ask me like it anyhow is going to do the same job >>>>> then why we need to bother about that? Actually when we invoke this way >>>>> >>>>> b.span(id: 'something').click >>>>> >>>>> People might not be knowing the specific importance of calling span >>>>> function using WATIR, for an example, WATIR does a amazing Job if it's >>>>> called as given below >>>>> >>>>> b.span(text: 'something').click >>>>> >>>>> Here text locator is not available in selenium so WATIR is going to >>>>> create the xpath using the above code like >>>>> >>>>> driver.find_element(xpath: >>>>> "//span[normalize-space()='something']).click >>>>> >>>>> Now the importance of calling b.span() becomes very clear and it's not >>>>> useless here, but such an important information is not available anywhere >>>>> So if it's included in the document, it would be great! >>>>> >>>>> What do you say? >>>>> >>>> -- > -- > 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.
