From bret at pettichord.com  Fri Dec  2 01:05:37 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Fri, 02 Dec 2005 00:05:37 -0600
Subject: [Wtr-core] OpenQA.org
Message-ID: <5.1.0.14.2.20051202000327.033d54f0@pop.gmail.com>

Hi friends,

I've been very busy lately and am behind in my email. But i wanted to let 
you all know that we've been invited to host Watir at www.OpenQA.org. 
Please take a look at it and let me know what you think. I think it would 
be much better for us to use Subversion and Jira than CVS and the "trackers".

Bret

_____________________
  Bret Pettichord
  www.pettichord.com


From raghu at qantom.com  Fri Dec  2 01:21:17 2005
From: raghu at qantom.com (Raghu Venkataramana)
Date: Fri, 02 Dec 2005 11:51:17 +0530
Subject: [Wtr-core] OpenQA.org
In-Reply-To: <5.1.0.14.2.20051202000327.033d54f0@pop.gmail.com>
References: <5.1.0.14.2.20051202000327.033d54f0@pop.gmail.com>
Message-ID: <438FE7DD.5040206@qantom.com>

+ + + +

SVN is definitely a much much better than CVS. (WET in fact gets 
developed internally
on SVN and then gets pushed to sourceforge - one of the reasons I chose 
sourceforge
was due to the fact that sourceforge promised to have a svn repository soon)

Jira again is a lovely issue tracker.

Thanks
Raghu


Bret Pettichord wrote:

>Hi friends,
>
>I've been very busy lately and am behind in my email. But i wanted to let 
>you all know that we've been invited to host Watir at www.OpenQA.org. 
>Please take a look at it and let me know what you think. I think it would 
>be much better for us to use Subversion and Jira than CVS and the "trackers".
>
>Bret
>
>_____________________
>  Bret Pettichord
>  www.pettichord.com
>
>_______________________________________________
>Wtr-core mailing list
>Wtr-core at rubyforge.org
>http://rubyforge.org/mailman/listinfo/wtr-core
>
>  
>


-- 
Qantom Software

http://www.qantom.com
Ph : 91-80-26799269 Xtn. 125
sip : raghu at sip411.com
--


From sy1234 at gmail.com  Fri Dec  2 09:17:16 2005
From: sy1234 at gmail.com (Sy Ali)
Date: Fri, 2 Dec 2005 09:17:16 -0500
Subject: [Wtr-core] OpenQA.org
In-Reply-To: <5.1.0.14.2.20051202000327.033d54f0@pop.gmail.com>
References: <5.1.0.14.2.20051202000327.033d54f0@pop.gmail.com>
Message-ID: <1e55af990512020617s23effa08l107632a727207098@mail.gmail.com>

On 12/2/05, Bret Pettichord <bret at pettichord.com> wrote:
[re www.OpenQA.org]
> Please take a look at it and let me know what you think. I think it would
> be much better for us to use Subversion and Jira than CVS and the "trackers".

They seem to be hosting only the one other project.  What's their
track record?  Are they reliable?

Mind you, the one project they host is selenium.. so that says a lot.


From bret at pettichord.com  Sat Dec  3 19:37:06 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Sat, 03 Dec 2005 18:37:06 -0600
Subject: [Wtr-core] OpenQA.org
In-Reply-To: <1e55af990512020617s23effa08l107632a727207098@mail.gmail.co
 m>
References: <5.1.0.14.2.20051202000327.033d54f0@pop.gmail.com>
	<5.1.0.14.2.20051202000327.033d54f0@pop.gmail.com>
Message-ID: <5.1.0.14.2.20051203173909.037a7ae8@pop.gmail.com>

At 08:17 AM 12/2/2005, Sy Ali wrote:
 > They seem to be hosting only the one other project.  What's their
 > track record?  Are they reliable?

Sy,

They just moved Selenium over this week.

I was responsible for the original hosting arrangements for Selenium when 
that project was launched by ThoughtWorks about a year ago. The project was 
originally hosted by ThoughtWorks, but because its IT organization was 
unable to provide adequate support for the repository, i authorized moving 
it to codehaus.org.

It's been in a kind of limbo since then, with the repository at Codehaus 
and the lists and bugs and wiki at ThoughtWorks. This move brings 
everything together at OpenQA.org.

Paul Hammant has been the prime mover at ThoughtWorks in getting Selenium 
over to OpenQA.org. I don't know anything about Patrick Lightbody, who runs 
OpenQA.org. But if Paul trusts him, then i don't have any worries.

Another question you might have is what do we do about the wiki. I think 
confluence ranks with media wiki. And OpenQA would give us the benefit of 
single signon -- one account/password gets you logged into everything. But 
you've done a lot of work to set up the new Watir mediawiki site. So i'm 
really willing to defer to you on this issue.

Bret

_____________________
  Bret Pettichord
  www.pettichord.com


From sy1234 at gmail.com  Mon Dec  5 09:14:35 2005
From: sy1234 at gmail.com (Sy Ali)
Date: Mon, 5 Dec 2005 09:14:35 -0500
Subject: [Wtr-core] OpenQA.org
In-Reply-To: <5.1.0.14.2.20051203173909.037a7ae8@pop.gmail.com>
References: <5.1.0.14.2.20051202000327.033d54f0@pop.gmail.com>
	<5.1.0.14.2.20051203173909.037a7ae8@pop.gmail.com>
Message-ID: <1e55af990512050614s7200fdccof7593da1ddef8fe4@mail.gmail.com>

On 12/3/05, Bret Pettichord <bret at pettichord.com> wrote:
> Paul Hammant has been the prime mover at ThoughtWorks in getting Selenium
> over to OpenQA.org. I don't know anything about Patrick Lightbody, who runs
> OpenQA.org. But if Paul trusts him, then i don't have any worries.

