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

Discussion:

Raja gopalan

2017-08-12 16:12:53 UTC

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.

watir-***@googlegroups.com
http://groups.google.com/group/watir-general
watir-general+***@googlegroups.com

---
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 watir-general+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Titus Fortner

2017-08-12 18:53:32 UTC

Permalink

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.

Post by Raja gopalan
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.

watir-***@googlegroups.com
http://groups.google.com/group/watir-general
watir-general+***@googlegroups.com

---
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 watir-general+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Raja gopalan

2017-08-12 19:30:35 UTC

Permalink

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

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.

Post by Raja gopalan
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?

Titus Fortner

2017-08-12 20:26:42 UTC

Permalink

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.

*"Yes, I have written about my desire for users not to need to know XPath

Post by Titus Fortner
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.

Post by Titus Fortner
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.

Post by Raja gopalan
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?

Raja gopalan

2017-08-13 04:56:30 UTC

Permalink

Ok that makes sense.

Post by Titus Fortner
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
`Watir.loger.level = :debug` and it will show each translation.

*"Yes, I have written about my desire for users not to need to know XPath

Post by Titus Fortner
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.

Post by Titus Fortner
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.

Post by Raja gopalan
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
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.
http://groups.google.com/group/watir-general
---
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
For more options, visit https://groups.google.com/d/optout.

r***@gmail.com

2017-08-14 11:39:41 UTC

Permalink

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.

*"Yes, I have written about my desire for users not to need to know XPath

Post by Titus Fortner
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.

Post by Titus Fortner
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.

Post by Raja gopalan
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
"//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?

Titus Fortner

2017-08-14 14:17:17 UTC

Permalink

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, <***@gmail.com> 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.

*"Yes, I have written about my desire for users not to need to know XPath

Post by Titus Fortner
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.

Post by Titus Fortner
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.

Post by Raja gopalan
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
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.

watir-***@googlegroups.com
http://groups.google.com/group/watir-general
watir-general+***@googlegroups.com

---
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 watir-general+***@googlegroups.com.
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.

watir-***@googlegroups.com
http://groups.google.com/group/watir-general
watir-general+***@googlegroups.com

---
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 watir-general+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

r***@gmail.com

2017-08-14 14:58:35 UTC

Permalink

Thank you Titus!

Post by 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.
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.

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

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.

Post by Raja gopalan
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
"//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?

Raja gopalan

2017-08-12 19:35:10 UTC

Permalink

Post by Titus Fortner
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.

Yes, that would be great!

Post by Titus Fortner

Post by Raja gopalan
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?