Re: [wtr-general] Re: link and link_text not working in Watir 6?

[rajagopalan madasami]

No problem

On 26-Oct-2017 9:05 PM, "Titus Fortner"  wrote:

> I can't tell if you are trolling or just intentionally missing the point.
>
> The use of the element method is never *required. You may prefer it for
> your own reasons, but that's not the same.
>
> I think I've made my reasonable request clear, even if you don't
> understand it. I'm done explaining this.
>
>
>
> On Thursday, October 26, 2017 at 12:16:18 AM UTC-5, rajagopal...@gmail.com
> wrote:
>>
>> Non-standard usage? But still it's taking an advantages of WATIR,
>> b.element() is not completely equivalent to driver.find_element(), it does
>> the element_call so many things are taken care of!
>>
>> On Thursday, October 26, 2017 at 5:20:12 AM UTC+5:30, Titus Fortner wrote:
>>>
>>> There are some good reasons to use watir 6+ even when not taking full
>>> advantage of the location API. I'm behind on blogging all these things.
>>>
>>> I just don't want to encourage non standard usage in our official
>>> mailing list.
>>>
>>>
>>>
>>>
>
>
> --
> --
> Before posting, please read http://watir.com/support. In short: search
> before you ask, be nice.
>
> watir-general@googlegroups.com
> http://groups.google.com/group/watir-general
> watir-general+unsubscr...@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+unsubscr...@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-general@googlegroups.com
http://groups.google.com/group/watir-general
watir-general+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[wtr-general] Re: link and link_text not working in Watir 6?

[Titus Fortner]

I can't tell if you are trolling or just intentionally missing the point.

The use of the element method is never *required. You may prefer it for 
your own reasons, but that's not the same.

I think I've made my reasonable request clear, even if you don't understand 
it. I'm done explaining this. 



On Thursday, October 26, 2017 at 12:16:18 AM UTC-5, rajagopal...@gmail.com 
wrote:
>
> Non-standard usage? But still it's taking an advantages of WATIR, 
> b.element() is not completely equivalent to driver.find_element(), it does 
> the element_call so many things are taken care of! 
>
> On Thursday, October 26, 2017 at 5:20:12 AM UTC+5:30, Titus Fortner wrote:
>>
>> There are some good reasons to use watir 6+ even when not taking full 
>> advantage of the location API. I'm behind on blogging all these things.
>>
>> I just don't want to encourage non standard usage in our official mailing 
>> list.
>>
>>
>>
>>
 

-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

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

[wtr-general] Re: link and link_text not working in Watir 6?

[rajagopalanmadasami]

Non-standard usage? But still it's taking an advantages of WATIR, 
b.element() is not completely equivalent to driver.find_element(), it does 
the element_call so many things are taken care of! 

On Thursday, October 26, 2017 at 5:20:12 AM UTC+5:30, Titus Fortner wrote:
>
> There are some good reasons to use watir 6+ even when not taking full 
> advantage of the location API. I'm behind on blogging all these things.
>
> I just don't want to encourage non standard usage in our official mailing 
> list.
>

-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

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

[wtr-general] Re: link and link_text not working in Watir 6?

[rajagopalanmadasami]

>
> Instead of #click, what happens if you do #href instead? Do you see the 
> difference in the results?

 
This comparison is no way related to what I am telling! 

I am saying something which selenium has the capability to automatically 
perform which we don't have to take care from our level(from WATIR)

So your problem comes with usage of b.element() ? Then tell me how to 
achieve the same with standard WATIR API? by using visible: true? It's not 
exactly equivalent, it does the iteration between all the links and chooses 
the visible one. 

Along those lines, we could add better support for browser.a(link_text: 
> 'foo') to match what Selenium does.


Yes, that's what I was about to say at my last mail, that seems to be good 
idea for me as well. 