That's good enough.


> Another question you might have is what do we do about the wiki. I think
> confluence ranks with media wiki. And OpenQA would give us the benefit of
> single signon -- one account/password gets you logged into everything. But
> you've done a lot of work to set up the new Watir mediawiki site. So i'm
> really willing to defer to you on this issue.

One signon is compelling.  However MediaWiki is quite capable and I
haven't met its match yet.  i took a look at confluence[1].. it's very
nice.  I disagree with some of their markup choices, and some features
were obviously put in as candy.  Some features are very cool, but I
myself wouldn't use a lot of what's there.

Is it possible to have ftp access and a mediawiki database set up at
that host?  MediaWiki can even share a database quite easily if need
be.  I don't mind hosting things separately.. since basically
everything is on autopilot.  Automated remote backups would take care
of the peace of mind for me.


[1] http://www.atlassian.com/software/confluence/


From jeff.darklight at gmail.com  Mon Dec  5 11:41:17 2005
From: jeff.darklight at gmail.com (Jeff Wood)
Date: Mon, 5 Dec 2005 08:41:17 -0800
Subject: [Wtr-core] ... Moving to SVN ...
Message-ID: <b539c61e0512050841l109c42a7la4945d92d99d3dd3@mail.gmail.com>

So, with the move to SVN comes the need for new connectivity information ...
any available for the WATiR SVN repo ?

j.

--
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org"

Jeff Wood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051205/53563752/attachment.htm

From bret at pettichord.com  Mon Dec  5 14:02:07 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 05 Dec 2005 13:02:07 -0600
Subject: [Wtr-core] ... Moving to SVN ...
In-Reply-To: <b539c61e0512050841l109c42a7la4945d92d99d3dd3@mail.gmail.co
 m>
Message-ID: <5.1.0.14.2.20051205130102.02c662c8@pop.gmail.com>

We haven't scheduled the move yet. For now, you should continue to use the 
CVS repo on rubyforge.net. We'll give a couple days notice before the move 
actually happens.

Bret

At 10:41 AM 12/5/2005, Jeff Wood wrote:
>So, with the move to SVN comes the need for new connectivity information 
>... any available for the WATiR SVN repo ?

_____________________
  Bret Pettichord
  www.pettichord.com


From jeff.darklight at gmail.com  Thu Dec  8 17:12:14 2005
From: jeff.darklight at gmail.com (Jeff Wood)
Date: Thu, 8 Dec 2005 14:12:14 -0800
Subject: [Wtr-core] ... rubyforge now supports SVN repos ...
Message-ID: <b539c61e0512081412n60a8f3b5m352fc61048173104@mail.gmail.com>

Does this change anything with regards to the planned move to openQA ???

...

j.

--
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org"

Jeff Wood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051208/8301b4cf/attachment.htm

From bret at pettichord.com  Fri Dec  9 01:35:21 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Fri, 9 Dec 2005 00:35:21 -0600
Subject: [Wtr-core] ... rubyforge now supports SVN repos ...
In-Reply-To: <b539c61e0512081412n60a8f3b5m352fc61048173104@mail.gmail.com>
References: <b539c61e0512081412n60a8f3b5m352fc61048173104@mail.gmail.com>
Message-ID: <ade75c5b0512082235r3f0fd9b0qa9ee48879f9adc5c@mail.gmail.com>

Very interesting. It does remove one motivator. But Jira is still a big
improvement. There is also some value to moving to the same site as Selenium
and Wet. But it certainly makes me less eager for the move. SVN is my #1
issue. BTW, i'm reading Mason's SVN book which i strongly recommend. (We are
also converting over to SVN at my job.)

Other thoughts?

On 12/8/05, Jeff Wood <jeff.darklight at gmail.com > wrote:
>
> Does this change anything with regards to the planned move to openQA ???
>
> ...
>
> j.
>
> --
> "Remember. Understand. Believe. Yield! -> http://ruby-lang.org "
>
> Jeff Wood
> _______________________________________________
> Wtr-core mailing list
> Wtr-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-core
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051209/e22909d5/attachment.htm

From jeff.darklight at gmail.com  Fri Dec  9 03:33:24 2005
From: jeff.darklight at gmail.com (Jeff Wood)
Date: Fri, 09 Dec 2005 00:33:24 -0800
Subject: [Wtr-core] ... rubyforge now supports SVN repos ...
In-Reply-To: <ade75c5b0512082235r3f0fd9b0qa9ee48879f9adc5c@mail.gmail.com>
References: <b539c61e0512081412n60a8f3b5m352fc61048173104@mail.gmail.com>
	<ade75c5b0512082235r3f0fd9b0qa9ee48879f9adc5c@mail.gmail.com>
Message-ID: <43994154.1000101@gmail.com>

Bret Pettichord wrote:

> Very interesting. It does remove one motivator. But Jira is still a 
> big improvement. There is also some value to moving to the same site 
> as Selenium and Wet. But it certainly makes me less eager for the 
> move. SVN is my #1 issue. BTW, i'm reading Mason's SVN book which i 
> strongly recommend. (We are also converting over to SVN at my job.)
>
> Other thoughts?
>
> On 12/8/05, *Jeff Wood* < jeff.darklight at gmail.com 
> <mailto:jeff.darklight at gmail.com>> wrote:
>
>     Does this change anything with regards to the planned move to
>     openQA ???
>
>     ...
>
>     j.
>
>     -- 
>     "Remember. Understand. Believe. Yield! -> http://ruby-lang.org
>     <http://ruby-lang.org> "
>
>     Jeff Wood
>     _______________________________________________
>     Wtr-core mailing list
>     Wtr-core at rubyforge.org <mailto:Wtr-core at rubyforge.org>
>     http://rubyforge.org/mailman/listinfo/wtr-core
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Wtr-core mailing list
>Wtr-core at rubyforge.org
>http://rubyforge.org/mailman/listinfo/wtr-core
>  
>
Ah, those are good reasons to do the move...

