Re: [wtr-general] Re: visible_text is deprecated

2017-12-17 Thread rajagopalanmadasami 
I agree with you, but frame was intentionally designed that way and that's 
what frame is being used. Raising the defect and fixing is not in my hand 
according to this project. 

Actually I worked in WATIR for first five years in my company but that was 
watir-classic not selenium based watir. But after that my company was sold 
to other company and they are using selenium Java binding and I am working 
with selenium-Java binding now. The project which I am working now is IDIT, 
here If I don't find any id, I can raise the defect by asking to add the id 
to the field. But still I don't find any need to ask them to add id while I 
code because I can write the xpath or css which would not be brittle until 
and unless they have undergone some major change. I Love WATIR for only one 
reason, the reason is, the waiting timings WATIR is maintaining from local 
language binding not from the driver level.

On Thursday, December 14, 2017 at 11:27:26 PM UTC+5:30, Chuck van der 
Linden wrote:

>
> On Wednesday, December 13, 2017 at 10:23:58 AM UTC-8, 
> rajagopal...@gmail.com  wrote:
>>
>> It's not possible to locate element without xpath in some places, xpath 
>> is pretty important and also unlike watir-classic, new WATIR which uses 
>> selenium-webdriver does the exceptional job with xpath. I have written an 
>> xpath when I code yesterday for an insurance company
>>
>> @b.element(xpath: 
>> ".//*[@id='ApprovalManagerSearch']/following-sibling::div[1]").iframe(id: 
>> 'SearchPanel').element(:id, "adviser1").click
>>
>> You see, you can't locate this element without using xpath and ofcourse 
>> watir provides functions to form this xpath, but that's for beginners, not 
>> for the one who learnt very well. 
>>
>>
> Interesting example.  Why won't the following work?
>
> #(replace  with the method for the type of element you want to 
> click on, e.g. .span or .div, etc) 
> b.iframe(id: 'SearchPanel').(:id, "adviser1").click 
>
>
> If the site is coded to meet the HTML standard 
>  then ID values 
> are unique within what most of us call a 'page' (technically it's the 
> element's home subtree 
> )   So you 
> should be able to directly access the iframe by ID, instead of having to 
> worry about the outer container.  Of course iframes effectively have their 
> own unique home-subtree so you do of course have to specify the iframe, 
> then the thing you want that is inside a subframe  (Yes, I know YOU already 
> know about iframes. Consider that last sentence for the benefit of other 
> readers.)
>
> Now, if the site isn't coded with valid HTML and ID values are not unique, 
> then I can see the need for the outer container.Although I would take 
> issue with the statement that XML is the *only* way to select that as CSS 
> selectors also allow you to select adjacent siblings, as does the 
> .following_siblings watir method.  So claiming xpath is the only way is a 
> falsehood.
>
> (ah, see I was somewhat ninja'd by Titus)
>
> Now if the site was created by developers who don't care if they code to 
> standards, then I would still argue that watir code such as that below is 
> easier to follow, and update when needed than a giant xpath selector 
> (making up the html tag types as I don't have actual html to reference)  
>
> @b.div(id: 'ApprovalManagerSearch')
>   .following_siblings[1]
>   .iframe(id: 'SearchPanel')
>   .span(:id, "adviser1").click
>
>
> If this is a site you are testing, and it does not conform to the HTML 
> specification, I would file bugs against those spec violations.  There 
> really is no excuse for any developer to be producing a site with invalid 
> HTML and counting on the relative *tolerance and forgiveness of the 
> browser* to deal with their shitty HTML.  If they can't make the ID's 
> unique then I'd lobby to remove them and include some custom attribute 
> (data-*something* most likely) so you can select the one you want without 
> having to rely on an index as in my experience that's the most likely thing 
> to be brittle and break when the design of the site is altered.  That would 
> perhaps return the sites code to compliance with the spec and also increase 
> the testability of the site. 
>
> If it's a 3rd party site you have no control over, and presuming you are 
> not violating any terms of service regarding accessing the site via the use 
> of robots or automation, then sadly you just have to cope with the garbage 
> being produced by their developers.  Although frankly in that case I'd be 
> asking about an API as that is generally a superior way to interact with a 
> 3rd party platform.  
>

-- 
-- 
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

Re: [wtr-general] Re: visible_text is deprecated

2017-12-14 Thread Chuck van der Linden 

On Wednesday, December 13, 2017 at 10:23:58 AM UTC-8, 
rajagopalanmadas...@gmail.com wrote:
>
> It's not possible to locate element without xpath in some places, xpath is 
> pretty important and also unlike watir-classic, new WATIR which uses 
> selenium-webdriver does the exceptional job with xpath. I have written an 
> xpath when I code yesterday for an insurance company
>
> @b.element(xpath: 
> ".//*[@id='ApprovalManagerSearch']/following-sibling::div[1]").iframe(id: 
> 'SearchPanel').element(:id, "adviser1").click
>
> You see, you can't locate this element without using xpath and ofcourse watir 
> provides functions to form this xpath, but that's for beginners, not for the 
> one who learnt very well. 
>
>
Interesting example.  Why won't the following work?

#(replace  with the method for the type of element you want to 
click on, e.g. .span or .div, etc) 
b.iframe(id: 'SearchPanel').(:id, "adviser1").click 


If the site is coded to meet the HTML standard 
 then ID values are 
unique within what most of us call a 'page' (technically it's the element's 
home 
subtree )  
 So you should be able to directly access the iframe by ID, instead of 
having to worry about the outer container.  Of course iframes effectively 
have their own unique home-subtree so you do of course have to specify the 
iframe, then the thing you want that is inside a subframe  (Yes, I know YOU 
already know about iframes. Consider that last sentence for the benefit of 
other readers.)

Now, if the site isn't coded with valid HTML and ID values are not unique, 
then I can see the need for the outer container.Although I would take 
issue with the statement that XML is the *only* way to select that as CSS 
selectors also allow you to select adjacent siblings, as does the 
.following_siblings watir method.  So claiming xpath is the only way is a 
falsehood.

(ah, see I was somewhat ninja'd by Titus)

Now if the site was created by developers who don't care if they code to 
standards, then I would still argue that watir code such as that below is 
easier to follow, and update when needed than a giant xpath selector 
(making up the html tag types as I don't have actual html to reference)  

@b.div(id: 'ApprovalManagerSearch')
  .following_siblings[1]
  .iframe(id: 'SearchPanel')
  .span(:id, "adviser1").click


If this is a site you are testing, and it does not conform to the HTML 
specification, I would file bugs against those spec violations.  There 
really is no excuse for any developer to be producing a site with invalid 
HTML and counting on the relative *tolerance and forgiveness of the browser* to 
deal with their shitty HTML.  If they can't make the ID's unique then I'd 
lobby to remove them and include some custom attribute (data-*something* most 
likely) so you can select the one you want without having to rely on an 
index as in my experience that's the most likely thing to be brittle and 
break when the design of the site is altered.  That would perhaps return 
the sites code to compliance with the spec and also increase the 
testability of the site. 

If it's a 3rd party site you have no control over, and presuming you are 
not violating any terms of service regarding accessing the site via the use 
of robots or automation, then sadly you just have to cope with the garbage 
being produced by their developers.  Although frankly in that case I'd be 
asking about an API as that is generally a superior way to interact with a 
3rd party platform.  

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

Re: [wtr-general] Re: visible_text is deprecated

2017-12-14 Thread rajagopalanmadasami 

>
> You have more than one iframe with an id of 'SearchPanel' on the same 
> page? 


yes, Exactly, I have three frame with an id of 'SearchPanel'. 


And yes, you can build this with Watir API without using XPath  



here it is 

@b.element(id: 'ApprovalManagerSearch').following_siblings[1].iframe(id: 
'SearchPanel').element(:id, "adviser1").click


But that could be helpful for the beginner, because I don't want to give 
the extra work to WATIR when I am able to write the xpath.


On Thursday, December 14, 2017 at 12:55:03 AM UTC+5:30, Titus Fortner wrote:

> You have more than one iframe with an id of 'SearchPanel' on the same 
> page? 
>
> And yes, you can build this with Watir API without using XPath 
>
> On Wed, Dec 13, 2017 at 7:23 PM,   
> wrote: 
> > I am saying WATIR forms the xpath internally when you pass a locator 
> which 
> > is not of selenium, for an example, text: locator 
> > 
> > If you write a code 
> > 
> > b.span(text: 'something').click 
> > 
> > 
> > then WATIR would write the corresponding equivalent as below 
> > 
> > driver.find_element(xpath: "//span[normalize-space()='something']).clici 
> > 
> > 
> > 
> > It's not possible to locate element without xpath in some places, xpath 
> is 
> > pretty important and also unlike watir-classic, new WATIR which uses 
> > selenium-webdriver does the exceptional job with xpath. I have written 
> an 
> > xpath when I code yesterday for an insurance company 
> > 
> > @b.element(xpath: 
> > 
> ".//*[@id='ApprovalManagerSearch']/following-sibling::div[1]").iframe(id: 
> > 'SearchPanel').element(:id, "adviser1").click 
> > 
> > You see, you can't locate this element without using xpath and ofcourse 
> > watir provides functions to form this xpath, but that's for beginners, 
> not 
> > for the one who learnt very well. 
> > 
> > 
> > 
> > 
> > On Wednesday, December 13, 2017 at 10:53:18 PM UTC+5:30, Chuck van der 
> > Linden wrote: 
> >> 
> >> On Tuesday, December 12, 2017 at 9:56:46 AM UTC-8, rajagopalan madasami 
> >> wrote: 
> >>> 
> >>> I am using watir over selenium for two reasons, one reason is waiting 
> >>> timings are maintained by local language binding but selenium is 
> maintaining 
> >>> timing from driver level , since selenium uses the timing from driver 
> level 
> >>> it differs from Firefox to Chrome, but since WATIR is maintaining 
> timing 
> >>> from local language binding it doesn't matter whether I use Chrome or 
> >>> Firefox. Another reason is stale element problem, WATIR relocates the 
> >>> element when element  goes to stale other than that I don't use any 
> other 
> >>> features of WATIR because everything else is time consuming like xpah 
> >>> formation. So if you simply allow element () to access selenium 
> locators 
> >>> directly it would be useful for me rather than unnecessary deprecating 
> what 
> >>> word extraordinary. 
>  
>  
> >>  When you say xpath formation, are you referring to figuring out xpath 
> to 
> >> use for selecting elements, or something internal to the code? 
> >> 
> >> I'm a bit surprised if the first as I almost never use xpath, in fact I 
> >> avoid it, when selecting elements,  I'm nearly always using something 
> like 
> >> ID, or Name, or Data-something, or Class , or increasingly of late CSS 
> >> selectors (whatever allows me to uniquely locate the element(s) I 
> need). 
> >> For me the main objective is clear readable code which is as 
> non-brittle as 
> >> possible.   So for something like the makemytrip site I'd be selecting 
> >> things such as 
> >> 
> >> browser.text_field(id: "hp-widget__sTo") 
> >> 
> >> 
> >> 
> > 
> > -- 
> > -- 
> > 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-genera...@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-genera...@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.

Re: [wtr-general] Re: visible_text is deprecated

2017-12-13 Thread Titus Fortner 
You have more than one iframe with an id of 'SearchPanel' on the same page?

And yes, you can build this with Watir API without using XPath

On Wed, Dec 13, 2017 at 7:23 PM,   wrote:
> I am saying WATIR forms the xpath internally when you pass a locator which
> is not of selenium, for an example, text: locator
>
> If you write a code
>
> b.span(text: 'something').click
>
>
> then WATIR would write the corresponding equivalent as below
>
> driver.find_element(xpath: "//span[normalize-space()='something']).clici
>
>
>
> It's not possible to locate element without xpath in some places, xpath is
> pretty important and also unlike watir-classic, new WATIR which uses
> selenium-webdriver does the exceptional job with xpath. I have written an
> xpath when I code yesterday for an insurance company
>
> @b.element(xpath:
> ".//*[@id='ApprovalManagerSearch']/following-sibling::div[1]").iframe(id:
> 'SearchPanel').element(:id, "adviser1").click
>
> You see, you can't locate this element without using xpath and ofcourse
> watir provides functions to form this xpath, but that's for beginners, not
> for the one who learnt very well.
>
>
>
>
> On Wednesday, December 13, 2017 at 10:53:18 PM UTC+5:30, Chuck van der
> Linden wrote:
>>
>> On Tuesday, December 12, 2017 at 9:56:46 AM UTC-8, rajagopalan madasami
>> wrote:
>>>
>>> I am using watir over selenium for two reasons, one reason is waiting
>>> timings are maintained by local language binding but selenium is maintaining
>>> timing from driver level , since selenium uses the timing from driver level
>>> it differs from Firefox to Chrome, but since WATIR is maintaining timing
>>> from local language binding it doesn't matter whether I use Chrome or
>>> Firefox. Another reason is stale element problem, WATIR relocates the
>>> element when element  goes to stale other than that I don't use any other
>>> features of WATIR because everything else is time consuming like xpah
>>> formation. So if you simply allow element () to access selenium locators
>>> directly it would be useful for me rather than unnecessary deprecating what
>>> word extraordinary.


>>  When you say xpath formation, are you referring to figuring out xpath to
>> use for selecting elements, or something internal to the code?
>>
>> I'm a bit surprised if the first as I almost never use xpath, in fact I
>> avoid it, when selecting elements,  I'm nearly always using something like
>> ID, or Name, or Data-something, or Class , or increasingly of late CSS
>> selectors (whatever allows me to uniquely locate the element(s) I need).
>> For me the main objective is clear readable code which is as non-brittle as
>> possible.   So for something like the makemytrip site I'd be selecting
>> things such as
>>
>> browser.text_field(id: "hp-widget__sTo")
>>
>>
>>
>
> --
> --
> 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.

Re: [wtr-general] Re: visible_text is deprecated

2017-12-13 Thread rajagopalanmadasami 
I am saying WATIR forms the xpath internally when you pass a locator which 
is not of selenium, for an example, text: locator

If you write a code

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


then WATIR would write the corresponding equivalent as below

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



It's not possible to locate element without xpath in some places, xpath is 
pretty important and also unlike watir-classic, new WATIR which uses 
selenium-webdriver does the exceptional job with xpath. I have written an 
xpath when I code yesterday for an insurance company

@b.element(xpath: 
".//*[@id='ApprovalManagerSearch']/following-sibling::div[1]").iframe(id: 
'SearchPanel').element(:id, "adviser1").click

You see, you can't locate this element without using xpath and ofcourse watir 
provides functions to form this xpath, but that's for beginners, not for the 
one who learnt very well. 




On Wednesday, December 13, 2017 at 10:53:18 PM UTC+5:30, Chuck van der 
Linden wrote:
>
> On Tuesday, December 12, 2017 at 9:56:46 AM UTC-8, rajagopalan madasami 
> wrote:
>>
>> I am using watir over selenium for two reasons, one reason is waiting 
>> timings are maintained by local language binding but selenium is 
>> maintaining timing from driver level , since selenium uses the timing from 
>> driver level it differs from Firefox to Chrome, but since WATIR is 
>> maintaining timing from local language binding it doesn't matter whether I 
>> use Chrome or Firefox. Another reason is stale element problem, WATIR 
>> relocates the element when element  goes to stale other than that I don't 
>> use any other features of WATIR because everything else is time consuming 
>> like xpah formation. So if you simply allow element () to access selenium 
>> locators directly it would be useful for me rather than unnecessary 
>> deprecating what word extraordinary.
>>
>>>
>>>  When you say *xpath formation*, are you referring to figuring out 
> xpath to use for selecting elements, or something internal to the code?
>
> I'm a bit surprised if the first as I almost never use xpath, in fact I 
> avoid it, when selecting elements,  I'm nearly always using something like 
> ID, or Name, or Data-something, or Class , or increasingly of late CSS 
> selectors (whatever allows me to uniquely locate the element(s) I need).  
> For me the main objective is clear readable code which is as non-brittle as 
> possible.   So for something like the makemytrip site I'd be selecting 
> things such as 
>
> browser.text_field(id: "hp-widget__sTo")
>
>
>  
>

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

Re: [wtr-general] Re: visible_text is deprecated

2017-12-13 Thread rajagopalanmadasami 
Then How would I access your code? After accessing my code, should I use it 
in WATIR library to check how is the performance? By the way where is your 
new code? 

On Wednesday, December 13, 2017 at 8:22:53 PM UTC+5:30, Justin Ko wrote:
>
> Sorry, no, these changes are not available in 6.10.1.
>
> There are still changes I want to do for the simplify_locator branch. 
> However, if the current state solves your problem, I can see if I get 
> something merged in sooner.
>
> Justin
>
>
> On Wednesday, December 13, 2017 at 1:42:05 AM UTC-5, 
> rajagopal...@gmail.com wrote:
>>
>> This change available in recent water 6.10.1?
>>
>> On Tuesday, December 12, 2017 at 11:39:51 PM UTC+5:30, Justin Ko wrote:
>>>
>>> Rajagopalan, would you be able to see if the changes I have made in 
>>> https://github.com/jkotests/watir/tree/simplify_locator fixes the 
>>> performance problem for :visible_text?
>>>
>>> I think the problem is where we filter elements:
>>>
>>> def filter_elements_by_locator(elements, visible = nil, visible_text = 
>>> nil, idx = nil, tag_name: nil, filter: :first) 
>>>   elements.select! { |el| visible == el.displayed? } unless visible.nil? 
>>>   elements.select! { |el| visible_text === el.text } unless visible_text
>>> .nil? 
>>>   elements.select! { |el| element_validator.validate(el, {tag_name: 
>>> tag_name}) } unless tag_name.nil? 
>>>   filter == :first ? elements[idx || 0] : elements 
>>> end
>>>
>>>
>>> We apply the filter to every element found, even if you just want the 
>>> first one. The changes I have in progress switch this to be lazy - ie we 
>>> would only need to inspect the first link that matches. For a page with a 
>>> lot of links, I believe this would increase performance a lot.
>>>
>>> Justin
>>>
>>>
>>> On Tuesday, December 12, 2017 at 12:56:46 PM UTC-5, rajagopalan madasami 
>>> wrote:

 I am using watir over selenium for two reasons, one reason is waiting 
 timings are maintained by local language binding but selenium is 
 maintaining timing from driver level , since selenium uses the timing from 
 driver level it differs from Firefox to Chrome, but since WATIR is 
 maintaining timing from local language binding it doesn't matter whether I 
 use Chrome or Firefox. Another reason is stale element problem, WATIR 
 relocates the element when element  goes to stale other than that I don't 
 use any other features of WATIR because everything else is time consuming 
 like xpah formation. So if you simply allow element () to access selenium 
 locators directly it would be useful for me rather than unnecessary 
 deprecating what word extraordinary.

 On 12-Dec-2017 11:06 PM, "Titus Fortner"  wrote:

> Hey Chuck,
>
> Especially with Watir 6, there are some good synchronization reasons 
> to prefer Watir over default selenium, even if not taking advantage of 
> the 
> improved encapsulation of the subclasses or the more advanced locator 
> strategies. Though, not so many that it might not be worth it for him to 
> roll his own at that point. Depends on how much else in the Watir 
> ecosystem 
> he is relying on.
>
> Titus
>
>
>
>
> On Tuesday, December 12, 2017 at 11:20:28 AM UTC-6, Chuck van der 
> Linden wrote:
>>
>> bah... need to be able to edit... I confused using .link method of 
>> watir with the :link locator type of Selenium... please disregard the 
>> confusion over that sentence.
>>
>> Point being however that you seem wedded to directly using .element 
>> and selenium selection methods, so the question of why even use Watir as 
>> opposed to Selenium, given your preferences, still exists. 
>>
>> On Tuesday, December 12, 2017 at 9:17:10 AM UTC-8, Chuck van der 
>> Linden wrote:
>>>
>>>
>>>
>>> On Monday, December 11, 2017 at 10:29:52 PM UTC-8, 
>>> rajagopal...@gmail.com wrote:

 Can you please pay a little attention to the ongoing conversation? 
 The conversation is not about using element() or using link() 
 function, the 
 conversation is about performance issue while I use visible text. I am 
 ready to use visible text If it does the good performance but it's not 
 doing it, I am trying to click a link which takes minutes to click 
 that 
 link but when I use link locator it clicks instantly. 

>>>
>>>  You say that, yet every code example I see from you uses .element
>>>
>>> Then we have statements like this:
>>>
  Yes, I agree using b.link() increases the performance, But I 
 completely against the idea of not using the link: locator of selenium.
>>>
>>>
>>> (given the sentence makes no sense if parsed using the double 
>>> negative (in which case you would already be using .link, which you are 
>>> not),  I presume that

Re: [wtr-general] Re: visible_text is deprecated

2017-12-13 Thread Chuck van der Linden 
On Tuesday, December 12, 2017 at 9:56:46 AM UTC-8, rajagopalan madasami 
wrote:
>
> I am using watir over selenium for two reasons, one reason is waiting 
> timings are maintained by local language binding but selenium is 
> maintaining timing from driver level , since selenium uses the timing from 
> driver level it differs from Firefox to Chrome, but since WATIR is 
> maintaining timing from local language binding it doesn't matter whether I 
> use Chrome or Firefox. Another reason is stale element problem, WATIR 
> relocates the element when element  goes to stale other than that I don't 
> use any other features of WATIR because everything else is time consuming 
> like xpah formation. So if you simply allow element () to access selenium 
> locators directly it would be useful for me rather than unnecessary 
> deprecating what word extraordinary.
>
>>
>>  When you say *xpath formation*, are you referring to figuring out xpath 
to use for selecting elements, or something internal to the code?

I'm a bit surprised if the first as I almost never use xpath, in fact I 
avoid it, when selecting elements,  I'm nearly always using something like 
ID, or Name, or Data-something, or Class , or increasingly of late CSS 
selectors (whatever allows me to uniquely locate the element(s) I need).  
For me the main objective is clear readable code which is as non-brittle as 
possible.   So for something like the makemytrip site I'd be selecting 
things such as 

browser.text_field(id: "hp-widget__sTo")


 

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

Re: [wtr-general] Re: visible_text is deprecated

2017-12-13 Thread Justin Ko 
Sorry, no, these changes are not available in 6.10.1.

There are still changes I want to do for the simplify_locator branch. 
However, if the current state solves your problem, I can see if I get 
something merged in sooner.

Justin


On Wednesday, December 13, 2017 at 1:42:05 AM UTC-5, rajagopal...@gmail.com 
wrote:
>
> This change available in recent water 6.10.1?
>
> On Tuesday, December 12, 2017 at 11:39:51 PM UTC+5:30, Justin Ko wrote:
>>
>> Rajagopalan, would you be able to see if the changes I have made in 
>> https://github.com/jkotests/watir/tree/simplify_locator fixes the 
>> performance problem for :visible_text?
>>
>> I think the problem is where we filter elements:
>>
>> def filter_elements_by_locator(elements, visible = nil, visible_text = 
>> nil, idx = nil, tag_name: nil, filter: :first) 
>>   elements.select! { |el| visible == el.displayed? } unless visible.nil? 
>>   elements.select! { |el| visible_text === el.text } unless visible_text.
>> nil? 
>>   elements.select! { |el| element_validator.validate(el, {tag_name: 
>> tag_name}) } unless tag_name.nil? 
>>   filter == :first ? elements[idx || 0] : elements 
>> end
>>
>>
>> We apply the filter to every element found, even if you just want the 
>> first one. The changes I have in progress switch this to be lazy - ie we 
>> would only need to inspect the first link that matches. For a page with a 
>> lot of links, I believe this would increase performance a lot.
>>
>> Justin
>>
>>
>> On Tuesday, December 12, 2017 at 12:56:46 PM UTC-5, rajagopalan madasami 
>> wrote:
>>>
>>> I am using watir over selenium for two reasons, one reason is waiting 
>>> timings are maintained by local language binding but selenium is 
>>> maintaining timing from driver level , since selenium uses the timing from 
>>> driver level it differs from Firefox to Chrome, but since WATIR is 
>>> maintaining timing from local language binding it doesn't matter whether I 
>>> use Chrome or Firefox. Another reason is stale element problem, WATIR 
>>> relocates the element when element  goes to stale other than that I don't 
>>> use any other features of WATIR because everything else is time consuming 
>>> like xpah formation. So if you simply allow element () to access selenium 
>>> locators directly it would be useful for me rather than unnecessary 
>>> deprecating what word extraordinary.
>>>
>>> On 12-Dec-2017 11:06 PM, "Titus Fortner"  wrote:
>>>
 Hey Chuck,

 Especially with Watir 6, there are some good synchronization reasons to 
 prefer Watir over default selenium, even if not taking advantage of the 
 improved encapsulation of the subclasses or the more advanced locator 
 strategies. Though, not so many that it might not be worth it for him to 
 roll his own at that point. Depends on how much else in the Watir 
 ecosystem 
 he is relying on.

 Titus




 On Tuesday, December 12, 2017 at 11:20:28 AM UTC-6, Chuck van der 
 Linden wrote:
>
> bah... need to be able to edit... I confused using .link method of 
> watir with the :link locator type of Selenium... please disregard the 
> confusion over that sentence.
>
> Point being however that you seem wedded to directly using .element 
> and selenium selection methods, so the question of why even use Watir as 
> opposed to Selenium, given your preferences, still exists. 
>
> On Tuesday, December 12, 2017 at 9:17:10 AM UTC-8, Chuck van der 
> Linden wrote:
>>
>>
>>
>> On Monday, December 11, 2017 at 10:29:52 PM UTC-8, 
>> rajagopal...@gmail.com wrote:
>>>
>>> Can you please pay a little attention to the ongoing conversation? 
>>> The conversation is not about using element() or using link() function, 
>>> the 
>>> conversation is about performance issue while I use visible text. I am 
>>> ready to use visible text If it does the good performance but it's not 
>>> doing it, I am trying to click a link which takes minutes to click that 
>>> link but when I use link locator it clicks instantly. 
>>>
>>
>>  You say that, yet every code example I see from you uses .element
>>
>> Then we have statements like this:
>>
>>>  Yes, I agree using b.link() increases the performance, But I 
>>> completely against the idea of not using the link: locator of selenium.
>>
>>
>> (given the sentence makes no sense if parsed using the double 
>> negative (in which case you would already be using .link, which you are 
>> not),  I presume that 'not' in the above is a typo) 
>>
>> So despite people telling you to use .link, you seem insistent on 
>> using .element.  which is basically the same as using raw Webdriver 
>> instead 
>> of Watir.  So frankly I don't think my question is that out of line.  If 
>> you insist on using .element, and are as you stated 'completely against 
>> the

Re: [wtr-general] Re: visible_text is deprecated

2017-12-12 Thread rajagopalanmadasami 
This change available in recent water 6.10.1?

On Tuesday, December 12, 2017 at 11:39:51 PM UTC+5:30, Justin Ko wrote:
>
> Rajagopalan, would you be able to see if the changes I have made in 
> https://github.com/jkotests/watir/tree/simplify_locator fixes the 
> performance problem for :visible_text?
>
> I think the problem is where we filter elements:
>
> def filter_elements_by_locator(elements, visible = nil, visible_text = nil
> , idx = nil, tag_name: nil, filter: :first) 
>   elements.select! { |el| visible == el.displayed? } unless visible.nil? 
>   elements.select! { |el| visible_text === el.text } unless visible_text.
> nil? 
>   elements.select! { |el| element_validator.validate(el, {tag_name: 
> tag_name}) } unless tag_name.nil? 
>   filter == :first ? elements[idx || 0] : elements 
> end
>
>
> We apply the filter to every element found, even if you just want the 
> first one. The changes I have in progress switch this to be lazy - ie we 
> would only need to inspect the first link that matches. For a page with a 
> lot of links, I believe this would increase performance a lot.
>
> Justin
>
>
> On Tuesday, December 12, 2017 at 12:56:46 PM UTC-5, rajagopalan madasami 
> wrote:
>>
>> I am using watir over selenium for two reasons, one reason is waiting 
>> timings are maintained by local language binding but selenium is 
>> maintaining timing from driver level , since selenium uses the timing from 
>> driver level it differs from Firefox to Chrome, but since WATIR is 
>> maintaining timing from local language binding it doesn't matter whether I 
>> use Chrome or Firefox. Another reason is stale element problem, WATIR 
>> relocates the element when element  goes to stale other than that I don't 
>> use any other features of WATIR because everything else is time consuming 
>> like xpah formation. So if you simply allow element () to access selenium 
>> locators directly it would be useful for me rather than unnecessary 
>> deprecating what word extraordinary.
>>
>> On 12-Dec-2017 11:06 PM, "Titus Fortner"  wrote:
>>
>>> Hey Chuck,
>>>
>>> Especially with Watir 6, there are some good synchronization reasons to 
>>> prefer Watir over default selenium, even if not taking advantage of the 
>>> improved encapsulation of the subclasses or the more advanced locator 
>>> strategies. Though, not so many that it might not be worth it for him to 
>>> roll his own at that point. Depends on how much else in the Watir ecosystem 
>>> he is relying on.
>>>
>>> Titus
>>>
>>>
>>>
>>>
>>> On Tuesday, December 12, 2017 at 11:20:28 AM UTC-6, Chuck van der Linden 
>>> wrote:

 bah... need to be able to edit... I confused using .link method of 
 watir with the :link locator type of Selenium... please disregard the 
 confusion over that sentence.

 Point being however that you seem wedded to directly using .element and 
 selenium selection methods, so the question of why even use Watir as 
 opposed to Selenium, given your preferences, still exists. 

 On Tuesday, December 12, 2017 at 9:17:10 AM UTC-8, Chuck van der Linden 
 wrote:
>
>
>
> On Monday, December 11, 2017 at 10:29:52 PM UTC-8, 
> rajagopal...@gmail.com wrote:
>>
>> Can you please pay a little attention to the ongoing conversation? 
>> The conversation is not about using element() or using link() function, 
>> the 
>> conversation is about performance issue while I use visible text. I am 
>> ready to use visible text If it does the good performance but it's not 
>> doing it, I am trying to click a link which takes minutes to click that 
>> link but when I use link locator it clicks instantly. 
>>
>
>  You say that, yet every code example I see from you uses .element
>
> Then we have statements like this:
>
>>  Yes, I agree using b.link() increases the performance, But I 
>> completely against the idea of not using the link: locator of selenium.
>
>
> (given the sentence makes no sense if parsed using the double negative 
> (in which case you would already be using .link, which you are not),  I 
> presume that 'not' in the above is a typo) 
>
> So despite people telling you to use .link, you seem insistent on 
> using .element.  which is basically the same as using raw Webdriver 
> instead 
> of Watir.  So frankly I don't think my question is that out of line.  If 
> you insist on using .element, and are as you stated 'completely against 
> the 
> idea' of using the watir API, then why use Watir and not just use 
> webdriver 
> directly?
>
> In terms of performance: 
> As Titus asked earlier, can you provide a code example that 
> demonstrates the performance difference you are claiming to see?  not a 
> discussion of code, but actual code against an actual site. 
>
 -- 
>>> -- 
>>> Before posting, please read

Re: [wtr-general] Re: visible_text is deprecated

2017-12-12 Thread Titus Fortner 
Ugh, what a horrible design. Who wrote what we have now?  

:)

Thanks for working to make it more straightforward.


On Tuesday, December 12, 2017 at 12:09:51 PM UTC-6, Justin Ko wrote:
>
> Rajagopalan, would you be able to see if the changes I have made in 
> https://github.com/jkotests/watir/tree/simplify_locator fixes the 
> performance problem for :visible_text?
>
> I think the problem is where we filter elements:
>
> def filter_elements_by_locator(elements, visible = nil, visible_text = nil
> , idx = nil, tag_name: nil, filter: :first) 
>   elements.select! { |el| visible == el.displayed? } unless visible.nil? 
>   elements.select! { |el| visible_text === el.text } unless visible_text.
> nil? 
>   elements.select! { |el| element_validator.validate(el, {tag_name: 
> tag_name}) } unless tag_name.nil? 
>   filter == :first ? elements[idx || 0] : elements 
> end
>
>
> We apply the filter to every element found, even if you just want the 
> first one. The changes I have in progress switch this to be lazy - ie we 
> would only need to inspect the first link that matches. For a page with a 
> lot of links, I believe this would increase performance a lot.
>
> Justin
>
>
> On Tuesday, December 12, 2017 at 12:56:46 PM UTC-5, rajagopalan madasami 
> wrote:
>>
>> I am using watir over selenium for two reasons, one reason is waiting 
>> timings are maintained by local language binding but selenium is 
>> maintaining timing from driver level , since selenium uses the timing from 
>> driver level it differs from Firefox to Chrome, but since WATIR is 
>> maintaining timing from local language binding it doesn't matter whether I 
>> use Chrome or Firefox. Another reason is stale element problem, WATIR 
>> relocates the element when element  goes to stale other than that I don't 
>> use any other features of WATIR because everything else is time consuming 
>> like xpah formation. So if you simply allow element () to access selenium 
>> locators directly it would be useful for me rather than unnecessary 
>> deprecating what word extraordinary.
>>
>> On 12-Dec-2017 11:06 PM, "Titus Fortner"  wrote:
>>
>>> Hey Chuck,
>>>
>>> Especially with Watir 6, there are some good synchronization reasons to 
>>> prefer Watir over default selenium, even if not taking advantage of the 
>>> improved encapsulation of the subclasses or the more advanced locator 
>>> strategies. Though, not so many that it might not be worth it for him to 
>>> roll his own at that point. Depends on how much else in the Watir ecosystem 
>>> he is relying on.
>>>
>>> Titus
>>>
>>>
>>>
>>>
>>> On Tuesday, December 12, 2017 at 11:20:28 AM UTC-6, Chuck van der Linden 
>>> wrote:

 bah... need to be able to edit... I confused using .link method of 
 watir with the :link locator type of Selenium... please disregard the 
 confusion over that sentence.

 Point being however that you seem wedded to directly using .element and 
 selenium selection methods, so the question of why even use Watir as 
 opposed to Selenium, given your preferences, still exists. 

 On Tuesday, December 12, 2017 at 9:17:10 AM UTC-8, Chuck van der Linden 
 wrote:
>
>
>
> On Monday, December 11, 2017 at 10:29:52 PM UTC-8, 
> rajagopal...@gmail.com wrote:
>>
>> Can you please pay a little attention to the ongoing conversation? 
>> The conversation is not about using element() or using link() function, 
>> the 
>> conversation is about performance issue while I use visible text. I am 
>> ready to use visible text If it does the good performance but it's not 
>> doing it, I am trying to click a link which takes minutes to click that 
>> link but when I use link locator it clicks instantly. 
>>
>
>  You say that, yet every code example I see from you uses .element
>
> Then we have statements like this:
>
>>  Yes, I agree using b.link() increases the performance, But I 
>> completely against the idea of not using the link: locator of selenium.
>
>
> (given the sentence makes no sense if parsed using the double negative 
> (in which case you would already be using .link, which you are not),  I 
> presume that 'not' in the above is a typo) 
>
> So despite people telling you to use .link, you seem insistent on 
> using .element.  which is basically the same as using raw Webdriver 
> instead 
> of Watir.  So frankly I don't think my question is that out of line.  If 
> you insist on using .element, and are as you stated 'completely against 
> the 
> idea' of using the watir API, then why use Watir and not just use 
> webdriver 
> directly?
>
> In terms of performance: 
> As Titus asked earlier, can you provide a code example that 
> demonstrates the performance difference you are claiming to see?  not a 
> discussion of code, but actual code against an actual site. 
>

Re: [wtr-general] Re: visible_text is deprecated

2017-12-12 Thread Justin Ko 
Rajagopalan, would you be able to see if the changes I have made in 
https://github.com/jkotests/watir/tree/simplify_locator fixes the 
performance problem for :visible_text?

I think the problem is where we filter elements:

def filter_elements_by_locator(elements, visible = nil, visible_text = nil, 
idx = nil, tag_name: nil, filter: :first) 
  elements.select! { |el| visible == el.displayed? } unless visible.nil? 
  elements.select! { |el| visible_text === el.text } unless visible_text.nil
? 
  elements.select! { |el| element_validator.validate(el, {tag_name: tag_name
}) } unless tag_name.nil? 
  filter == :first ? elements[idx || 0] : elements 
end


We apply the filter to every element found, even if you just want the first 
one. The changes I have in progress switch this to be lazy - ie we would 
only need to inspect the first link that matches. For a page with a lot of 
links, I believe this would increase performance a lot.

Justin


On Tuesday, December 12, 2017 at 12:56:46 PM UTC-5, rajagopalan madasami 
wrote:
>
> I am using watir over selenium for two reasons, one reason is waiting 
> timings are maintained by local language binding but selenium is 
> maintaining timing from driver level , since selenium uses the timing from 
> driver level it differs from Firefox to Chrome, but since WATIR is 
> maintaining timing from local language binding it doesn't matter whether I 
> use Chrome or Firefox. Another reason is stale element problem, WATIR 
> relocates the element when element  goes to stale other than that I don't 
> use any other features of WATIR because everything else is time consuming 
> like xpah formation. So if you simply allow element () to access selenium 
> locators directly it would be useful for me rather than unnecessary 
> deprecating what word extraordinary.
>
> On 12-Dec-2017 11:06 PM, "Titus Fortner"  > wrote:
>
>> Hey Chuck,
>>
>> Especially with Watir 6, there are some good synchronization reasons to 
>> prefer Watir over default selenium, even if not taking advantage of the 
>> improved encapsulation of the subclasses or the more advanced locator 
>> strategies. Though, not so many that it might not be worth it for him to 
>> roll his own at that point. Depends on how much else in the Watir ecosystem 
>> he is relying on.
>>
>> Titus
>>
>>
>>
>>
>> On Tuesday, December 12, 2017 at 11:20:28 AM UTC-6, Chuck van der Linden 
>> wrote:
>>>
>>> bah... need to be able to edit... I confused using .link method of watir 
>>> with the :link locator type of Selenium... please disregard the confusion 
>>> over that sentence.
>>>
>>> Point being however that you seem wedded to directly using .element and 
>>> selenium selection methods, so the question of why even use Watir as 
>>> opposed to Selenium, given your preferences, still exists. 
>>>
>>> On Tuesday, December 12, 2017 at 9:17:10 AM UTC-8, Chuck van der Linden 
>>> wrote:



 On Monday, December 11, 2017 at 10:29:52 PM UTC-8, 
 rajagopal...@gmail.com wrote:
>
> Can you please pay a little attention to the ongoing conversation? The 
> conversation is not about using element() or using link() function, the 
> conversation is about performance issue while I use visible text. I am 
> ready to use visible text If it does the good performance but it's not 
> doing it, I am trying to click a link which takes minutes to click that 
> link but when I use link locator it clicks instantly. 
>

  You say that, yet every code example I see from you uses .element

 Then we have statements like this:

>  Yes, I agree using b.link() increases the performance, But I 
> completely against the idea of not using the link: locator of selenium.


 (given the sentence makes no sense if parsed using the double negative 
 (in which case you would already be using .link, which you are not),  I 
 presume that 'not' in the above is a typo) 

 So despite people telling you to use .link, you seem insistent on using 
 .element.  which is basically the same as using raw Webdriver instead of 
 Watir.  So frankly I don't think my question is that out of line.  If you 
 insist on using .element, and are as you stated 'completely against the 
 idea' of using the watir API, then why use Watir and not just use 
 webdriver 
 directly?

 In terms of performance: 
 As Titus asked earlier, can you provide a code example that 
 demonstrates the performance difference you are claiming to see?  not a 
 discussion of code, but actual code against an actual site. 

>>> -- 
>> -- 
>> 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-genera...@googlegroups.com 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Watir

Re: [wtr-general] Re: visible_text is deprecated

2017-12-12 Thread rajagopalan madasami 
I am using watir over selenium for two reasons, one reason is waiting
timings are maintained by local language binding but selenium is
maintaining timing from driver level , since selenium uses the timing from
driver level it differs from Firefox to Chrome, but since WATIR is
maintaining timing from local language binding it doesn't matter whether I
use Chrome or Firefox. Another reason is stale element problem, WATIR
relocates the element when element  goes to stale other than that I don't
use any other features of WATIR because everything else is time consuming
like xpah formation. So if you simply allow element () to access selenium
locators directly it would be useful for me rather than unnecessary
deprecating what word extraordinary.

On 12-Dec-2017 11:06 PM, "Titus Fortner"  wrote:

> Hey Chuck,
>
> Especially with Watir 6, there are some good synchronization reasons to
> prefer Watir over default selenium, even if not taking advantage of the
> improved encapsulation of the subclasses or the more advanced locator
> strategies. Though, not so many that it might not be worth it for him to
> roll his own at that point. Depends on how much else in the Watir ecosystem
> he is relying on.
>
> Titus
>
>
>
>
> On Tuesday, December 12, 2017 at 11:20:28 AM UTC-6, Chuck van der Linden
> wrote:
>>
>> bah... need to be able to edit... I confused using .link method of watir
>> with the :link locator type of Selenium... please disregard the confusion
>> over that sentence.
>>
>> Point being however that you seem wedded to directly using .element and
>> selenium selection methods, so the question of why even use Watir as
>> opposed to Selenium, given your preferences, still exists.
>>
>> On Tuesday, December 12, 2017 at 9:17:10 AM UTC-8, Chuck van der Linden
>> wrote:
>>>
>>>
>>>
>>> On Monday, December 11, 2017 at 10:29:52 PM UTC-8,
>>> rajagopal...@gmail.com wrote:

 Can you please pay a little attention to the ongoing conversation? The
 conversation is not about using element() or using link() function, the
 conversation is about performance issue while I use visible text. I am
 ready to use visible text If it does the good performance but it's not
 doing it, I am trying to click a link which takes minutes to click that
 link but when I use link locator it clicks instantly.

>>>
>>>  You say that, yet every code example I see from you uses .element
>>>
>>> Then we have statements like this:
>>>
  Yes, I agree using b.link() increases the performance, But I
 completely against the idea of not using the link: locator of selenium.
>>>
>>>
>>> (given the sentence makes no sense if parsed using the double negative
>>> (in which case you would already be using .link, which you are not),  I
>>> presume that 'not' in the above is a typo)
>>>
>>> So despite people telling you to use .link, you seem insistent on using
>>> .element.  which is basically the same as using raw Webdriver instead of
>>> Watir.  So frankly I don't think my question is that out of line.  If you
>>> insist on using .element, and are as you stated 'completely against the
>>> idea' of using the watir API, then why use Watir and not just use webdriver
>>> directly?
>>>
>>> In terms of performance:
>>> As Titus asked earlier, can you provide a code example that demonstrates
>>> the performance difference you are claiming to see?  not a discussion of
>>> code, but actual code against an actual site.
>>>
>> --
> --
> 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: visible_text is deprecated

2017-12-12 Thread Titus Fortner 
Hey Chuck,

Especially with Watir 6, there are some good synchronization reasons to 
prefer Watir over default selenium, even if not taking advantage of the 
improved encapsulation of the subclasses or the more advanced locator 
strategies. Though, not so many that it might not be worth it for him to 
roll his own at that point. Depends on how much else in the Watir ecosystem 
he is relying on.

Titus




On Tuesday, December 12, 2017 at 11:20:28 AM UTC-6, Chuck van der Linden 
wrote:
>
> bah... need to be able to edit... I confused using .link method of watir 
> with the :link locator type of Selenium... please disregard the confusion 
> over that sentence.
>
> Point being however that you seem wedded to directly using .element and 
> selenium selection methods, so the question of why even use Watir as 
> opposed to Selenium, given your preferences, still exists. 
>
> On Tuesday, December 12, 2017 at 9:17:10 AM UTC-8, Chuck van der Linden 
> wrote:
>>
>>
>>
>> On Monday, December 11, 2017 at 10:29:52 PM UTC-8, rajagopal...@gmail.com 
>>  wrote:
>>>
>>> Can you please pay a little attention to the ongoing conversation? The 
>>> conversation is not about using element() or using link() function, the 
>>> conversation is about performance issue while I use visible text. I am 
>>> ready to use visible text If it does the good performance but it's not 
>>> doing it, I am trying to click a link which takes minutes to click that 
>>> link but when I use link locator it clicks instantly. 
>>>
>>
>>  You say that, yet every code example I see from you uses .element
>>
>> Then we have statements like this:
>>
>>>  Yes, I agree using b.link() increases the performance, But I completely 
>>> against the idea of not using the link: locator of selenium.
>>
>>
>> (given the sentence makes no sense if parsed using the double negative 
>> (in which case you would already be using .link, which you are not),  I 
>> presume that 'not' in the above is a typo) 
>>
>> So despite people telling you to use .link, you seem insistent on using 
>> .element.  which is basically the same as using raw Webdriver instead of 
>> Watir.  So frankly I don't think my question is that out of line.  If you 
>> insist on using .element, and are as you stated 'completely against the 
>> idea' of using the watir API, then why use Watir and not just use webdriver 
>> directly?
>>
>> In terms of performance: 
>> As Titus asked earlier, can you provide a code example that demonstrates 
>> the performance difference you are claiming to see?  not a discussion of 
>> code, but actual code against an actual site. 
>>
>

-- 
-- 
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: visible_text is deprecated

2017-12-12 Thread Chuck van der Linden 
bah... need to be able to edit... I confused using .link method of watir 
with the :link locator type of Selenium... please disregard the confusion 
over that sentence.

Point being however that you seem wedded to directly using .element and 
selenium selection methods, so the question of why even use Watir as 
opposed to Selenium, given your preferences, still exists. 

On Tuesday, December 12, 2017 at 9:17:10 AM UTC-8, Chuck van der Linden 
wrote:
>
>
>
> On Monday, December 11, 2017 at 10:29:52 PM UTC-8, 
> rajagopalanmadas...@gmail.com wrote:
>>
>> Can you please pay a little attention to the ongoing conversation? The 
>> conversation is not about using element() or using link() function, the 
>> conversation is about performance issue while I use visible text. I am 
>> ready to use visible text If it does the good performance but it's not 
>> doing it, I am trying to click a link which takes minutes to click that 
>> link but when I use link locator it clicks instantly. 
>>
>
>  You say that, yet every code example I see from you uses .element
>
> Then we have statements like this:
>
>>  Yes, I agree using b.link() increases the performance, But I completely 
>> against the idea of not using the link: locator of selenium.
>
>
> (given the sentence makes no sense if parsed using the double negative (in 
> which case you would already be using .link, which you are not),  I presume 
> that 'not' in the above is a typo) 
>
> So despite people telling you to use .link, you seem insistent on using 
> .element.  which is basically the same as using raw Webdriver instead of 
> Watir.  So frankly I don't think my question is that out of line.  If you 
> insist on using .element, and are as you stated 'completely against the 
> idea' of using the watir API, then why use Watir and not just use webdriver 
> directly?
>
> In terms of performance: 
> As Titus asked earlier, can you provide a code example that demonstrates 
> the performance difference you are claiming to see?  not a discussion of 
> code, but actual code against an actual site. 
>

-- 
-- 
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: visible_text is deprecated

2017-12-12 Thread Chuck van der Linden 


On Monday, December 11, 2017 at 10:29:52 PM UTC-8, 
rajagopalanmadas...@gmail.com wrote:
>
> Can you please pay a little attention to the ongoing conversation? The 
> conversation is not about using element() or using link() function, the 
> conversation is about performance issue while I use visible text. I am 
> ready to use visible text If it does the good performance but it's not 
> doing it, I am trying to click a link which takes minutes to click that 
> link but when I use link locator it clicks instantly. 
>

 You say that, yet every code example I see from you uses .element

Then we have statements like this:

>  Yes, I agree using b.link() increases the performance, But I completely 
> against the idea of not using the link: locator of selenium.


(given the sentence makes no sense if parsed using the double negative (in 
which case you would already be using .link, which you are not),  I presume 
that 'not' in the above is a typo) 

So despite people telling you to use .link, you seem insistent on using 
.element.  which is basically the same as using raw Webdriver instead of 
Watir.  So frankly I don't think my question is that out of line.  If you 
insist on using .element, and are as you stated 'completely against the 
idea' of using the watir API, then why use Watir and not just use webdriver 
directly?

In terms of performance: 
As Titus asked earlier, can you provide a code example that demonstrates 
the performance difference you are claiming to see?  not a discussion of 
code, but actual code against an actual site. 

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

Re: [wtr-general] Re: visible_text is deprecated

2017-12-12 Thread Titus Fortner 
I'm confused. If the links are all the same text, are all visible, and
you only need the first one, why are you doing it this way?

Do you have example html to point to?


On Tue, Dec 12, 2017 at 7:31 AM,   wrote:
> It's a railway ticket booking. There are many book now links are there and
> all of them are visible, but it has to choose the first one but it takes too
> long time to click that link but while I use lick locator it does click
> instantly.
>
> On Monday, December 11, 2017 at 7:59:05 PM UTC+5:30, Titus Fortner wrote:
>>
>> Do you have example code for it taking that long? How many links are on
>> the page? Are you ruining locally or remotely?
>
> --
> --
> 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.

Re: [wtr-general] Re: visible_text is deprecated

2017-12-11 Thread rajagopalanmadasami 
It's a railway ticket booking. There are many book now links are there and 
all of them are visible, but it has to choose the first one but it takes 
too long time to click that link but while I use lick locator it does click 
instantly. 

On Monday, December 11, 2017 at 7:59:05 PM UTC+5:30, Titus Fortner wrote:
>
> Do you have example code for it taking that long? How many links are on 
> the page? Are you ruining locally or remotely?

-- 
-- 
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: visible_text is deprecated

2017-12-11 Thread rajagopalanmadasami 
Can you please pay a little attention to the ongoing conversation? The 
conversation is not about using element() or using link() function, the 
conversation is about performance issue while I use visible text. I am 
ready to use visible text If it does the good performance but it's not 
doing it, I am trying to click a link which takes minutes to click that 
link but when I use link locator it clicks instantly. 

On Tuesday, December 12, 2017 at 1:08:18 AM UTC+5:30, Chuck van der Linden 
wrote:
>
> On Sunday, December 10, 2017 at 9:03:18 AM UTC-8, rajagopalan madasami 
> wrote:
>>
>> It is known that using :visible_text will not have the same performance. 
>> It has to iterate over elements, where as the Selenium ones would not. 
>> The benefit of :visible_text is that we can apply it across all element 
>> types, not just links.
>>
>> Yes, it is increasing the performance ! But still it's taking much time 
>> but compared to element() function it's okay. But *link*: locator really 
>> rocks! I still don't have any clue why WATIR is going to forbid using such 
>> a powerful performance of Selenium, I don't see any reason other than 
>> putting just name sake of WATIR API. 
>>
>> I have a number of ideas for improving locator performance in general. 
>> However, for this specific case, you will see performance improvements by 
>> not using #element. Just switching to using #link will cut down the 
>> number of elements Watir has to iterate over. If there are other locators 
>> to reduce the links checked, that will also help performance. If that 
>> doesn't help, a specific example would help us identify other places for 
>> performance improvements.
>>
>> Yes, I agree using b.link() increases the performance, But I completely 
>> against the idea of not using the link: locator of selenium.
>>
>> If I pass the locator which is inside the selenium locators list, then 
>> make a direct call to find_element just by passing those two values, but 
>> when you find the locator which is not in selenium locators list, then go 
>> for formation of xpath. It's pretty simple. It was good but I don't know 
>> why all these unnecessary arrangement which actually spoils the WATIR 
>> structure rather than improving. The very first time yesterday when I 
>> developed  WATIR code for new project, I installed previous version(6.8.4) 
>> because of this new arrangement. 
>>
>>
> If you want to just use `.element` method instead of specific element type 
> methods such as `.link` , and use selenium locators instead of those that 
> Watir provides, then why use Watir?  Why not just use raw Webdriver 
> instead, since you see to like its API more than the Watir API?   The only 
> time I use .element with Watir is as a last resort when nothing else will 
> work.  Otherwise I use the selection methods that parallel the DOM element 
> type I am selecting, be it a .div or a .link or a .checkbox
>

-- 
-- 
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: visible_text is deprecated

2017-12-11 Thread Chuck van der Linden 
On Sunday, December 10, 2017 at 9:03:18 AM UTC-8, rajagopalan madasami 
wrote:
>
> It is known that using :visible_text will not have the same performance. 
> It has to iterate over elements, where as the Selenium ones would not. The 
> benefit of :visible_text is that we can apply it across all element types, 
> not just links.
>
> Yes, it is increasing the performance ! But still it's taking much time 
> but compared to element() function it's okay. But *link*: locator really 
> rocks! I still don't have any clue why WATIR is going to forbid using such 
> a powerful performance of Selenium, I don't see any reason other than 
> putting just name sake of WATIR API. 
>
> I have a number of ideas for improving locator performance in general. 
> However, for this specific case, you will see performance improvements by 
> not using #element. Just switching to using #link will cut down the 
> number of elements Watir has to iterate over. If there are other locators 
> to reduce the links checked, that will also help performance. If that 
> doesn't help, a specific example would help us identify other places for 
> performance improvements.
>
> Yes, I agree using b.link() increases the performance, But I completely 
> against the idea of not using the link: locator of selenium.
>
> If I pass the locator which is inside the selenium locators list, then 
> make a direct call to find_element just by passing those two values, but 
> when you find the locator which is not in selenium locators list, then go 
> for formation of xpath. It's pretty simple. It was good but I don't know 
> why all these unnecessary arrangement which actually spoils the WATIR 
> structure rather than improving. The very first time yesterday when I 
> developed  WATIR code for new project, I installed previous version(6.8.4) 
> because of this new arrangement. 
>
>
If you want to just use `.element` method instead of specific element type 
methods such as `.link` , and use selenium locators instead of those that 
Watir provides, then why use Watir?  Why not just use raw Webdriver 
instead, since you see to like its API more than the Watir API?   The only 
time I use .element with Watir is as a last resort when nothing else will 
work.  Otherwise I use the selection methods that parallel the DOM element 
type I am selecting, be it a .div or a .link or a .checkbox

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

Re: [wtr-general] Re: visible_text is deprecated

2017-12-11 Thread Titus Fortner 
Do you have example code for it taking that long? How many links are on the 
page? Are you ruining locally or remotely?

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

Re: [wtr-general] Re: visible_text is deprecated

2017-12-11 Thread rajagopalan madasami 
I understand your point, but it creates drastic performance difference, it
clicks the link after 2 to 3 minutes. Direct selenium link locator clicks
the link instantly. After wrapped in link() method, it clicks in 30
seconds(approximately). But my question, what other other element visible
text matter? buttons? Or what else? Link is the only thing which usually
uses text to locate the element, that's the common notion, for button we
always preferred to use value locator.

On Mon, Dec 11, 2017 at 7:13 PM, Titus Fortner 
wrote:

> We've already had this conversation on github. The consistency of the API
> is much more important than this minor performance difference. Now all
> locators will be treated exactly the same. It should be possible to
> implement visible_text with the selenium locator, but a cursory look it was
> harder than I wanted to invest time into. You are welcome to PR a fix.
>
> --
> --
> 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: visible_text is deprecated

2017-12-11 Thread Titus Fortner 
We've already had this conversation on github. The consistency of the API is 
much more important than this minor performance difference. Now all locators 
will be treated exactly the same. It should be possible to implement 
visible_text with the selenium locator, but a cursory look it was harder than I 
wanted to invest time into. You are welcome to PR a fix.

-- 
-- 
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: visible_text is deprecated

2017-12-10 Thread rajagopalanmadasami 

>
> It is known that using :visible_text will not have the same performance. 
It has to iterate over elements, where as the Selenium ones would not. The 
benefit of :visible_text is that we can apply it across all element types, 
not just links.

Yes, it is increasing the performance ! But still it's taking much time but 
compared to element() function it's okay. But *link*: locator really rocks! 
I still don't have any clue why WATIR is going to forbid using such a 
powerful performance of Selenium, I don't see any reason other than putting 
just name sake of WATIR API. 

I have a number of ideas for improving locator performance in general. 
However, for this specific case, you will see performance improvements by 
not using #element. Just switching to using #link will cut down the number 
of elements Watir has to iterate over. If there are other locators to 
reduce the links checked, that will also help performance. If that doesn't 
help, a specific example would help us identify other places for 
performance improvements.

Yes, I agree using b.link() increases the performance, But I completely 
against the idea of not using the link: locator of selenium.

If I pass the locator which is inside the selenium locators list, then make 
a direct call to find_element just by passing those two values, but when 
you find the locator which is not in selenium locators list, then go for 
formation of xpath. It's pretty simple. It was good but I don't know why 
all these unnecessary arrangement which actually spoils the WATIR structure 
rather than improving. The very first time yesterday when I developed  
WATIR code for new project, I installed previous version(6.8.4) because of 
this new arrangement. 


On Sunday, December 10, 2017 at 7:54:42 PM UTC+5:30, Justin Ko wrote:

> Yes, the plan is to remove :link, :link_text and :partial_link_text.
>
> It is known that using :visible_text will not have the same performance. 
> It has to iterate over elements, where as the Selenium ones would not. The 
> benefit of :visible_text is that we can apply it across all element types, 
> not just links.
>
> I have a number of ideas for improving locator performance in general. 
> However, for this specific case, you will see performance improvements by 
> not using #element. Just switching to using #link will cut down the number 
> of elements Watir has to iterate over. If there are other locators to 
> reduce the links checked, that will also help performance. If that doesn't 
> help, a specific example would help us identify other places for 
> performance improvements.
>
> Justin
>
>
> On Sunday, December 10, 2017 at 2:24:19 AM UTC-5, rajagopal...@gmail.com 
> wrote:
>>
>> When I use
>>
>> b.element(link: 'Book Now').click
>>
>> it says 
>>
>> 2017-12-10 12:49:01 WARN Watir [DEPRECATION] :link locator is deprecated. 
>> Use :visible_text instead.
>>
>> Does that mean it would be removed in future? 
>>
>> because what I found is, visible_text locator is not working properly, it 
>> clicks the link after 3 to 5 mins of time, How funny, Isn't it? 
>>
>

-- 
-- 
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: visible_text is deprecated

2017-12-10 Thread Justin Ko 
Yes, the plan is to remove :link, :link_text and :partial_link_text.

It is known that using :visible_text will not have the same performance. It 
has to iterate over elements, where as the Selenium ones would not. The 
benefit of :visible_text is that we can apply it across all element types, 
not just links.

I have a number of ideas for improving locator performance in general. 
However, for this specific case, you will see performance improvements by 
not using #element. Just switching to using #link will cut down the number 
of elements Watir has to iterate over. If there are other locators to 
reduce the links checked, that will also help performance. If that doesn't 
help, a specific example would help us identify other places for 
performance improvements.

Justin


On Sunday, December 10, 2017 at 2:24:19 AM UTC-5, rajagopal...@gmail.com 
wrote:
>
> When I use
>
> b.element(link: 'Book Now').click
>
> it says 
>
> 2017-12-10 12:49:01 WARN Watir [DEPRECATION] :link locator is deprecated. 
> Use :visible_text instead.
>
> Does that mean it would be removed in future? 
>
> because what I found is, visible_text locator is not working properly, it 
> clicks the link after 3 to 5 mins of time, How funny, Isn't it? 
>

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