On Wednesday, October 25, 2017 at 7:53:15 PM UTC+5:30, Titus Fortner wrote:
>
> Instead of #click, what happens if you do #href instead? Do you see the 
> difference in the results?
>
> Regardless of whether you understand the reasoning, I'm asking that you 
> not tell Watir users to use the element method. If there is something that 
> can't be solved without the element method, then we need to fix it.
>
> Along those lines, we could add better support for browser.a(link_text: 
> 'foo') to match what Selenium does.
> Feel free to make a PR, or raise an issue and I'll get to it before the 
> next major release.
>
> Titus
>
>
> On Wednesday, October 25, 2017 at 7:15:09 AM UTC-5, rajagopal...@gmail.com 
> wrote:
>>
>>  I don't understand what you mean by " you don't care about the resulting 
>> lack of encapsulation"? Care to explain? 
>>
>> What's wrong with telling the users the way it works? I am confusing 
>> anything, I am pretty clear about what I talk 
>>
>> I am telling If they use
>>
>> b.link(text: 'something').click
>>
>> it would form the xpath and it might miss to click the expected link if 
>> some other link which matches these xpath which were hidden
>>
>> but when they use
>> b.element(link: 'something').click
>>
>> it would exactly point to the required link and receives the click
>>
>> b.element() also has the advatange of WATIR over simply calling 
>> driver.find_element() because it has 'element_call' before it actually 
>> interacts the element . So I am gaining the advantages of WATIR even when I 
>> use b.element() as well. 
>>
>> I completely agree with you point that xpath is the good idea to the 
>> driver but bad idea to the users, there are many people to whom I am 
>> promoting WATIR for two reasons,
>>
>> 1)xpath formation
>>
>> 2) programming level waiting for an element(not from the driver level 
>> waiting which is happening in selenium)
>>
>> So I support for xpath creation of WATIR but I am opposing when people 
>> tend to use xpath when we can locate through any others locators which are 
>> available in selenium because of it's brittle nature and visibility problem 
>> if it's link. 
>>  
>>
>>
>> On Wednesday, October 25, 2017 at 5:19:31 PM UTC+5:30, Titus Fortner 
>> wrote:
>>
>>> We actually had a long discussion at the Ruby test code hackathon in 
>>> Toronto last month about the proper behavior of the #text and #text_content 
>>> methods and how they relate to the text locator (which handles String and 
>>> RegExp values differently). I came into it arguing for changing the text 
>>> locator to only find visible text, but after a lengthy considerations of 
>>> backward compatibility and the fundamentally unique nature of text nodes as 
>>> it relates to the DOM, especially considering the difficulties of dealing 
>>> with nested text nodes with various possibilities for hidden . It was 
>>> decided to keep the current text locator behavior for String values and to 
>>> adjust the text locator behavior for RegExp values to match. This provides 
>>> more flexibility and backward compatibility at the expense of being 
>>> potentially confusing for things with multiple matches.
>>>
>>> All of this being said, the correct response when using Watir is:
>>>
>>> browser.a(text: 'something', visible: true).click`
>>>
>>> There are several ways to accomplish this, but this is what fits our 
>>> API. Feel free to use any other way you want,
>>> but it isn't helpful to tell other users to do things that encourages 
>>> them to work against rather than with our API.
>>>
>>> I get that you've found what you consider is a clever way to use Watir 
>>> and save a couple extra wire calls, and
>>> that you don't care about the resulting lack of encapsulation. Good on 
>>> you. 
>>> This mailing list is not the right forum for you to push this idea, so 
>>> please stop.
>>>
>>> Thank you for your understanding.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wednesday, October 25, 2017 at 2:30:36 AM UTC-5, 
>>> rajagopal...@gmail.com wrote:

 Please reject my last mail, I was wrong about b.link(link_text: 
 'something').click

 Read this one, I have explained the advantage of link: over xpath:
 b.element(text: 

[wtr-general] Re: link and link_text not working in Watir 6?

[rajagopalanmadasami]

> You realize you are effectively trying to 'mansplain' to one of the 
> developers of Watir why not to use a majority of the Watir API?   If you 
> are just going to use b.element all the time, instead of making use of the 
> Watir API and object model, then what is even the point of using Watir?  
> why not just use nakid Webdriver?



I am not sure how my message is reaching you this way! I seriously wonder! 
I have never asked to b.element() all the time, only when it's required!  
As I explained,

b.element(link: 'something').click

the aforementioned code would click the visible link, how do you achieve by 
standard WATIR api? there is a way you could write

b.link(text: 'something', visible: 'true').click

but the above code would perform the iteration to find out the visible 
link. So why not someone can simply use the code which I mentioned? 
b.element() is NOT completely equivalent to driver.find_element(), it does 
element_call before it interacts the element, it waits for  exists? 
visible? enabled? before it interacts the element, but if you use 
driver.find_element() plainly then it's waiting is depending upon which 
native driver you are using. So b.element() uses WATIR advantages here.



I'm only a water user and ex 'support sherif', not a committer, so my 
> opinion may not hold as much Weight as Titus's, but my approach has always 
> been to use the method/object (one begets the other) closest to the HTML 
> element type I am dealing with.  So if I am working with a div, I use 
> b.div  etc.  I only use b.element as a last resort.   I honestly don't care 
> how watir casts my selections and if it's sending xpath to the driver or 
> not, I'm happy to use the API as intended as this for me results in the 
> cleanest easiest to read code.. That said, I avoid actual xpath in how I 
> specify selections, where I prefer to use watir's native selectors, or css 
> selectors and only use xpath if nothing else will work.  (because I find 
> xpath hard for humans to read, and often brittle if long paths are given)   


 
I usually select the code according to the usuage, for an example,

If you use

b.element(id: 'something').click

it would no way differ from the below code

b.div(id: 'something').click

because WATIR  coverts the both of the above code into 

driver.find_element(id: 'something').click

So if you use b.div() or b.element() it doesn't differ much in any way

But there is a difference when you pass the locators which are not in 
selenium webdriver's list and it's specific to WATIR

for an example, 

If you write

b.element(text: 'something').click

this absolutely differ from the following code

b.div(text: 'something').click

WATIR coverts the first one into

driver.find_element(xpath: "//*[normalize-space()='something']).click

and it converts the second one into

driver.find_element(xpath: "//div[noramlize-space()='something']).click

Do you feel the difference? 


And also WATIR does the tremendous difference while forming xpath in some 
other places when we have long path but I am not going write about that 
here since you are not much interested in xpath and how WATIR converts at 
the back. 

On Thursday, October 26, 2017 at 4:50:33 AM UTC+5:30, Chuck van der Linden 
wrote:
>
> On Wednesday, October 25, 2017 at 12:30:36 AM UTC-7, 
> rajagopal...@gmail.com  wrote:
>>
>> Please reject my last mail, I was wrong about b.link(link_text: 
>> 'something').click
>>
>> Read this one, I have explained the advantage of link: over xpath:
>> b.element(text: 'something').click
>>
>>
>> It would create the selenium equivalent of 
>>
>> driver.find_element(xpath: "//*[noramlize-space()='something']").click
>>
>> It would perfectly work if this xpath matches only one, but there are 
>> more and rest of them are hidden it would choose to click the first one, 
>> not the one which is visible, but If you write the below code
>>
>> b.element(link: 'something').click
>>
>> It would write the selenium equivalent of 
>>
>> driver.find_element(link: 'something').click
>>
>>
>> it would perfectly choose the visible one by rejecting all the invisible 
>> one, 
>>
>>
>> You may say to me that I could achieve the same by passing 'visible: 
>> true' as the second parameter, but WATIR does here is, it iterates over all 
>> the links before it chooses the visible one. 
>>
>> So using link: over xpath: has many advantages, That's why I said we need 
>> to go for xpath when we can't use any other available locators. 
>>
>>>
>
>
>
> I'm only a water user and ex 'support sherif', not a committer, so my 
> opinion may not hold as much Weight as Titus's, but my approach has always 
> been to use the method/object (one begets the other) closest to the HTML 
> element type I am dealing with.  So if I am working with a div, I use 
> b.div  etc.  I only use b.element as a last resort.   I honestly don't care 
> how watir casts my selections and if it's sending xpath to the driver or 
> not, I'm happy to use the 

[wtr-general] Re: link and link_text not working in Watir 6?

[Titus Fortner]

There are some good reasons to use watir 6+ even when not taking full advantage 
of the location API. I'm behind on blogging all these things.

I just don't want to encourage non standard usage in our official mailing list.

-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

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

[wtr-general] Re: link and link_text not working in Watir 6?

[Chuck van der Linden]

On Wednesday, October 25, 2017 at 12:30:36 AM UTC-7, 
rajagopalanmadas...@gmail.com wrote:
>
> Please reject my last mail, I was wrong about b.link(link_text: 
> 'something').click
>
> Read this one, I have explained the advantage of link: over xpath:
> b.element(text: 'something').click
>
>
> It would create the selenium equivalent of 
>
> driver.find_element(xpath: "//*[noramlize-space()='something']").click
>
> It would perfectly work if this xpath matches only one, but there are more 
> and rest of them are hidden it would choose to click the first one, not the 
> one which is visible, but If you write the below code
>
> b.element(link: 'something').click
>
> It would write the selenium equivalent of 
>
> driver.find_element(link: 'something').click
>
>
> it would perfectly choose the visible one by rejecting all the invisible 
> one, 
>
>
> You may say to me that I could achieve the same by passing 'visible: true' 
> as the second parameter, but WATIR does here is, it iterates over all the 
> links before it chooses the visible one. 
>
> So using link: over xpath: has many advantages, That's why I said we need 
> to go for xpath when we can't use any other available locators. 
>
>>

You realize you are effectively trying to 'mansplain' to one of the 
developers of Watir why not to use a majority of the Watir API?   If you 
are just going to use b.element all the time, instead of making use of the 
Watir API and object model, then what is even the point of using Watir?  
why not just use nakid Webdriver?

I'm only a water user and ex 'support sherif', not a committer, so my 
opinion may not hold as much Weight as Titus's, but my approach has always 
been to use the method/object (one begets the other) closest to the HTML 
element type I am dealing with.  So if I am working with a div, I use 
b.div  etc.  I only use b.element as a last resort.   I honestly don't care 
how watir casts my selections and if it's sending xpath to the driver or 
not, I'm happy to use the API as intended as this for me results in the 
cleanest easiest to read code.. That said, I avoid actual xpath in how I 
specify selections, where I prefer to use watir's native selectors, or css 
selectors and only use xpath if nothing else will work.  (because I find 
xpath hard for humans to read, and often brittle if long paths are given)   

-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

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

[wtr-general] Re: link and link_text not working in Watir 6?

[Titus Fortner]

Instead of #click, what happens if you do #href instead? Do you see the 
difference in the results?

Regardless of whether you understand the reasoning, I'm asking that you not 
tell Watir users to use the element method. If there is something that 
can't be solved without the element method, then we need to fix it.

Along those lines, we could add better support for browser.a(link_text: 
'foo') to match what Selenium does.
Feel free to make a PR, or raise an issue and I'll get to it before the 
next major release.

Titus


On Wednesday, October 25, 2017 at 7:15:09 AM UTC-5, rajagopal...@gmail.com 
wrote:
>
>  I don't understand what you mean by " you don't care about the resulting 
> lack of encapsulation"? Care to explain? 
>
> What's wrong with telling the users the way it works? I am confusing 
> anything, I am pretty clear about what I talk 
>
> I am telling If they use
>
> b.link(text: 'something').click
>
> it would form the xpath and it might miss to click the expected link if 
> some other link which matches these xpath which were hidden
>
> but when they use
> b.element(link: 'something').click
>
> it would exactly point to the required link and receives the click
>
> b.element() also has the advatange of WATIR over simply calling 
> driver.find_element() because it has 'element_call' before it actually 
> interacts the element . So I am gaining the advantages of WATIR even when I 
> use b.element() as well. 
>
> I completely agree with you point that xpath is the good idea to the 
> driver but bad idea to the users, there are many people to whom I am 
> promoting WATIR for two reasons,
>
> 1)xpath formation
>
> 2) programming level waiting for an element(not from the driver level 
> waiting which is happening in selenium)
>
> So I support for xpath creation of WATIR but I am opposing when people 
> tend to use xpath when we can locate through any others locators which are 
> available in selenium because of it's brittle nature and visibility problem 
> if it's link. 
>  
>
>
> On Wednesday, October 25, 2017 at 5:19:31 PM UTC+5:30, Titus Fortner wrote:
>
>> We actually had a long discussion at the Ruby test code hackathon in 
>> Toronto last month about the proper behavior of the #text and #text_content 
>> methods and how they relate to the text locator (which handles String and 
>> RegExp values differently). I came into it arguing for changing the text 
>> locator to only find visible text, but after a lengthy considerations of 
>> backward compatibility and the fundamentally unique nature of text nodes as 
>> it relates to the DOM, especially considering the difficulties of dealing 
>> with nested text nodes with various possibilities for hidden . It was 
>> decided to keep the current text locator behavior for String values and to 
>> adjust the text locator behavior for RegExp values to match. This provides 
>> more flexibility and backward compatibility at the expense of being 
>> potentially confusing for things with multiple matches.
>>
>> All of this being said, the correct response when using Watir is:
>>
>> browser.a(text: 'something', visible: true).click`
>>
>> There are several ways to accomplish this, but this is what fits our API. 
>> Feel free to use any other way you want,
>> but it isn't helpful to tell other users to do things that encourages 
>> them to work against rather than with our API.
>>
>> I get that you've found what you consider is a clever way to use Watir 
>> and save a couple extra wire calls, and
>> that you don't care about the resulting lack of encapsulation. Good on 
>> you. 
>> This mailing list is not the right forum for you to push this idea, so 
>> please stop.
>>
>> Thank you for your understanding.
>>
>>
>>
>>
>>
>>
>> On Wednesday, October 25, 2017 at 2:30:36 AM UTC-5, 
>> rajagopal...@gmail.com wrote:
>>>
>>> Please reject my last mail, I was wrong about b.link(link_text: 
>>> 'something').click
>>>
>>> Read this one, I have explained the advantage of link: over xpath:
>>> b.element(text: 'something').click
>>>
>>>
>>> It would create the selenium equivalent of 
>>>
>>> driver.find_element(xpath: "//*[noramlize-space()='something']").click
>>>
>>> It would perfectly work if this xpath matches only one, but there are 
>>> more and rest of them are hidden it would choose to click the first one, 
>>> not the one which is visible, but If you write the below code
>>>
>>> b.element(link: 'something').click
>>>
>>> It would write the selenium equivalent of 
>>>
>>> driver.find_element(link: 'something').click
>>>
>>>
>>> it would perfectly choose the visible one by rejecting all the invisible 
>>> one, 
>>>
>>>
>>> You may say to me that I could achieve the same by passing 'visible: 
>>> true' as the second parameter, but WATIR does here is, it iterates over all 
>>> the links before it chooses the visible one. 
>>>
>>> So using link: over xpath: has many advantages, That's why I said we 
>>> need to go for xpath when we can't use any other available 