Just saw the news on the ruby-talk list and figured I'd forward it over.

j.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051209/e5f6ea32/attachment.htm

From Mark_Cain at rl.gov  Fri Dec  9 10:00:44 2005
From: Mark_Cain at rl.gov (Cain, Mark)
Date: Fri, 9 Dec 2005 07:00:44 -0800
Subject: [Wtr-core] ... rubyforge now supports SVN repos ...
Message-ID: <9C0BD1E3DAF1204D842D72E2DCE2A04ED1D4B9@EX5V.rl.gov>

I have been using it for months now and think it is better than anything
I have previously used.  There are several good clients available, I am
using TortoiseSVN and like it a lot. It integrates directly into windows
explorer and there is a pretty good eclipse plugin as well.

 

My $.02

 

--Mark

 

________________________________

From: wtr-core-bounces at rubyforge.org
[mailto:wtr-core-bounces at rubyforge.org] On Behalf Of Bret Pettichord
Sent: Thursday, December 08, 2005 10:35 PM
To: wtr-core at rubyforge.org
Subject: Re: [Wtr-core] ... rubyforge now supports SVN repos ...

 

Very interesting. It does remove one motivator. But Jira is still a big
improvement. There is also some value to moving to the same site as
Selenium and Wet. But it certainly makes me less eager for the move. SVN
is my #1 issue. BTW, i'm reading Mason's SVN book which i strongly
recommend. (We are also converting over to SVN at my job.)

Other thoughts?

On 12/8/05, Jeff Wood < jeff.darklight at gmail.com
<mailto:jeff.darklight at gmail.com> > wrote:

Does this change anything with regards to the planned move to openQA ???


...

j.

-- 
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org "

Jeff Wood 
_______________________________________________
Wtr-core mailing list
Wtr-core at rubyforge.org 
http://rubyforge.org/mailman/listinfo/wtr-core



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051209/19e575e6/attachment.htm

From bret at pettichord.com  Sat Dec 10 13:56:20 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Sat, 10 Dec 2005 12:56:20 -0600
Subject: [Wtr-core] Added one more feature to watir
In-Reply-To: <e26bda3e0512082303y77629cb8w62718bb6c6304f59@mail.gmail.com>
References: <e26bda3e0512082303y77629cb8w62718bb6c6304f59@mail.gmail.com>
Message-ID: <ade75c5b0512101056m4a7d86e0o20b7b96c9d77abec@mail.gmail.com>

Angrez,

The feature you speak of is mostly already committed to the trunk. The
syntax is ie.element(:[attr-name], [attr value]).

Please take a look at the code in trunk and let me know your thoughts. It
also allows you to get the value of attributes using ie.element().[attr
name].

This currently handles the most popular attributes, but not all of them. I
can think of a couple ways to extend these syntaxes to cover all possible
attributes, rather than introducing a new syntax.

(Actually ie.element().ole_object.[attr name] already will work for all
attributes.)

Bret

P.S. It is very hard for me to review a modified watir.rb. It's much easier
if you send a patch file (i.e. a diff) of your changes.

On 12/9/05, Angrez Singh <angrez at gmail.com> wrote:
>
> Hi Bret,
>
> I have added the code in watir.rb (local copy) to select element on the
> basis of any attribute. I think this was in the road map of watir 1.5. The
> syntax will look like:
>
> ie.element(:attr, [attr name], [attr value])
>
> Attached is the watir.rb file that contains the code. Could you please
> check the file and mail me back so that I can commit the code and bug fixes
> today itself. Also attached is the test script and html page. Change the
> path of the html file to point to path on your hard drive.
>
> I am also thinking of adding a new method to Element class for returning
> value of any attribute of element. Should I go ahead?
>
> Regards,
> Angrez
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051210/6b4d1513/attachment-0001.htm

From angrez at gmail.com  Mon Dec 12 00:23:08 2005
From: angrez at gmail.com (Angrez Singh)
Date: Mon, 12 Dec 2005 10:53:08 +0530
Subject: [Wtr-core] Added one more feature to watir
In-Reply-To: <ade75c5b0512101056m4a7d86e0o20b7b96c9d77abec@mail.gmail.com>
References: <e26bda3e0512082303y77629cb8w62718bb6c6304f59@mail.gmail.com>
	<ade75c5b0512101056m4a7d86e0o20b7b96c9d77abec@mail.gmail.com>
Message-ID: <e26bda3e0512112123he4184f9r4fd3b15521d8ba61@mail.gmail.com>

Hi Bret,

I have looked at the trunk and found that the feature is there. But that
works for only some standard attributes (not all). Also if tommorrow some
new attribute gets added to the elements then we have to change the code in
order to support new attribute. But in my case it wouldn't be the case. Also
if someone adds his/her own attribute to the tag (which is not a standard
attribute), and he/she wants to access element according to that attribute,
there will be no way.

About the syntax, it is familiar syntax as we use the same for accessing
Radio and Checkbox elements.
ie.radio(:selector, name, value)

Attached is the diff of the watir.rb. The diff was taken using the following
command:
diff watir.rb watir.rb.original

What do you guys think about this feature?

Regards,
Angrez


