Re: [wtr-general] Re: This must be added into the recent Documentation in WATIR

[rajagopalanmadasami]

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,  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 
 "*
>>>
>>>
>>> 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 

Re: [wtr-general] Re: This must be added into the recent Documentation in WATIR

[Titus Fortner]

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,  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
>>> "*
>>
>>
>> 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 

Re: [wtr-general] Re: This must be added into the recent Documentation in WATIR

[Raja gopalan]

Ok that makes sense.

On Aug 13, 2017 1:56 AM, "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
>>> "*
>>
>>
>> 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()='som
 ething']).click

 Now the importance of calling b.span() becomes very clear and it's not