[wtr-general] Re: link and link_text not working in Watir 6?

[rajagopalanmadasami]

 I don't understand what you mean by " you don't care about the resulting 
lack of encapsulation"? Care to explain? 

What's wrong with telling the users the way it works? I am confusing 
anything, I am pretty clear about what I talk 

I am telling If they use

b.link(text: 'something').click

it would form the xpath and it might miss to click the expected link if 
some other link which matches these xpath which were hidden

but when they use
b.element(link: 'something').click

it would exactly point to the required link and receives the click

b.element() also has the advatange of WATIR over simply calling 
driver.find_element() because it has 'element_call' before it actually 
interacts the element . So I am gaining the advantages of WATIR even when I 
use b.element() as well. 

I completely agree with you point that xpath is the good idea to the driver 
but bad idea to the users, there are many people to whom I am promoting 
WATIR for two reasons,

1)xpath formation

2) programming level waiting for an element(not from the driver level 
waiting which is happening in selenium)

So I support for xpath creation of WATIR but I am opposing when people tend 
to use xpath when we can locate through any others locators which are 
available in selenium because of it's brittle nature and visibility problem 
if it's link. 
 


On Wednesday, October 25, 2017 at 5:19:31 PM UTC+5:30, Titus Fortner wrote:

> We actually had a long discussion at the Ruby test code hackathon in 
> Toronto last month about the proper behavior of the #text and #text_content 
> methods and how they relate to the text locator (which handles String and 
> RegExp values differently). I came into it arguing for changing the text 
> locator to only find visible text, but after a lengthy considerations of 
> backward compatibility and the fundamentally unique nature of text nodes as 
> it relates to the DOM, especially considering the difficulties of dealing 
> with nested text nodes with various possibilities for hidden . It was 
> decided to keep the current text locator behavior for String values and to 
> adjust the text locator behavior for RegExp values to match. This provides 
> more flexibility and backward compatibility at the expense of being 
> potentially confusing for things with multiple matches.
>
> All of this being said, the correct response when using Watir is:
>
> browser.a(text: 'something', visible: true).click`
>
> There are several ways to accomplish this, but this is what fits our API. 
> Feel free to use any other way you want,
> but it isn't helpful to tell other users to do things that encourages them 
> to work against rather than with our API.
>
> I get that you've found what you consider is a clever way to use Watir and 
> save a couple extra wire calls, and
> that you don't care about the resulting lack of encapsulation. Good on 
> you. 
> This mailing list is not the right forum for you to push this idea, so 
> please stop.
>
> Thank you for your understanding.
>
>
>
>
>
>
> On Wednesday, October 25, 2017 at 2:30:36 AM UTC-5, rajagopal...@gmail.com 
> wrote:
>>
>> Please reject my last mail, I was wrong about b.link(link_text: 
>> 'something').click
>>
>> Read this one, I have explained the advantage of link: over xpath:
>> b.element(text: 'something').click
>>
>>
>> It would create the selenium equivalent of 
>>
>> driver.find_element(xpath: "//*[noramlize-space()='something']").click
>>
>> It would perfectly work if this xpath matches only one, but there are 
>> more and rest of them are hidden it would choose to click the first one, 
>> not the one which is visible, but If you write the below code
>>
>> b.element(link: 'something').click
>>
>> It would write the selenium equivalent of 
>>
>> driver.find_element(link: 'something').click
>>
>>
>> it would perfectly choose the visible one by rejecting all the invisible 
>> one, 
>>
>>
>> You may say to me that I could achieve the same by passing 'visible: 
>> true' as the second parameter, but WATIR does here is, it iterates over all 
>> the links before it chooses the visible one. 
>>
>> So using link: over xpath: has many advantages, That's why I said we need 
>> to go for xpath when we can't use any other available locators. 
>>
>> On Tuesday, October 24, 2017 at 8:22:36 PM UTC+5:30, Titus Fortner wrote:
>>>
>>> If you want to use Watir without its powerful element location API, and 
>>> use only the element method and only Selenium locators, you are more than 
>>> welcome to do that.
>>> But stop telling other users that it's the right way to do it or that 
>>> it's better, because it isn't.
>>>
>>> Watir provides an easy way for the user to combine multiple location 
>>> strategies to uniquely identify an element without needing to use XPath.
>>> What Watir sends to the driver is irrelevant to the user.
>>>
>>> XPath for the user => Bad
>>> XPath for the driver => Good
>>>
>>> Separating what the user knows and what the driver knows is the whole 
>>> point, 

[wtr-general] Re: link and link_text not working in Watir 6?

[Titus Fortner]

We actually had a long discussion at the Ruby test code hackathon in 
Toronto last month about the proper behavior of the #text and #text_content 
methods and how they relate to the text locator (which handles String and 
RegExp values differently). I came into it arguing for changing the text 
locator to only find visible text, but after a lengthy considerations of 
backward compatibility and the fundamentally unique nature of text nodes as 
it relates to the DOM, especially considering the difficulties of dealing 
with nested text nodes with various possibilities for hidden . It was 
decided to keep the current text locator behavior for String values and to 
adjust the text locator behavior for RegExp values to match. This provides 
more flexibility and backward compatibility at the expense of being 
potentially confusing for things with multiple matches.

All of this being said, the correct response when using Watir is:

browser.a(text: 'something', visible: true).click`