On 12/11/05, Bret Pettichord <bret at pettichord.com> wrote:
>
> Angrez,
>
> The feature you speak of is mostly already committed to the trunk. The
> syntax is ie.element(:[attr-name], [attr value]).
>
> Please take a look at the code in trunk and let me know your thoughts. It
> also allows you to get the value of attributes using ie.element().[attr
> name].
>
> This currently handles the most popular attributes, but not all of them. I
> can think of a couple ways to extend these syntaxes to cover all possible
> attributes, rather than introducing a new syntax.
>
> (Actually ie.element().ole_object.[attr name] already will work for all
> attributes.)
>
> Bret
>
> P.S. It is very hard for me to review a modified watir.rb. It's much
> easier if you send a patch file (i.e. a diff) of your changes.
>
> On 12/9/05, Angrez Singh <angrez at gmail.com> wrote:
> >
> > Hi Bret,
> >
> > I have added the code in watir.rb (local copy) to select element on the
> > basis of any attribute. I think this was in the road map of watir 1.5.
> > The syntax will look like:
> >
> > ie.element(:attr, [attr name], [attr value])
> >
> > Attached is the watir.rb file that contains the code. Could you please
> > check the file and mail me back so that I can commit the code and bug fixes
> > today itself. Also attached is the test script and html page. Change the
> > path of the html file to point to path on your hard drive.
> >
> > I am also thinking of adding a new method to Element class for returning
> > value of any attribute of element. Should I go ahead?
> >
> > Regards,
> > Angrez
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051212/7367a027/attachment.htm
-------------- next part --------------
235,236c235,236
<             class_eval "def #{method_name}(how, what, value = nil)
<                           #{klass_name}.new(self, how, what, value)
---
>             class_eval "def #{method_name}(how, what)
>                           #{klass_name}.new(self, how, what)
242c242
<             class_eval "def #{method_name}(how, what = nil, value = nil)
---
>             class_eval "def #{method_name}(how, what = nil)
244c244
<                           #{klass_name}.new(self, how, what, value)
---
>                           #{klass_name}.new(self, how, what)
430,431c430,431
<         def hidden(how, what, value = nil)
<             return Hidden.new(self, how, what, value)
---
>         def hidden(how, what)
>             return Hidden.new(self, how, what)
468,469c468,469
<         def select_list(how, what, value = nil) 
<             return SelectList.new(self, how, what, value)
---
>         def select_list(how, what) 
>             return SelectList.new(self, how, what)
613,614c613,614
<         def link(how, what, value = nil) 
<             return Link.new(self, how, what, value)
---
>         def link(how, what) 
>             return Link.new(self, how, what)
692,693c692,693
<         def div(how, what, value = nil)
<             return Div.new(self, how, what, value)
---
>         def div(how, what)
>             return Div.new(self, how, what)
724,725c724,725
<         def span(how, what, value = nil)
<             return Span.new(self, how, what, value)
---
>         def span(how, what)
>             return Span.new(self, how, what)
757,758c757,758
<         def p(how, what, value = nil)
<             return P.new(self, how, what, value)
---
>         def p(how, what)
>             return P.new(self, how, what)
790,791c790,791
<         def pre(how, what, value = nil)
<             return Pre.new(self, how, what, value)
---
>         def pre(how, what)
>             return Pre.new(self, how, what)
823,824c823,824
<         def label(how, what, value = nil)
<             return Label.new(self, how, what, value)
---
>         def label(how, what)
>             return Label.new(self, how, what)
911,918d910
<                     elsif how == :attr
<                         attribute = object.getAttribute(what)
< 
<                         if value
<                             if(attribute && value.match(attribute))
<                                 o = object
<                             end
<                         end
943c935
<         def locate_tagged_element(tag, how, what, value)
---
>         def locate_tagged_element(tag, how, what)
953,960c945
<                     attribute = count
<                 elsif how == :attr
<                     attribute = object.getAttribute(what)
<                     if value
<                         if(attribute && value.match(attribute))
<                             o = object
<                         end
<                     end                        
---
>                     attribute = count                        
2229,2234d2213
< 
<         # Returns the value of attribute if it exists else return nil
<         def attribute_value(attribute)
<             assert_exists
<             return ole_object.getAttribute(attribute)
<         end    
2423c2402
<         def initialize(container, how, what, value)
---
>         def initialize(container, how, what)
2427d2405
<             @value = value
2448,2450d2425
<                     when :attr
<                         attribute = thisForm.getAttribute(@what)
<                         @value.match(attribute) ? thisForm : nil
2550c2525
<                 @o = @container.locate_tagged_element(self.class::TAG, @how, @what, @value)
---
>                 @o = @container.locate_tagged_element(self.class::TAG, @how, @what)
2554c2529
<         def initialize(container, how, what, value)
---
>         def initialize(container, how, what)
2558d2532
<             @value = value
2612c2586
<             n <<   "inner text:".ljust(TO_S_SIZE) + self.text
---
>             n <<   "inner text:".ljust(TO_S_SIZE) + self.innerText
2642c2616
<             Table.new(container, :direct, o, nil)
---
>             Table.new(container, :direct, o)
2649c2623
<         def initialize(container, how, what, value)
---
>         def initialize(container, how, what)
2653d2626
<             @value = value
2663c2636
<                 @o = @container.locate_tagged_element('TABLE', @how, @what, @value)
---
>                 @o = @container.locate_tagged_element('TABLE', @how, @what)
2716c2689
<             1.upto( @o.getElementsByTagName("TR").length) { |i|  yield TableRow.new(@container, :direct, row(i), nil )    }
---
>             1.upto( @o.getElementsByTagName("TR").length) { |i|  yield TableRow.new(@container, :direct, row(i) )    }
2886c2859
<                 @o = @container.locate_tagged_element("TR", @how, @what, @value)   
---
>                 @o = @container.locate_tagged_element("TR", @how, @what)   
2891c2864
<                     @cells << TableCell.new(@container, :direct, oo, nil)
---
>                     @cells << TableCell.new(@container, :direct, oo)
2901c2874
<         def initialize(container, how, what, value)
---
>         def initialize(container, how, what)
2904,2905c2877
<             @what = what
<             @value = value   
---
>             @what = what   
2945c2917
<                 @o = @container.locate_tagged_element("TD", @how, @what, @value)   
---
>                 @o = @container.locate_tagged_element("TD", @how, @what)   
2953c2925
<         def initialize(container, how, what, value)   
---
>         def initialize(container, how, what)   
2956,2957c2928
<             @what = what
<             @value = value        
---
>             @what = what   
2987c2958
<         def initialize(container, how, what, value)
---
>         def initialize(container, how, what)
2991d2961
<             @value = value
2999c2969
<             @o = @container.locate_tagged_element('IMG', @how, @what, @value)
---
>             @o = @container.locate_tagged_element('IMG', @how, @what)
3120c3090
<         def initialize(container, how, what, value)
---
>         def initialize(container, how, what)
3124d3093
<             @value = value
3133c3102
<                 @o = @container.locate_tagged_element('A', @how, @what, @value)
---
>                 @o = @container.locate_tagged_element('A', @how, @what)
3160c3129
<             n <<   "inner text:".ljust(TO_S_SIZE) + self.text
---
>             n <<   "inner text:".ljust(TO_S_SIZE) + self.innerText
3181c3150
<                 @o = @container.locate_input_element(@how, @what, self.class::INPUT_TYPES, @value)
---
>                 @o = @container.locate_input_element(@how, @what, self.class::INPUT_TYPES)
3184c3153
<         def initialize(container, how, what, value = nil)
---
>         def initialize(container, how, what)
3188d3156
<             @value = value
3367c3335
<             n <<   "max length:".ljust(TO_S_SIZE) + self.maxlength.to_s
---
>             n <<   "max length:".ljust(TO_S_SIZE) + self.maxLength.to_s