There are several ways to accomplish this, but this is what fits our API. 
Feel free to use any other way you want,
but it isn't helpful to tell other users to do things that encourages them 
to work against rather than with our API.

I get that you've found what you consider is a clever way to use Watir and 
save a couple extra wire calls, and
that you don't care about the resulting lack of encapsulation. Good on you. 
This mailing list is not the right forum for you to push this idea, so 
please stop.

Thank you for your understanding.






On Wednesday, October 25, 2017 at 2:30:36 AM UTC-5, rajagopal...@gmail.com 
wrote:
>
> Please reject my last mail, I was wrong about b.link(link_text: 
> 'something').click
>
> Read this one, I have explained the advantage of link: over xpath:
> b.element(text: 'something').click
>
>
> It would create the selenium equivalent of 
>
> driver.find_element(xpath: "//*[noramlize-space()='something']").click
>
> It would perfectly work if this xpath matches only one, but there are more 
> and rest of them are hidden it would choose to click the first one, not the 
> one which is visible, but If you write the below code
>
> b.element(link: 'something').click
>
> It would write the selenium equivalent of 
>
> driver.find_element(link: 'something').click
>
>
> it would perfectly choose the visible one by rejecting all the invisible 
> one, 
>
>
> You may say to me that I could achieve the same by passing 'visible: true' 
> as the second parameter, but WATIR does here is, it iterates over all the 
> links before it chooses the visible one. 
>
> So using link: over xpath: has many advantages, That's why I said we need 
> to go for xpath when we can't use any other available locators. 
>
> On Tuesday, October 24, 2017 at 8:22:36 PM UTC+5:30, Titus Fortner wrote:
>>
>> If you want to use Watir without its powerful element location API, and 
>> use only the element method and only Selenium locators, you are more than 
>> welcome to do that.
>> But stop telling other users that it's the right way to do it or that 
>> it's better, because it isn't.
>>
>> Watir provides an easy way for the user to combine multiple location 
>> strategies to uniquely identify an element without needing to use XPath.
>> What Watir sends to the driver is irrelevant to the user.
>>
>> XPath for the user => Bad
>> XPath for the driver => Good
>>
>> Separating what the user knows and what the driver knows is the whole 
>> point, and your comments are only confusing the issue.
>>
>>
>>
>> On Tuesday, October 24, 2017 at 4:39:48 AM UTC-5, rajagopal...@gmail.com 
>> wrote:
>>>
>>> yes, that's what I am saying xpath usage must be the last one. If we 
>>> could use available selenium-webdriver locators then we need to prefer that 
>>> one. 
>>>
>>> On Monday, October 23, 2017 at 7:28:06 PM UTC+5:30, Titus Fortner wrote:

 The only reasons not to use xpath are that it is hard to read, and 
 difficult to write such that it is not brittle. Neither of these apply to 
 how Watir implements its location system.
>>>
>>>



-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

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

[wtr-general] Re: link and link_text not working in Watir 6?

[rajagopalanmadasami]

Please reject my last mail, I was wrong about b.link(link_text: 
'something').click

Read this one, I have explained the advantage of link: over xpath:
b.element(text: 'something').click


It would create the selenium equivalent of 

driver.find_element(xpath: "//*[noramlize-space()='something']").click

It would perfectly work if this xpath matches only one, but there are more 
and rest of them are hidden it would choose to click the first one, not the 
one which is visible, but If you write the below code

b.element(link: 'something').click

It would write the selenium equivalent of 

driver.find_element(link: 'something').click


it would perfectly choose the visible one by rejecting all the invisible 
one, 


You may say to me that I could achieve the same by passing 'visible: true' 
as the second parameter, but WATIR does here is, it iterates over all the 
links before it chooses the visible one. 

So using link: over xpath: has many advantages, That's why I said we need 
to go for xpath when we can't use any other available locators. 

On Tuesday, October 24, 2017 at 8:22:36 PM UTC+5:30, Titus Fortner wrote:
>
> If you want to use Watir without its powerful element location API, and 
> use only the element method and only Selenium locators, you are more than 
> welcome to do that.
> But stop telling other users that it's the right way to do it or that it's 
> better, because it isn't.
>
> Watir provides an easy way for the user to combine multiple location 
> strategies to uniquely identify an element without needing to use XPath.
> What Watir sends to the driver is irrelevant to the user.
>
> XPath for the user => Bad
> XPath for the driver => Good
>
> Separating what the user knows and what the driver knows is the whole 
> point, and your comments are only confusing the issue.
>
>
>
> On Tuesday, October 24, 2017 at 4:39:48 AM UTC-5, rajagopal...@gmail.com 
> wrote:
>>
>> yes, that's what I am saying xpath usage must be the last one. If we 
>> could use available selenium-webdriver locators then we need to prefer that 
>> one. 
>>
>> On Monday, October 23, 2017 at 7:28:06 PM UTC+5:30, Titus Fortner wrote:
>>>
>>> The only reasons not to use xpath are that it is hard to read, and 
>>> difficult to write such that it is not brittle. Neither of these apply to 
>>> how Watir implements its location system.
>>
>>
>>>
>>>