From angrez at gmail.com  Mon Dec 12 03:17:54 2005
From: angrez at gmail.com (Angrez Singh)
Date: Mon, 12 Dec 2005 13:47:54 +0530
Subject: [Wtr-core] Added one more feature to watir
In-Reply-To: <e26bda3e0512112123he4184f9r4fd3b15521d8ba61@mail.gmail.com>
References: <e26bda3e0512082303y77629cb8w62718bb6c6304f59@mail.gmail.com>
	<ade75c5b0512101056m4a7d86e0o20b7b96c9d77abec@mail.gmail.com>
	<e26bda3e0512112123he4184f9r4fd3b15521d8ba61@mail.gmail.com>
Message-ID: <e26bda3e0512120017i7c5806b0iafb2da30dd01a714@mail.gmail.com>

Hi,
If it sounds little rude,

What do you guys think about this feature?


I mean what are your thoughts about this feature.

Regards,
Angrez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051212/c3732847/attachment.htm

From angrez at gmail.com  Mon Dec 12 12:00:17 2005
From: angrez at gmail.com (Angrez Singh)
Date: Mon, 12 Dec 2005 22:30:17 +0530
Subject: [Wtr-core] Added one more feature to watir
In-Reply-To: <ade75c5b0512120840w7c299009u124512229792bdda@mail.gmail.com>
References: <e26bda3e0512082303y77629cb8w62718bb6c6304f59@mail.gmail.com>
	<ade75c5b0512101056m4a7d86e0o20b7b96c9d77abec@mail.gmail.com>
	<e26bda3e0512112123he4184f9r4fd3b15521d8ba61@mail.gmail.com>
	<ade75c5b0512120840w7c299009u124512229792bdda@mail.gmail.com>
Message-ID: <e26bda3e0512120900g1ac41f7ct40b60e2feaa00fcd@mail.gmail.com>

>
> These are good points. It would help me to know whether there are specific
> attributes you are trying to get to that aren't in there right now, or
> whether this is strictly a theoretical concern. I mostly subscribe to a
> YAGNI philosophy. (Namely, don't build things until you actually know that
> you need them otherwise, You Aren't Going to Need It.)
>

I am investigating and let you know. By the way  MSDN reference of  MSHTML
has a  lot of attributes for  every  HTML element but I don't know if they
are used in real world or not.

I am also very resistant to changing the standard interface. With the
> proposed changes, for most attributes there would be two syntaxes for
> specifying elements by attribute, one of which is more general than the
> other. This makes the API harder to understand. I would rather fix the
> current syntax to be more general (if this really is a significant issue --
> i haven't been convinced that it is, but i'm not convinced that it isn't
> either), by using method missing to make an attribute search in this case:
> ie.element(:[extra attribute], 'value').
>

It can be generalized.

I am also thinking of adding a new method to Element class for returning
> > value of any attribute of element. Should I go ahead?
>
>
> I like the idea. What would the method be named?
>

I am thinking of adding a method named 'attribute_value ( [attribute_name]
), to the base element class. What are your thoughts?

Regards,
Angrez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051212/026302db/attachment.htm

From bpettichord at gmail.com  Mon Dec 12 11:40:18 2005
From: bpettichord at gmail.com (Bret Pettichord)
Date: Mon, 12 Dec 2005 10:40:18 -0600
Subject: [Wtr-core] Added one more feature to watir
In-Reply-To: <e26bda3e0512112123he4184f9r4fd3b15521d8ba61@mail.gmail.com>
References: <e26bda3e0512082303y77629cb8w62718bb6c6304f59@mail.gmail.com>
	<ade75c5b0512101056m4a7d86e0o20b7b96c9d77abec@mail.gmail.com>
	<e26bda3e0512112123he4184f9r4fd3b15521d8ba61@mail.gmail.com>