-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

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

[wtr-general] Re: link and link_text not working in Watir 6?

[rajagopalanmadasami]

All the selenium locators are WATIR's locators as well, I don't have to use 
element method if you don't like it, I could use link method as well with

b.link(link: 'something').click

it will still call selenium equivalent of 

driver.find_element(link: 'something').click

no difference, but when we choose to write xpath, there is higher chance 
that it would break if it's lengthily. And also, If you use 

b.link(text: 'something').click


It would create the selenium equivalent of 

driver.find_element(xpath: "//link[noramlize-space()='something']").click

It would perfectly work if this xpath matches only one, but there are more 
and rest of them are hidden it would choose to click the first one, not the 
one which is visible, but If you write the below code


b.element(link: 'something').click


Or 


b.link(link: 'something').click


It would write the selenium equivalent of 

driver.find_element(link: 'something').click


it would perfectly choose the visible one by rejecting all the invisible 
one, 


You may say to me that I could achieve the same by passing 'visible: true' 
as the second parameter, but WATIR does here is, it iterates over all the 
links before it chooses the visible one. 

So using link: over xpath: has many advantages, That's why I said we need 
to go for xpath when we can't use any other available locators. 



On Tuesday, October 24, 2017 at 8:22:36 PM UTC+5:30, Titus Fortner wrote:
>
> If you want to use Watir without its powerful element location API, and 
> use only the element method and only Selenium locators, you are more than 
> welcome to do that.
> But stop telling other users that it's the right way to do it or that it's 
> better, because it isn't.
>
> Watir provides an easy way for the user to combine multiple location 
> strategies to uniquely identify an element without needing to use XPath.
> What Watir sends to the driver is irrelevant to the user.
>
> XPath for the user => Bad
> XPath for the driver => Good
>
> Separating what the user knows and what the driver knows is the whole 
> point, and your comments are only confusing the issue.
>
>
>
> On Tuesday, October 24, 2017 at 4:39:48 AM UTC-5, rajagopal...@gmail.com 
> wrote:
>>
>> yes, that's what I am saying xpath usage must be the last one. If we 
>> could use available selenium-webdriver locators then we need to prefer that 
>> one. 
>>
>> On Monday, October 23, 2017 at 7:28:06 PM UTC+5:30, Titus Fortner wrote:
>>>
>>> The only reasons not to use xpath are that it is hard to read, and 
>>> difficult to write such that it is not brittle. Neither of these apply to 
>>> how Watir implements its location system.
>>
>>
>>>
>>>