Message-ID: <ade75c5b0512120840w7c299009u124512229792bdda@mail.gmail.com>

On 12/11/05, Angrez Singh <angrez at gmail.com> wrote:
>
> I have looked at the trunk and found that the feature is there. But that
> works for only some standard attributes (not all). Also if tommorrow some
> new attribute gets added to the elements then we have to change the code in
> order to support new attribute. But in my case it wouldn't be the case. Also
> if someone adds his/her own attribute to the tag (which is not a standard
> attribute), and he/she wants to access element according to that attribute,
> there will be no way.


These are good points. It would help me to know whether there are specific
attributes you are trying to get to that aren't in there right now, or
whether this is strictly a theoretical concern. I mostly subscribe to a
YAGNI philosophy. (Namely, don't build things until you actually know that
you need them otherwise, You Aren't Going to Need It.)

I am also very resistant to changing the standard interface. With the
proposed changes, for most attributes there would be two syntaxes for
specifying elements by attribute, one of which is more general than the
other. This makes the API harder to understand. I would rather fix the
current syntax to be more general (if this really is a significant issue --
i haven't been convinced that it is, but i'm not convinced that it isn't
either), by using method missing to make an attribute search in this case:
ie.element(:[extra attribute], 'value').

My intent is to also reintroduce a more general syntax that would allow
blocks to specify elements. Thus: ie.element{|e| e.attribute('name') ==
'value'} would give you the power you want without actually having to
introduces an attribute-specific syntax.

About the syntax, it is familiar syntax as we use the same for accessing
> Radio and Checkbox elements.
> ie.radio(:selector, name, value)


I consider this deviation from the standard to be problematic, and would be
happy to eventually deprecate it. The problem, really, is that you need
specify radio and checkbox elements using two attributes. Once we provide a
general mechanism for supporting multiple attributes (like Wet), then i plan
to discourage this syntax.

I am also thinking of adding a new method to Element class for returning
> value of any attribute of element. Should I go ahead?


I like the idea. What would the method be named?

Bret
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051212/09760060/attachment-0001.htm

From bret at pettichord.com  Mon Dec 12 15:06:31 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 12 Dec 2005 14:06:31 -0600
Subject: [Wtr-core] Migrating to OpenQA.org
Message-ID: <5.1.0.14.2.20051212122452.04008f88@pop.gmail.com>

Tom,

We are making plans to move the hosting of Watir to OpenQA.org. This is 
going to be hosting many testing tools. They already have Selenium.

One reason for the move is that they have offer Jira and Confluence for 
their tracking and wiki. In my view, these are much better than the tools 
used at Rubyforge. The other is that there is some value to being 
co-located with other testing tools. Our hope is to increase the 
integration between these tools with time. Their web-based forums are also 
attractive.

We will probably continue to use Rubyforge for the IEController and 
Scripting101 subprojects of Web Testing with Ruby. The Scripting101 source 
base is still active. I also expect that we'll continue to make our 
releases and gems for Watir available through Rubyforge.

We will also be migrating from CVS to SVN at OpenQA.org. I'm pleased to see 
that Rubyforge is now offer SVN support.

I'm sending this note just as a heads up and to let you know our reasons. 
We've been very happy with Rubyforge and appreciate your efforts to keep it 
up and running. We may find ourselves asking for assistance with the 
migration at some point as well.

Bret

_____________________
  Bret Pettichord
  www.pettichord.com


From bret at pettichord.com  Mon Dec 12 15:11:42 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 12 Dec 2005 14:11:42 -0600
Subject: [Wtr-core] submission?
Message-ID: <5.1.0.14.2.20051212141022.0419dcb0@pop.gmail.com>

I had thought that i needed to review some code that had been sent to me a 
month or so ago. I checked my mail backlog today and couldn't find it. If 
you are waiting for this review, please let me know. (I'm not talking about 
Angrez.)

Bret


_____________________
  Bret Pettichord
  www.pettichord.com


From jeff.darklight at gmail.com  Mon Dec 12 15:20:03 2005
From: jeff.darklight at gmail.com (Jeff Wood)
Date: Mon, 12 Dec 2005 12:20:03 -0800
Subject: [Wtr-core] submission?
In-Reply-To: <5.1.0.14.2.20051212141022.0419dcb0@pop.gmail.com>
References: <5.1.0.14.2.20051212141022.0419dcb0@pop.gmail.com>
Message-ID: <b539c61e0512121220o21329618r4c3455ae4c9b9dfe@mail.gmail.com>

I had sent code to fix the bug with frames & iframes ... I'll have to resend
it this evening when I get home if you can't find it.

j.


On 12/12/05, Bret Pettichord <bret at pettichord.com> wrote:
>
> I had thought that i needed to review some code that had been sent to me a
> month or so ago. I checked my mail backlog today and couldn't find it. If
> you are waiting for this review, please let me know. (I'm not talking
> about
> Angrez.)
>
> Bret
>
>
> _____________________
>   Bret Pettichord
>   www.pettichord.com
>
> _______________________________________________
> Wtr-core mailing list
> Wtr-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-core
>



--
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org"

Jeff Wood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051212/a16185a6/attachment.htm

From tom at infoether.com  Mon Dec 12 16:27:28 2005
From: tom at infoether.com (Tom Copeland)
Date: Mon, 12 Dec 2005 16:27:28 -0500
Subject: [Wtr-core] Migrating to OpenQA.org
In-Reply-To: <5.1.0.14.2.20051212122452.04008f88@pop.gmail.com>
References: <5.1.0.14.2.20051212122452.04008f88@pop.gmail.com>
Message-ID: <1134422848.6317.5.camel@hal>

Hi Bret -

Sure thing, that all sounds fine!  It makes sense that when a project
really takes off - as Watir has done - it may find a more suitable home
somewhere else.  If RubyForge is acting as an incubator for excellent
Ruby projects, I think it's serving a good purpose.

Let me know if I can do anything to help you transition more smoothly,

Yours,

Tom

On Mon, 2005-12-12 at 14:06 -0600, Bret Pettichord wrote:
> Tom,
> 
> We are making plans to move the hosting of Watir to OpenQA.org. This is 
> going to be hosting many testing tools. They already have Selenium.
> 
> One reason for the move is that they have offer Jira and Confluence for 
> their tracking and wiki. In my view, these are much better than the tools 
> used at Rubyforge. The other is that there is some value to being 
> co-located with other testing tools. Our hope is to increase the 
> integration between these tools with time. Their web-based forums are also 
> attractive.
> 
> We will probably continue to use Rubyforge for the IEController and 
> Scripting101 subprojects of Web Testing with Ruby. The Scripting101 source 
> base is still active. I also expect that we'll continue to make our 
> releases and gems for Watir available through Rubyforge.
> 
> We will also be migrating from CVS to SVN at OpenQA.org. I'm pleased to see 
> that Rubyforge is now offer SVN support.
> 
> I'm sending this note just as a heads up and to let you know our reasons. 
> We've been very happy with Rubyforge and appreciate your efforts to keep it 
> up and running. We may find ourselves asking for assistance with the 
> migration at some point as well.
> 
> Bret
> 
> _____________________
>   Bret Pettichord
>   www.pettichord.com
> 


From angrez at gmail.com  Mon Dec 19 02:08:09 2005
From: angrez at gmail.com (Angrez Singh)
Date: Mon, 19 Dec 2005 12:38:09 +0530
Subject: [Wtr-core] Added one more feature to watir
In-Reply-To: <e26bda3e0512120900g1ac41f7ct40b60e2feaa00fcd@mail.gmail.com>
References: <e26bda3e0512082303y77629cb8w62718bb6c6304f59@mail.gmail.com>
	<ade75c5b0512101056m4a7d86e0o20b7b96c9d77abec@mail.gmail.com>
	<e26bda3e0512112123he4184f9r4fd3b15521d8ba61@mail.gmail.com>
	<ade75c5b0512120840w7c299009u124512229792bdda@mail.gmail.com>
	<e26bda3e0512120900g1ac41f7ct40b60e2feaa00fcd@mail.gmail.com>
Message-ID: <e26bda3e0512182308l80b7304te53c5bdb571f630b@mail.gmail.com>

Hi Bret,

I am also very resistant to changing the standard interface. With the
> > proposed changes, for most attributes there would be two syntaxes for
> > specifying elements by attribute, one of which is more general than the
> > other. This makes the API harder to understand. I would rather fix the
> > current syntax to be more general (if this really is a significant issue --
> > i haven't been convinced that it is, but i'm not convinced that it isn't
> > either), by using method missing to make an attribute search in this case:
> > ie.element(:[extra attribute], 'value').
> >
>
> It can be generalized.
>

While locating the element using locate_input_element &
locate_tagged_element methods, if how is not index then we call the some
method in element with the name same as how. If that attribute is there in
the element then we return the value which is then matched to return the
correct element. Correct?

If yes, then we can  change these functions a little bit, instead of
invoking the methods in element class (that exists only for some predefined
attributes), we can use getAttribute method of OLEObject to get the value of
any attribute (attribute will be specified by 'how' variable). If that value
matches with 'what' variable, we can return that element. This will provide
us with the power to locate element with any attribute without changing the
syntax.

What are your thoughts ?

I am also thinking of adding a new method to Element class for returning
> > > value of any attribute of element. Should I go ahead?
> >
> >
> > I like the idea. What would the method be named?
> >
>
> I am thinking of adding a method named 'attribute_value ( [attribute_name]
> ), to the base element class. What are your thoughts?
>