-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

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

[wtr-general] Re: link and link_text not working in Watir 6?

[Chuck van der Linden]

two thumbs up on the below admonishment/advice.  

On Tuesday, October 24, 2017 at 7:52:36 AM UTC-7, Titus Fortner wrote:
>
> If you want to use Watir without its powerful element location API, and 
> use only the element method and only Selenium locators, you are more than 
> welcome to do that.
> But stop telling other users that it's the right way to do it or that it's 
> better, because it isn't.
>
> Watir provides an easy way for the user to combine multiple location 
> strategies to uniquely identify an element without needing to use XPath.
> What Watir sends to the driver is irrelevant to the user.
>
> XPath for the user => Bad
> XPath for the driver => Good
>
> Separating what the user knows and what the driver knows is the whole 
> point, and your comments are only confusing the issue.
>
>
>
> On Tuesday, October 24, 2017 at 4:39:48 AM UTC-5, rajagopal...@gmail.com 
> wrote:
>>
>> yes, that's what I am saying xpath usage must be the last one. If we 
>> could use available selenium-webdriver locators then we need to prefer that 
>> one. 
>>
>> On Monday, October 23, 2017 at 7:28:06 PM UTC+5:30, Titus Fortner wrote:
>>>
>>> The only reasons not to use xpath are that it is hard to read, and 
>>> difficult to write such that it is not brittle. Neither of these apply to 
>>> how Watir implements its location system.
>>
>>
>>>
>>>

-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

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

[wtr-general] Re: link and link_text not working in Watir 6?

[Titus Fortner]

If you want to use Watir without its powerful element location API, and use 
only the element method and only Selenium locators, you are more than 
welcome to do that.
But stop telling other users that it's the right way to do it or that it's 
better, because it isn't.

Watir provides an easy way for the user to combine multiple location 
strategies to uniquely identify an element without needing to use XPath.
What Watir sends to the driver is irrelevant to the user.

XPath for the user => Bad
XPath for the driver => Good

Separating what the user knows and what the driver knows is the whole 
point, and your comments are only confusing the issue.



On Tuesday, October 24, 2017 at 4:39:48 AM UTC-5, rajagopal...@gmail.com 
wrote:
>
> yes, that's what I am saying xpath usage must be the last one. If we could 
> use available selenium-webdriver locators then we need to prefer that one. 
>
> On Monday, October 23, 2017 at 7:28:06 PM UTC+5:30, Titus Fortner wrote:
>>
>> The only reasons not to use xpath are that it is hard to read, and 
>> difficult to write such that it is not brittle. Neither of these apply to 
>> how Watir implements its location system.
>
>
>>
>>

-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

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

[wtr-general] Re: link and link_text not working in Watir 6?

[rajagopalanmadasami]

yes, that's what I am saying xpath usage must be the last one. If we could 
use available selenium-webdriver locators then we need to prefer that one. 

On Monday, October 23, 2017 at 7:28:06 PM UTC+5:30, Titus Fortner wrote:
>
> The only reasons not to use xpath are that it is hard to read, and 
> difficult to write such that it is not brittle. Neither of these apply to 
> how Watir implements its location system.

-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

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

[wtr-general] Re: link and link_text not working in Watir 6?

[Titus Fortner]

The only reasons not to use xpath are that it is hard to read, and difficult to 
write such that it is not brittle. Neither of these apply to how Watir 
implements its location system.

-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

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

[wtr-general] Re: link and link_text not working in Watir 6?

[rajagopalanmadasami]

It's better to relay on element(link: "Services") instead of using 
link(text: "Services") because when we use link(text: "Services") WATIR 
goes on to form the xpath. xpath must be the last chance when we can't use 
any selenium locators. 