I have committed the code to HEAD with two bug fixes also.

Regards,
Angrez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-core/attachments/20051219/b71da490/attachment.htm

From sy1234 at gmail.com  Mon Dec 19 17:52:53 2005
From: sy1234 at gmail.com (Sy Ali)
Date: Mon, 19 Dec 2005 22:52:53 +0000
Subject: [Wtr-core] Migrating to Confluence
Message-ID: <1e55af990512191452kd0ce236v78831470368f3954@mail.gmail.com>

Let me know when Confluence is set up and I'll lend a hand with that migration.


From bret at pettichord.com  Thu Dec 29 12:42:55 2005
From: bret at pettichord.com (Bret Pettichord)
Date: Thu, 29 Dec 2005 11:42:55 -0600
Subject: [Wtr-core] Patch for HEAD - Updated Frame#locate
In-Reply-To: <b539c61e0511282213h7e16eb6cm5de9f7dc9cfea4e5@mail.gmail.co
 m>
References: <b539c61e0511282157o53ebf379jd5461478b8d547d3@mail.gmail.com>
	<b539c61e0511282133w50ec8126gffc4acb966f88a03@mail.gmail.com>
	<b539c61e0511282157o53ebf379jd5461478b8d547d3@mail.gmail.com>
Message-ID: <5.1.0.14.2.20051229113437.020f4880@pop.gmail.com>

Jeff,

Thanks for your patch adding new methods for locating iframes. Sorry for 
the delay in replying.

When i run the unit tests with your patch, i get the errors detailed below. 
(It's unclear to me how failure #2 could be related to your patch; perhaps 
it has an unrelated cause.)

We need these fixed, before we can commit the patch. We also need tests 
(unit tests, not just manual tests in irb) for the new features that you 
added, which will ensure that the new functionality continues to work.

Thanks again for your work on Watir.

Bret