On Thursday, October 19, 2017 at 8:00:22 PM UTC+5:30, Justin Ko wrote:
>
> :link and :link_text are Selenium-WebDriver locators. Their support is 
> quite limited in Watir. They are only accepted when using the #element 
> method:
>
> browser.element(link_text: "Services").exists?
> #=> true
>
> browser.element(link: "Services").exists?
> #=> true
>
> Instead, I would suggest using :text:
>
> # using :text allows you to use the other element methods
> browser.link(text: "Services").exists?
> #=> true
>
> # exact text match
> browser.element(text: "Services").exists?
> #=> true
>
> # partial text match (which is not supported by :link_text and :link)
> browser.element(text: /Ser/).exists?
> #=> true
>
> - Justin
>
>
> On Thursday, October 19, 2017 at 10:16:21 AM UTC-4, inve...@gmail.com 
> wrote:
>>
>> I have some automation running and when I use link_text or link as the 
>> means to locate elements, I get:
>>
>> Watir::Exception::MissingWayOffFindingObjectException
>> invalid_attribute :link_text
>>
>> The same applies for :link.
>>
>> More broadly, let's say you have links that look like this:
>>
>> Services
>>
>> How would you generally go about finding that, assuming you didn't want 
>> to use XPath? Maybe I'm just trying the wrong locators.
>>
>>

-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

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

[wtr-general] Re: link and link_text not working in Watir 6?

[Justin Ko]

>
> If you try to use something like browser.link(text: "Services").click, it 
> says:
>
> "element located, but timed out after 30, seconds."
>

 The problem here is that there are actually 2 services links on the page. 
One is in the mobile nav menu (when the browser width is small) and one is 
in the full site menu (when the browser with is wide). `browser.link` grabs 
the first matching element, which in this case is the one in the nav menu. 
The element exists, but never becomes visible. Depending on what browser 
width you want to work with, you need to either:

   1. Expand the menu (for smaller browser widths):
   browser.div(id: 'mob-burger-trigger').click
   browser.link(text: 'Services').click
   
   2. Click the visible (or second) services link (for wider browser 
   widths):
   browser.link(text: 'Services', visible: true).click
   

If I do the more generic element: browser.element(link_text: 
> "Services").click, I get:
>
> "timeout after 30 seconds." (So it just couldn't find it at all.)
>
 
Interestingly, :link_text appears to take into account the text styling. If 
you view the source, the HTML text is just "Services". However, there is a 
style applying a text-transform which makes it look like "SERVICES" in the 
UI. The :link_text locator appears to consider the transform. As a result, 
you need to use the capitalized value:

browser.element(link_text: 'SERVICES').click

-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

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

[wtr-general] Re: link and link_text not working in Watir 6?

[inveilus]

On Thursday, October 19, 2017 at 9:30:22 AM UTC-5, Justin Ko wrote:
>
> :link and :link_text are Selenium-WebDriver locators. Their support is 
> quite limited in Watir. They are only accepted when using the #element 
> method:
>
> browser.element(link_text: "Services").exists?
> #=> true
>
> browser.element(link: "Services").exists?
> #=> true
>
>
>
Hmm. That makes sense but then it makes my findings even more interesting. 
I've found a site where the locators just don't seem to work no matter 
what, at least when using Watir. It's https://www.vokal.io/.

If you try to use something like browser.link(text: "Services").click, it 
says:

"element located, but timed out after 30, seconds."

If I do the more generic element: browser.element(link_text: 
"Services").click, I get:

"timeout after 30 seconds." (So it just couldn't find it at all.)

The content isn't in an iframe or anything like that. So I don't think this 
is an issue with the context. And, in the first exasmple I showed above, it 
did say "element located" but timed out. It's not clear why it couldn't 
click the element.

 

-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

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

[wtr-general] Re: link and link_text not working in Watir 6?

[Justin Ko]

:link and :link_text are Selenium-WebDriver locators. Their support is 
quite limited in Watir. They are only accepted when using the #element 
method:

browser.element(link_text: "Services").exists?
#=> true

browser.element(link: "Services").exists?
#=> true

Instead, I would suggest using :text:

# using :text allows you to use the other element methods
browser.link(text: "Services").exists?
#=> true

# exact text match
browser.element(text: "Services").exists?
#=> true

# partial text match (which is not supported by :link_text and :link)
browser.element(text: /Ser/).exists?
#=> true

- Justin


On Thursday, October 19, 2017 at 10:16:21 AM UTC-4, inve...@gmail.com wrote:
>
> I have some automation running and when I use link_text or link as the 
> means to locate elements, I get:
>
> Watir::Exception::MissingWayOffFindingObjectException
> invalid_attribute :link_text
>
> The same applies for :link.
>
> More broadly, let's say you have links that look like this:
>
> Services
>
> How would you generally go about finding that, assuming you didn't want to 
> use XPath? Maybe I'm just trying the wrong locators.
>
>

-- 
-- 
Before posting, please read http://watir.com/support. In short: search before 
you ask, be nice.

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