Loaded suite D:/workspace/watir/unittests/core_tests
Started
...........E...........F..................................................F.E.EE.E...E............E..........................................................................
Finished in 100.304 seconds.

   1) Error:
test_frame(TC_Buttons):
Watir::Exception::UnknownObjectException: Unable to locate object, using 
caption and Click Me
     D:/workspace/watir/unittests/../watir.rb:1998:in `assert_exists'
     D:/workspace/watir/unittests/../watir.rb:2207:in `enabled?'
     D:/workspace/watir/unittests/../unittests/buttons_test.rb:129:in 
`test_frame'

   2) Failure:
test_using_default(TC_Defaults) 
[D:/workspace/watir/unittests/../unittests/speed_settings_test.rb:12]:
<:slow> expected but was
<:fast>.

   3) Failure:
test_links_in_frames(TC_Frame_Links) 
[D:/workspace/watir/unittests/../unittests/links_test.rb:147]:
<false> is not true.

   4) Error:
test_frame_no_what(TC_Frames):
Watir::Exception::UnknownObjectException: Unable to locate object, using id 
and b2
     D:/workspace/watir/unittests/../watir.rb:1998:in `assert_exists'
     D:/workspace/watir/unittests/../watir.rb:2207:in `enabled?'
     D:/workspace/watir/unittests/../unittests/frame_test.rb:17:in 
`test_frame_no_what'

   5) Error:
test_frame_using_name(TC_Frames):
Watir::Exception::UnknownObjectException: Unable to locate object, using id 
and b2
     D:/workspace/watir/unittests/../watir.rb:1998:in `assert_exists'
     D:/workspace/watir/unittests/../watir.rb:2207:in `enabled?'
     D:/workspace/watir/unittests/../unittests/frame_test.rb:24:in 
`test_frame_using_name'

   6) Error:
test_frame_using_name_and_regexp(TC_Frames):
Watir::Exception::UnknownObjectException: Unable to locate object, using id 
and b2
     D:/workspace/watir/unittests/../watir.rb:1998:in `assert_exists'
     D:/workspace/watir/unittests/../watir.rb:2207:in `enabled?'
     D:/workspace/watir/unittests/../unittests/frame_test.rb:30:in 
`test_frame_using_name_and_regexp'

   7) Error:
test_preset_frame(TC_Frames):
Watir::Exception::UnknownObjectException: Unable to locate object, using id 
and b2
     D:/workspace/watir/unittests/../watir.rb:1998:in `assert_exists'
     D:/workspace/watir/unittests/../watir.rb:2207:in `enabled?'
     D:/workspace/watir/unittests/../unittests/frame_test.rb:47:in 
`test_preset_frame'
     D:/workspace/watir/unittests/../unittests/frame_test.rb:46:in 
`instance_eval'
     D:/workspace/watir/unittests/../unittests/frame_test.rb:46:in 
`instance_eval'
     D:/workspace/watir/unittests/../unittests/frame_test.rb:46:in 
`test_preset_frame'

   8) Error:
test_Iframe(TC_IFrames):
Watir::Exception::UnknownObjectException: Unable to locate object, using 
name and textToSend
     D:/workspace/watir/unittests/../watir.rb:1998:in `assert_exists'
     D:/workspace/watir/unittests/../watir.rb:3467:in `set'
     D:/workspace/watir/unittests/../unittests/frame_test.rb:98:in 
`test_Iframe'

   9) Error:
test_frame(TC_NestedFrames):
Watir::Exception::UnknownFrameException: Unable to locate a frame with name 
senderFrame
     D:/workspace/watir/unittests/../watir.rb:2296:in `locate'
     D:/workspace/watir/unittests/../watir.rb:2306:in `initialize'
     (eval):3:in `new'
     (eval):3:in `frame'
     D:/workspace/watir/unittests/../unittests/frame_test.rb:82:in `test_frame'

173 tests, 980 assertions, 2 failures, 7 errors

At 12:13 AM 11/29/2005, Jeff Wood wrote:
>Ok, sorry for the confusion ... I had two small little errors ... all 
>better. and all working.  Please review & comment.
>
>j.
>
>On 11/28/05, Jeff Wood 
><<mailto:jeff.darklight at gmail.com>jeff.darklight at gmail.com> wrote:
>>Sorry, put a hold on that ... seems like I found a few new issues ...
>>
>>j.
>>
>>
>>On 11/28/05, Jeff Wood <<mailto:jeff.darklight at gmail.com> 
>>jeff.darklight at gmail.com> wrote:
>>>Ok, here's my submission for a patch to HEAD for the Frame#locate function.
>>>
>>>It solves the bug with not being able to find iframes by anything other 
>>>than :index
>>>
>>>With this patch both frames and iframes are all now findable based on
>>>
>>>:index, :src, :name, or :id
>>>
>>>Let me know what you think.
>>>
>>>I haven't updated the testcases yet, but I did test it out manually ( 
>>>good 'ol irb ).
>>>
>>>j.
>>>
>>>--
>>>"Remember. Understand. Believe. Yield! -> 
>>><http://ruby-lang.org>http://ruby-lang.org"
>>>
>>>Jeff Wood
>>
>>
>>
>>--
>>"Remember. Understand. Believe. Yield! -> 
>><http://ruby-lang.org>http://ruby-lang.org"
>>
>>Jeff Wood
>
>
>
>--
>"Remember. Understand. Believe. Yield! -> 
><http://ruby-lang.org>http://ruby-lang.org"
>
>Jeff Wood
>_______________________________________________
>Wtr-core mailing list
>Wtr-core at rubyforge.org
>http://rubyforge.org/mailman/listinfo/wtr-core

_____________________
  Bret Pettichord
  www.pettichord.com