From bret at pettichord.com  Tue Jul 10 00:55:51 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 09 Jul 2007 23:55:51 -0500
Subject: [Wtr-development] Updates
Message-ID: <46931157.9040900@pettichord.com>

I am currently working on a new website for wtr.rubyforge.org -- a new 
set of pages that are up to date and provide more detail than what is 
available. I realize that this addresses a long-standing complaint.

I have been committing my work in progress to 
https://svn.openqa.org/svn/watir/trunk/doc. I plan to post them to 
wtr.rubyforge.org as soon as they are clearly no worse (i.e. no more out 
of date) than what is presently there. You are welcome to review and 
comment on the work in progress. You can read the *.page files yourself 
-- they are in textile, and easy to read markup language. You can also 
install webgen and the build the pages yourself if you want to see them.

My goal is mostly to provide pointers to the most current information 
that is available. I appreciate your help in this regard in particular, 
that is in publishing so much information about Watir.

In the process of doing this, i am uncovering discrepancies and 
inconsistencies that I feel should be discussed. I will be using this 
list (wtr-development) for this discussion and I hope that those of you 
who i have cc'd are reading this list.

Some specific concerns follow shortly.

I have also sent an invite to the members of wtr-general to join the new 
group at google. However, this invitation has been rerouted to the spam 
police at google and i fear it may not be released. So a more indirect 
invitation directly to wtr-general may be in order. I appreciate your 
help with this migration.

Bret



From paul.rogers at shaw.ca  Tue Jul 10 11:28:10 2007
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Tue, 10 Jul 2007 09:28:10 -0600
Subject: [Wtr-development] Updates
In-Reply-To: <46931157.9040900@pettichord.com>
References: <46931157.9040900@pettichord.com>
Message-ID: <cc71fd86ac9c.4693512a@shaw.ca>

this seems like an appropriate time for what I have been doing....

I was hoping to get a lot of work done on a couple of things - a 'rails-like' interface to watir that I think makes more readable code. Ive been using a modified form of it at work for a while and Im mostly pleased. I expect it will be an addon done via contrib or a different project.

Ive also been looking at the dialog ( file downloads, security alerts etc) but really didnt get much done. What I have done however is produce a doc that currently explains all the dialogs, and sample javascript of what produces them. Im then going to get the 'current' way of dealing with them in, and then hopefully come up with a better winclicker ( or whatever )

Paul

----- Original Message -----
From: Bret Pettichord <bret at pettichord.com>
Date: Monday, July 9, 2007 10:58 pm
Subject: Updates
To: wtr-development at rubyforge.org
Cc: Charley Baker <charley.baker at gmail.com>, Jeff Fry <jeff.fry at gmail.com>, Zeljko Filipin <zeljko.filipin at gmail.com>, Paul Rogers <paul.rogers at shaw.ca>

> I am currently working on a new website for wtr.rubyforge.org -- 
> a new 
> set of pages that are up to date and provide more detail than 
> what is 
> available. I realize that this addresses a long-standing complaint.
> 
> I have been committing my work in progress to 
> https://svn.openqa.org/svn/watir/trunk/doc. I plan to post them 
> to 
> wtr.rubyforge.org as soon as they are clearly no worse (i.e. no 
> more out 
> of date) than what is presently there. You are welcome to review 
> and 
> comment on the work in progress. You can read the *.page files 
> yourself 
> -- they are in textile, and easy to read markup language. You 
> can also 
> install webgen and the build the pages yourself if you want to 
> see them.
> 
> My goal is mostly to provide pointers to the most current 
> information 
> that is available. I appreciate your help in this regard in 
> particular, 
> that is in publishing so much information about Watir.
> 
> In the process of doing this, i am uncovering discrepancies and 
> inconsistencies that I feel should be discussed. I will be using 
> this 
> list (wtr-development) for this discussion and I hope that those 
> of you 
> who i have cc'd are reading this list.
> 
> Some specific concerns follow shortly.
> 
> I have also sent an invite to the members of wtr-general to join 
> the new 
> group at google. However, this invitation has been rerouted to 
> the spam 
> police at google and i fear it may not be released. So a more 
> indirect 
> invitation directly to wtr-general may be in order. I appreciate 
> your 
> help with this migration.
> 
> Bret
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-development/attachments/20070710/0a39e777/attachment-0001.html 

From bret at pettichord.com  Tue Jul 10 13:28:56 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 10 Jul 2007 12:28:56 -0500
Subject: [Wtr-development] Recommended version of Ruby]
Message-ID: <4693C1D8.8090305@pettichord.com>

(I posted this to wtr-general by mistake. I intended to post it here.)

What version of Ruby should we recommend?

After a recent discussion we agreed that the rdoc (readme.rb) should read:

   Best is to use Ruby 1.8.2-14 or later.
   However, if you are using the Watir::IE#modal_dialog method, you must 
use Ruby 1.8.2-14 and not a more recent version.
   Watir (in general) will not work with Ruby 1.8.1-13. (This version of 
Ruby has a bad WIN32OLE library.)

I revised this recommendation to this thus in the new (unpublished) website:

    First you need to "install
    Ruby":http://rubyforge.org/frs/?group_id=167 using
    the one-click installer for Windows.
    *We recommend Ruby 1.8.2-14 or later.*

    However, if you wish to use Watir's support for the *IE web modal
    dialog*
    then you "must use Ruby
    1.8.2-14":http://wiki.openqa.org/display/WTR/Installation
    and not a more recent version. This dialog is
    posted with the showModalDialog() JavaScript command and is
    supported with Watir's
    ie.modal_dialog command.

However, the wiki page for installing recommends 1.8.2-14 for everyone.
    http://wiki.openqa.org/display/WTR/Install+Ruby

I was surprised when i found this and started a discussion with Zeljko 
on the page, but thought the issue might be of more general interest.

Personally, i think that people should be using the latest generally 
available version of Ruby. There continue to be improvements with it. 
For example I recently reported several Ruby bugs that interfered with 
integrating Watir with Cruise Control. 
http://www.io.com/~wazmo/blog/archives/2007_04.html. At this point, we 
see problems in both 1.8.5 and 1.8.6, but expect that 1.8.7 will have 
these problems fixed and will be encouraging a move there when it happens.

Should our recommendation for newer versions of Ruby be more emphatic?

Another question regards the modal dialog support. I don't know if the 
community understands that at this point i am abandoning this 
functionality. I would love to see someone take it over and make it so 
that it was dependent on a specific version of Ruby. But i don't expect 
that to happen. But we can't allow this to say that all users should 
stick with 1.8.2 until the end of time.

For example, rubygems in 1.8.2 does not support the --install-depencies 
argument, which makes installing via gem much more complicated (esp. 
when i publish the gem to rubyforge.org). So once this is done, i will 
probably be telling people NOT to use 1.8.2, because i think it is more 
important to make our install instructions simple. We can have alternate 
instructions for the people who need the modal_dialog support.

I'd appreciate your thoughts and questions.

Bret



_______________________________________________
Wtr-general mailing list
Wtr-general at rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general


From paul.rogers at shaw.ca  Tue Jul 10 13:59:07 2007
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Tue, 10 Jul 2007 11:59:07 -0600
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <4693C1D8.8090305@pettichord.com>
References: <4693C1D8.8090305@pettichord.com>
Message-ID: <ccbeb17af70e.4693748b@shaw.ca>

how about pulling the modal_dialog support into a seperate entity ( gem, plug in what ever) and letting people who use that decide what version to use.
That may also tie in well with my dialog support stuff Im trying to do.

I guess one of the problems will be that people may not know they need? a certain version of ruby until they find they need to test modal dialogs, and then they have to install that version, which is basically a pain - Ive had to do this for rails compatability.

Was there a typo in your original post - you said 
" I would love to see someone take it over and make? it so? that it was dependent on a specific version of Ruby"

but did you mean ?
" I would love to see someone take it over and make? it so? that it was INDEPENDANT on a specific version of Ruby"



Paul


----- Original Message -----
From: Bret Pettichord <bret at pettichord.com>
Date: Tuesday, July 10, 2007 11:32 am
Subject: Recommended version of Ruby]
To: wtr-development at rubyforge.org
Cc: Paul Rogers <paul.rogers at shaw.ca>, Charley Baker <charley.baker at gmail.com>, Zeljko Filipin <zeljko.filipin at gmail.com>, Jeff Fry <jeff.fry at gmail.com>

> (I posted this to wtr-general by mistake. I intended to post it here.)
> 
> What version of Ruby should we recommend?
> 
> After a recent discussion we agreed that the rdoc (readme.rb) 
> should read:
> 
> ?? Best is to use Ruby 1.8.2-14 or later.
> ?? However, if you are using the 
> Watir::IE#modal_dialog method, you must 
> use Ruby 1.8.2-14 and not a more recent version.
> ?? Watir (in general) will not work with Ruby 1.8.1-
> 13. (This version of 
> Ruby has a bad WIN32OLE library.)
> 
> I revised this recommendation to this thus in the new 
> (unpublished) website:
> 
> ??? First you need to "install
> ??? Ruby":http://rubyforge.org/frs/?group_id=167 using
> ??? the one-click installer for Windows.
> ??? *We recommend Ruby 1.8.2-14 or later.*
> 
> ??? However, if you wish to use Watir's support 
> for the *IE web modal
> ??? dialog*
> ??? then you "must use Ruby
> ??? 1.8.2-
> 14":http://wiki.openqa.org/display/WTR/Installation??? and not a more recent version. This dialog is
> ??? posted with the showModalDialog() JavaScript 
> command and is
> ??? supported with Watir's
> ??? ie.modal_dialog command.
> 
> However, the wiki page for installing recommends 1.8.2-14 for 
> everyone.??? 
> http://wiki.openqa.org/display/WTR/Install+Ruby
> I was surprised when i found this and started a discussion with 
> Zeljko 
> on the page, but thought the issue might be of more general interest.
> 
> Personally, i think that people should be using the latest 
> generally 
> available version of Ruby. There continue to be improvements 
> with it. 
> For example I recently reported several Ruby bugs that 
> interfered with 
> integrating Watir with Cruise Control. 
> http://www.io.com/~wazmo/blog/archives/2007_04.html. At this 
> point, we 
> see problems in both 1.8.5 and 1.8.6, but expect that 1.8.7 will 
> have 
> these problems fixed and will be encouraging a move there when 
> it happens.
> 
> Should our recommendation for newer versions of Ruby be more emphatic?
> 
> Another question regards the modal dialog support. I don't know 
> if the 
> community understands that at this point i am abandoning this 
> functionality. I would love to see someone take it over and make 
> it so 
> that it was dependent on a specific version of Ruby. But i don't 
> expect 
> that to happen. But we can't allow this to say that all users 
> should 
> stick with 1.8.2 until the end of time.
> 
> For example, rubygems in 1.8.2 does not support the --install-
> depencies 
> argument, which makes installing via gem much more complicated 
> (esp. 
> when i publish the gem to rubyforge.org). So once this is done, 
> i will 
> probably be telling people NOT to use 1.8.2, because i think it 
> is more 
> important to make our install instructions simple. We can have 
> alternate 
> instructions for the people who need the modal_dialog support.
> 
> I'd appreciate your thoughts and questions.
> 
> Bret
> 
> 
> 
> _______________________________________________
> Wtr-general mailing list
> Wtr-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-general
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-development/attachments/20070710/9ece9250/attachment.html 

From bret at pettichord.com  Tue Jul 10 14:44:31 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 10 Jul 2007 13:44:31 -0500
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <ccbeb17af70e.4693748b@shaw.ca>
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
Message-ID: <ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>

On 7/10/07, Paul Rogers <paul.rogers at shaw.ca> wrote:
>
> how about pulling the modal_dialog support into a seperate entity ( gem,
> plug in what ever) and letting people who use that decide what version to
> use.


This is an interesting suggestion. I guess it would help make people aware
of what has a separate set of dependencies. I've also been thinking about
making contrib a separate gem.

That may also tie in well with my dialog support stuff Im trying to do.
>
> I guess one of the problems will be that people may not know they need  a
> certain version of ruby until they find they need to test modal dialogs, and
> then they have to install that version, which is basically a pain - Ive had
> to do this for rails compatability.


My goal is to simplify using Watir for everyday users. What i don't know is
how many users are using modal dialog support. I suppose making it be a
separate gem would help give me some numbers.

Was there a typo in your original post - you said
> " I would love to see someone take it over and make  it so  that it was
> dependent on a specific version of Ruby"
>
> but did you mean ?
> " I would love to see someone take it over and make  it so  that it was
> INDEPENDANT on a specific version of Ruby"


Exactly.  Sorry for the confusion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-development/attachments/20070710/fc44cfe3/attachment.html 

From jeff.fry at gmail.com  Tue Jul 10 19:47:35 2007
From: jeff.fry at gmail.com (Jeff Fry)
Date: Tue, 10 Jul 2007 16:47:35 -0700
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
	<ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
Message-ID: <970956b0707101647i7cc3cee7oe2fb300aa4491da5@mail.gmail.com>

On 7/10/07, Bret Pettichord <bret at pettichord.com> wrote:
>
> On 7/10/07, Paul Rogers <paul.rogers at shaw.ca> wrote:
> >
> > how about pulling the modal_dialog support into a seperate entity ( gem,
> > plug in what ever) and letting people who use that decide what version to
> > use.
>
>
> This is an interesting suggestion. I guess it would help make people aware
> of what has a separate set of dependencies. I've also been thinking about
> making contrib a separate gem.
>
> That may also tie in well with my dialog support stuff Im trying to do.
> >
> > I guess one of the problems will be that people may not know they need
> > a certain version of ruby until they find they need to test modal dialogs,
> > and then they have to install that version, which is basically a pain - Ive
> > had to do this for rails compatability.
>
>
> My goal is to simplify using Watir for everyday users. What i don't know
> is how many users are using modal dialog support. I suppose making it be a
> separate gem would help give me some numbers.
>

I like the keep it simple idea as well, but keeping folks on
1.8.2-14indefinitely (as you suggest) isn't going to keep things
simple either. I
think it might be workable to give folks a simple tree of:

If you want to drive modal dialogs, install ruby 182-14, watir, and the
modal_dialog gem,
Else install the latest ruby and watir.

...Except, I wonder how many folks know what 'modal dialogs' mean, and might
be a bit paralyzed by indecision. So, if we start giving folks this choice,
I'd also want to give folks a good heuristic to figure out if they currently
need to drive modal dialogs.

Maybe that heuristic would be an example page containing them? Maybe the
heuristic could be as simple as "If you don't know, ignore the modal
dialogs". I can't actually suggest a guideline because I still don't really
know what they are about myself (though I'd be curious to see an example of
one, if you know of a publicly viewable one). Perhaps if it's easier to
teach me than to document it, I could do the documenting...but I again don't
know enough to suggest that that'd be the case.  ;0)

Jeff


-- 
http://testingjeff.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-development/attachments/20070710/084ba077/attachment-0001.html 

From zeljko.filipin at gmail.com  Wed Jul 11 11:09:45 2007
From: zeljko.filipin at gmail.com (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Wed, 11 Jul 2007 17:09:45 +0200
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <04dc01c7c353$b348c0e0$6400a8c0@laptop>
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
	<ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
	<970956b0707101647i7cc3cee7oe2fb300aa4491da5@mail.gmail.com>
	<04dc01c7c353$b348c0e0$6400a8c0@laptop>
Message-ID: <f81b1250707110809j4c57c9aat71a44b6159963935@mail.gmail.com>

On 7/11/07, Paul Rogers <paul.rogers at shaw.ca> wrote:
>
>  this doc may help. Its what I started a few days ago to help understand
> the different types of windows/dialogs and how to access them
>

Paul,

This is great. I would like to see this at our wiki. Would you put it there?

Zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-development/attachments/20070711/78a6de06/attachment.html 

From bret at pettichord.com  Wed Jul 11 13:39:23 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 11 Jul 2007 12:39:23 -0500
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <f81b1250707110809j4c57c9aat71a44b6159963935@mail.gmail.com>
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
	<ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
	<970956b0707101647i7cc3cee7oe2fb300aa4491da5@mail.gmail.com>
	<04dc01c7c353$b348c0e0$6400a8c0@laptop>
	<f81b1250707110809j4c57c9aat71a44b6159963935@mail.gmail.com>
Message-ID: <ade75c5b0707111039u71220edaqf72ce9eb26402fa3@mail.gmail.com>

On 7/11/07, ?eljko Filipin <zeljko.filipin at gmail.com> wrote:
>
> On 7/11/07, Paul Rogers <paul.rogers at shaw.ca> wrote:
> >
> >  this doc may help. Its what I started a few days ago to help understand
> > the different types of windows/dialogs and how to access them
> >
>
> Paul,
>
> This is great. I would like to see this at our wiki. Would you put it
> there?
>

+1. I would really like to see this published.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-development/attachments/20070711/d741e83e/attachment.html 

From paul.rogers at shaw.ca  Tue Jul 10 20:37:43 2007
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Tue, 10 Jul 2007 18:37:43 -0600
Subject: [Wtr-development] Recommended version of Ruby]
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
	<ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
	<970956b0707101647i7cc3cee7oe2fb300aa4491da5@mail.gmail.com>
Message-ID: <04dc01c7c353$b348c0e0$6400a8c0@laptop>

this doc may help. Its what I started a few days ago to help understand the different types of windows/dialogs and how to access them

Paul
  ----- Original Message ----- 
  From: Jeff Fry 
  To: Bret Pettichord 
  Cc: Paul Rogers ; wtr-development at rubyforge.org ; Charley Baker ; Zeljko Filipin 
  Sent: Tuesday, July 10, 2007 5:47 PM
  Subject: Re: Recommended version of Ruby]





  On 7/10/07, Bret Pettichord <bret at pettichord.com> wrote:
    On 7/10/07, Paul Rogers <paul.rogers at shaw.ca> wrote: 
      how about pulling the modal_dialog support into a seperate entity ( gem, plug in what ever) and letting people who use that decide what version to use.

    This is an interesting suggestion. I guess it would help make people aware of what has a separate set of dependencies. I've also been thinking about making contrib a separate gem. 



      That may also tie in well with my dialog support stuff Im trying to do. 

      I guess one of the problems will be that people may not know they need  a certain version of ruby until they find they need to test modal dialogs, and then they have to install that version, which is basically a pain - Ive had to do this for rails compatability. 

    My goal is to simplify using Watir for everyday users. What i don't know is how many users are using modal dialog support. I suppose making it be a separate gem would help give me some numbers. 

  I like the keep it simple idea as well, but keeping folks on 1.8.2-14 indefinitely (as you suggest) isn't going to keep things simple either. I think it might be workable to give folks a simple tree of: 

  If you want to drive modal dialogs, install ruby 182-14, watir, and the modal_dialog gem,
  Else install the latest ruby and watir.

  ...Except, I wonder how many folks know what 'modal dialogs' mean, and might be a bit paralyzed by indecision. So, if we start giving folks this choice, I'd also want to give folks a good heuristic to figure out if they currently need to drive modal dialogs. 

  Maybe that heuristic would be an example page containing them? Maybe the heuristic could be as simple as "If you don't know, ignore the modal dialogs". I can't actually suggest a guideline because I still don't really know what they are about myself (though I'd be curious to see an example of one, if you know of a publicly viewable one). Perhaps if it's easier to teach me than to document it, I could do the documenting...but I again don't know enough to suggest that that'd be the case.  ;0) 

  Jeff



  -- 
  http://testingjeff.wordpress.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-development/attachments/20070710/fea2f5dc/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dialogs.doc
Type: application/msword
Size: 278016 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/wtr-development/attachments/20070710/fea2f5dc/attachment-0001.doc 

From charley.baker at gmail.com  Wed Jul 11 13:54:00 2007
From: charley.baker at gmail.com (Charley Baker)
Date: Wed, 11 Jul 2007 11:54:00 -0600
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <f81b1250707110809j4c57c9aat71a44b6159963935@mail.gmail.com>
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
	<ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
	<970956b0707101647i7cc3cee7oe2fb300aa4491da5@mail.gmail.com>
	<04dc01c7c353$b348c0e0$6400a8c0@laptop>
	<f81b1250707110809j4c57c9aat71a44b6159963935@mail.gmail.com>
Message-ID: <f96821860707111054r552be60bnef169ee57fc7d9c4@mail.gmail.com>

  I'm unfortunately in the position of having to use modal dialog quite a
lot for one of our 3rd party applications which can open up to 8 or more
modals. I've got everyone on ruby 1.8.2-15 which was the last release
1.8.2one click installer. I took a look at the code for the modal
dialog, and
just haven't had the time to make this a priority to dig into since it
currently works.

  While I don't want to lose this support, given the current state of this
feature and the requirement on Ruby 1.8.2, I think a separate gem and moving
that code out makes sense, the dialog functionality in general needs some
work - modal, javascript, proxy, security dialogs, etc.

 Ideally we need some way to encapsulate the dialogs and make them somewhat
more transparent in the longer term roadmap.

Nice job on the document Paul, not only should it help users out but also
gives a clear, concise picture of the various dialog classifications that we
need to contend with.

 I'd second or third the others and say this is something that we should
publish on the site. It belongs in the category of 'doh, i should have
thought of that.'

-Charley

On 7/11/07, ?eljko Filipin <zeljko.filipin at gmail.com> wrote:
>
> On 7/11/07, Paul Rogers <paul.rogers at shaw.ca> wrote:
> >
> >  this doc may help. Its what I started a few days ago to help understand
> > the different types of windows/dialogs and how to access them
> >
>
> Paul,
>
> This is great. I would like to see this at our wiki. Would you put it
> there?
>
> Zeljko
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-development/attachments/20070711/49ba910b/attachment.html 

From Mark_Cain at RL.gov  Wed Jul 11 13:40:58 2007
From: Mark_Cain at RL.gov (Cain, Mark)
Date: Wed, 11 Jul 2007 10:40:58 -0700
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <4693C1D8.8090305@pettichord.com>
References: <4693C1D8.8090305@pettichord.com>
Message-ID: <74805676EA7D9243BDF45D637BAD341067D9C5@EX01-3.rl.gov>

Do you have a timeline on when the lasted version of ruby will be
supported? 


--Mark


-----Original Message-----
From: wtr-development-bounces at rubyforge.org
[mailto:wtr-development-bounces at rubyforge.org] On Behalf Of Bret
Pettichord
Sent: Tuesday, July 10, 2007 10:29 AM
To: wtr-development at rubyforge.org
Cc: Paul Rogers
Subject: [Wtr-development] Recommended version of Ruby]

(I posted this to wtr-general by mistake. I intended to post it here.)

What version of Ruby should we recommend?

After a recent discussion we agreed that the rdoc (readme.rb) should
read:

   Best is to use Ruby 1.8.2-14 or later.
   However, if you are using the Watir::IE#modal_dialog method, you must
use Ruby 1.8.2-14 and not a more recent version.
   Watir (in general) will not work with Ruby 1.8.1-13. (This version of
Ruby has a bad WIN32OLE library.)

I revised this recommendation to this thus in the new (unpublished)
website:

    First you need to "install
    Ruby":http://rubyforge.org/frs/?group_id=167 using
    the one-click installer for Windows.
    *We recommend Ruby 1.8.2-14 or later.*

    However, if you wish to use Watir's support for the *IE web modal
    dialog*
    then you "must use Ruby
    1.8.2-14":http://wiki.openqa.org/display/WTR/Installation
    and not a more recent version. This dialog is
    posted with the showModalDialog() JavaScript command and is
    supported with Watir's
    ie.modal_dialog command.

However, the wiki page for installing recommends 1.8.2-14 for everyone.
    http://wiki.openqa.org/display/WTR/Install+Ruby

I was surprised when i found this and started a discussion with Zeljko
on the page, but thought the issue might be of more general interest.

Personally, i think that people should be using the latest generally
available version of Ruby. There continue to be improvements with it. 
For example I recently reported several Ruby bugs that interfered with
integrating Watir with Cruise Control. 
http://www.io.com/~wazmo/blog/archives/2007_04.html. At this point, we
see problems in both 1.8.5 and 1.8.6, but expect that 1.8.7 will have
these problems fixed and will be encouraging a move there when it
happens.

Should our recommendation for newer versions of Ruby be more emphatic?

Another question regards the modal dialog support. I don't know if the
community understands that at this point i am abandoning this
functionality. I would love to see someone take it over and make it so
that it was dependent on a specific version of Ruby. But i don't expect
that to happen. But we can't allow this to say that all users should
stick with 1.8.2 until the end of time.

For example, rubygems in 1.8.2 does not support the --install-depencies
argument, which makes installing via gem much more complicated (esp. 
when i publish the gem to rubyforge.org). So once this is done, i will
probably be telling people NOT to use 1.8.2, because i think it is more
important to make our install instructions simple. We can have alternate
instructions for the people who need the modal_dialog support.

I'd appreciate your thoughts and questions.

Bret



_______________________________________________
Wtr-general mailing list
Wtr-general at rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general

_______________________________________________
Wtr-development mailing list
Wtr-development at rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-development

From charley.baker at gmail.com  Wed Jul 11 14:47:01 2007
From: charley.baker at gmail.com (Charley Baker)
Date: Wed, 11 Jul 2007 12:47:01 -0600
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <74805676EA7D9243BDF45D637BAD341067D9C5@EX01-3.rl.gov>
References: <4693C1D8.8090305@pettichord.com>
	<74805676EA7D9243BDF45D637BAD341067D9C5@EX01-3.rl.gov>
Message-ID: <f96821860707111147y6c77f9cchaa0298f154f9447b@mail.gmail.com>

You could theoretically recompile the library extensions against the latest
version of Ruby. I haven't tried and you're kind of on your own on that one.
I've had to backwards compile the wmq library with 1.8.2 to support mq6.
Otherwise vote on jira: http://jira.openqa.org/browse/WTR-1

I seem to be one of the few heavy users of the modal dialogs and should
likely own this. Timeline is tbd, dependent on my time which has been
minimal for quite some time. If you want to chip in and have some
suggestions around this area, I'd be all too happy to work with you. ;)

-c

On 7/11/07, Cain, Mark <Mark_Cain at rl.gov> wrote:
>
> Do you have a timeline on when the lasted version of ruby will be
> supported?
>
>
> --Mark
>
>
> -----Original Message-----
> From: wtr-development-bounces at rubyforge.org
> [mailto:wtr-development-bounces at rubyforge.org] On Behalf Of Bret
> Pettichord
> Sent: Tuesday, July 10, 2007 10:29 AM
> To: wtr-development at rubyforge.org
> Cc: Paul Rogers
> Subject: [Wtr-development] Recommended version of Ruby]
>
> (I posted this to wtr-general by mistake. I intended to post it here.)
>
> What version of Ruby should we recommend?
>
> After a recent discussion we agreed that the rdoc (readme.rb) should
> read:
>
>    Best is to use Ruby 1.8.2-14 or later.
>    However, if you are using the Watir::IE#modal_dialog method, you must
> use Ruby 1.8.2-14 and not a more recent version.
>    Watir (in general) will not work with Ruby 1.8.1-13. (This version of
> Ruby has a bad WIN32OLE library.)
>
> I revised this recommendation to this thus in the new (unpublished)
> website:
>
>     First you need to "install
>     Ruby":http://rubyforge.org/frs/?group_id=167 using
>     the one-click installer for Windows.
>     *We recommend Ruby 1.8.2-14 or later.*
>
>     However, if you wish to use Watir's support for the *IE web modal
>     dialog*
>     then you "must use Ruby
>     1.8.2-14":http://wiki.openqa.org/display/WTR/Installation
>     and not a more recent version. This dialog is
>     posted with the showModalDialog() JavaScript command and is
>     supported with Watir's
>     ie.modal_dialog command.
>
> However, the wiki page for installing recommends 1.8.2-14 for everyone.
>     http://wiki.openqa.org/display/WTR/Install+Ruby
>
> I was surprised when i found this and started a discussion with Zeljko
> on the page, but thought the issue might be of more general interest.
>
> Personally, i think that people should be using the latest generally
> available version of Ruby. There continue to be improvements with it.
> For example I recently reported several Ruby bugs that interfered with
> integrating Watir with Cruise Control.
> http://www.io.com/~wazmo/blog/archives/2007_04.html. At this point, we
> see problems in both 1.8.5 and 1.8.6, but expect that 1.8.7 will have
> these problems fixed and will be encouraging a move there when it
> happens.
>
> Should our recommendation for newer versions of Ruby be more emphatic?
>
> Another question regards the modal dialog support. I don't know if the
> community understands that at this point i am abandoning this
> functionality. I would love to see someone take it over and make it so
> that it was dependent on a specific version of Ruby. But i don't expect
> that to happen. But we can't allow this to say that all users should
> stick with 1.8.2 until the end of time.
>
> For example, rubygems in 1.8.2 does not support the --install-depencies
> argument, which makes installing via gem much more complicated (esp.
> when i publish the gem to rubyforge.org). So once this is done, i will
> probably be telling people NOT to use 1.8.2, because i think it is more
> important to make our install instructions simple. We can have alternate
> instructions for the people who need the modal_dialog support.
>
> I'd appreciate your thoughts and questions.
>
> Bret
>
>
>
> _______________________________________________
> Wtr-general mailing list
> Wtr-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-general
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-development/attachments/20070711/8abe18a6/attachment.html 

From bret at pettichord.com  Tue Jul 24 18:35:32 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 24 Jul 2007 17:35:32 -0500
Subject: [Wtr-development] Fwd: speeding up Watir to beat Rational
	Functional Tester
In-Reply-To: <20070724210924.5482.qmail@ns6.webmasters.com>
References: <20070724210924.5482.qmail@ns6.webmasters.com>
Message-ID: <ade75c5b0707241535x4855d455jf1ebad0fde7d49c4@mail.gmail.com>

This concept looks pretty worthwhile to me. Comments? I want to think about
the names for the new methods.

Bret

---------- Forwarded message ----------
From: jonathan at kohl.ca <jonathan at kohl.ca>
Date: 24 Jul 2007 21:09:24 -0000
Subject: speeding up Watir to beat Rational Functional Tester
To: bret at pettichord.com

Hi Bret;

So far, even running Watir 1.5 in fast mode on this application is about the
same speed as RFT. I added a new method "set_fast" that just sets the entire
value in a text field, and it is now blazing fast. Also, I needed to not
have the JS events fire because they tend to cause a layer to appear that
changes as you type. This speed issue is a sticking point, but this hack
seems to work.

Here is a very simple test excerpt(assertions fail, and the data handling
variable section needs to be refactored out and improved, I need to do more
work.)

Here is what the code looks like so far in my proof of concept. So far, the
script runs very quickly compared to RFT.

Thanks;

-Jonathan

require 'watir'
require 'watir/testcase'
require 'watir/performance_helper'

class TC_Booking_Engine < Watir::TestCase

     $ie = Watir::IE.new
     time = Time.now
     tomorrow = time + 86400
     next_month =  time + 2592000
     @@date_depart = tomorrow.strftime("%d")
     @@month_depart = tomorrow.strftime("%m")
     @@date_return = tomorrow.strftime("%d")
     @@month_return = next_month.strftime("%m")
     @@test_site = "http://www.westjet.com/index_en.html"

  def test_step_one

    $ie.goto(@@test_site)
    $ie.text_field(:id, "origin1").set_fast("Calgary, AB (YYC)")
    $ie.text_field(:id, "destination1").set_fast("Victoria, BC (YYJ)")
    $ie.text_field(:name, "departDay1_day").set_fast(@@date_depart)
    $ie.text_field(:name, "departMonth1_month").set_fast(@@month_depart)
    $ie.text_field(:name, "departDay2_day").set_fast(@@date_return)
    $ie.text_field(:name, "departMonth2_month").set_fast(@@month_return)
    $ie.button(:value, "Get Flights").click
    assert($ie.contains_text("/Departing/"))
  end

  def test_step_two
    $ie.radio(:index, 4).set
    $ie.radio(:index, 9).set
    $ie.button(:value, "Continue >").click
    assert($ie.contains_text("/Who is Booking?/"))
  end

end

Here is what performance helper looks like:
require 'watir'

module Watir

  class RadioCheckCommon
       def set
           assert_enabled
           highlight(:set)
           @o.scrollIntoView #this is missing in Watir.rb and
                             # bothered users
           set_clear_item(true)
           highlight(:clear)
         end

       end

  class TextField

    #no fire events, and the entire string is set at once
    def set_fast(setThis)
      assert_enabled
      assert_not_readonly
      highlight(:set)
      @o.scrollIntoView
      @o.focus
      @o.select
      @o.value = setThis.to_s
      highlight(:clear)
    end

  end

end
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-development/attachments/20070724/cbb594c9/attachment-0001.html 

From bret at pettichord.com  Tue Jul 31 11:11:07 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 31 Jul 2007 10:11:07 -0500
Subject: [Wtr-development] performance slow down with 1.5.1.1192 gem
In-Reply-To: <1185894273.649334.281350@b79g2000hse.googlegroups.com>
References: <1185482663.554176.306420@d55g2000hsg.googlegroups.com>
	<46AA0429.9050109@pettichord.com>
	<1185894273.649334.281350@b79g2000hse.googlegroups.com>
Message-ID: <ade75c5b0707310811n13eeff57tda3b573350a7a53c@mail.gmail.com>

That would be great. This is a big concern for me. We are about ready to
release 1.5 to rubyforge but don't want to see performance problems.

Bret

On 7/31/07, sbalek <shyamala98 at gmail.com> wrote:
>
> I will try to make a small test case of my html that I can send in.
>
> On Jul 27, 10:41 am, Bret Pettichord <b... at pettichord.com> wrote:
> > sbalek wrote:
> > > My test initializes a few text fields on a page that trigger
> > > javascript execution. The performace was pretty good in watir 1.4.1. I
> > > uninstalled it and installed watir 1.5.1.1192 gem and the test took
> > > for ever.
> > > I reverted back to 1.4.1 and the test executes just fine.
> >
> > > Anyone seen this?
> >
> > If you can show us an example, that would help us a lot in understanding
> > the possible causes.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wtr-development/attachments/20070731/427564a3/attachment.html 

From bret at pettichord.com  Tue Jul 10 00:55:51 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 09 Jul 2007 23:55:51 -0500
Subject: [Wtr-development] Updates
Message-ID: <46931157.9040900@pettichord.com>

I am currently working on a new website for wtr.rubyforge.org -- a new 
set of pages that are up to date and provide more detail than what is 
available. I realize that this addresses a long-standing complaint.

I have been committing my work in progress to 
https://svn.openqa.org/svn/watir/trunk/doc. I plan to post them to 
wtr.rubyforge.org as soon as they are clearly no worse (i.e. no more out 
of date) than what is presently there. You are welcome to review and 
comment on the work in progress. You can read the *.page files yourself 
-- they are in textile, and easy to read markup language. You can also 
install webgen and the build the pages yourself if you want to see them.

My goal is mostly to provide pointers to the most current information 
that is available. I appreciate your help in this regard in particular, 
that is in publishing so much information about Watir.

In the process of doing this, i am uncovering discrepancies and 
inconsistencies that I feel should be discussed. I will be using this 
list (wtr-development) for this discussion and I hope that those of you 
who i have cc'd are reading this list.

Some specific concerns follow shortly.

I have also sent an invite to the members of wtr-general to join the new 
group at google. However, this invitation has been rerouted to the spam 
police at google and i fear it may not be released. So a more indirect 
invitation directly to wtr-general may be in order. I appreciate your 
help with this migration.

Bret




From paul.rogers at shaw.ca  Tue Jul 10 11:28:10 2007
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Tue, 10 Jul 2007 09:28:10 -0600
Subject: [Wtr-development] Updates
In-Reply-To: <46931157.9040900@pettichord.com>
References: <46931157.9040900@pettichord.com>
Message-ID: <cc71fd86ac9c.4693512a@shaw.ca>

this seems like an appropriate time for what I have been doing....

I was hoping to get a lot of work done on a couple of things - a 'rails-like' interface to watir that I think makes more readable code. Ive been using a modified form of it at work for a while and Im mostly pleased. I expect it will be an addon done via contrib or a different project.

Ive also been looking at the dialog ( file downloads, security alerts etc) but really didnt get much done. What I have done however is produce a doc that currently explains all the dialogs, and sample javascript of what produces them. Im then going to get the 'current' way of dealing with them in, and then hopefully come up with a better winclicker ( or whatever )

Paul

----- Original Message -----
From: Bret Pettichord <bret at pettichord.com>
Date: Monday, July 9, 2007 10:58 pm
Subject: Updates
To: wtr-development at rubyforge.org
Cc: Charley Baker <charley.baker at gmail.com>, Jeff Fry <jeff.fry at gmail.com>, Zeljko Filipin <zeljko.filipin at gmail.com>, Paul Rogers <paul.rogers at shaw.ca>

> I am currently working on a new website for wtr.rubyforge.org -- 
> a new 
> set of pages that are up to date and provide more detail than 
> what is 
> available. I realize that this addresses a long-standing complaint.
> 
> I have been committing my work in progress to 
> https://svn.openqa.org/svn/watir/trunk/doc. I plan to post them 
> to 
> wtr.rubyforge.org as soon as they are clearly no worse (i.e. no 
> more out 
> of date) than what is presently there. You are welcome to review 
> and 
> comment on the work in progress. You can read the *.page files 
> yourself 
> -- they are in textile, and easy to read markup language. You 
> can also 
> install webgen and the build the pages yourself if you want to 
> see them.
> 
> My goal is mostly to provide pointers to the most current 
> information 
> that is available. I appreciate your help in this regard in 
> particular, 
> that is in publishing so much information about Watir.
> 
> In the process of doing this, i am uncovering discrepancies and 
> inconsistencies that I feel should be discussed. I will be using 
> this 
> list (wtr-development) for this discussion and I hope that those 
> of you 
> who i have cc'd are reading this list.
> 
> Some specific concerns follow shortly.
> 
> I have also sent an invite to the members of wtr-general to join 
> the new 
> group at google. However, this invitation has been rerouted to 
> the spam 
> police at google and i fear it may not be released. So a more 
> indirect 
> invitation directly to wtr-general may be in order. I appreciate 
> your 
> help with this migration.
> 
> Bret
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070710/0a39e777/attachment-0002.html>

From bret at pettichord.com  Tue Jul 10 13:28:56 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 10 Jul 2007 12:28:56 -0500
Subject: [Wtr-development] Recommended version of Ruby]
Message-ID: <4693C1D8.8090305@pettichord.com>

(I posted this to wtr-general by mistake. I intended to post it here.)

What version of Ruby should we recommend?

After a recent discussion we agreed that the rdoc (readme.rb) should read:

   Best is to use Ruby 1.8.2-14 or later.
   However, if you are using the Watir::IE#modal_dialog method, you must 
use Ruby 1.8.2-14 and not a more recent version.
   Watir (in general) will not work with Ruby 1.8.1-13. (This version of 
Ruby has a bad WIN32OLE library.)

I revised this recommendation to this thus in the new (unpublished) website:

    First you need to "install
    Ruby":http://rubyforge.org/frs/?group_id=167 using
    the one-click installer for Windows.
    *We recommend Ruby 1.8.2-14 or later.*

    However, if you wish to use Watir's support for the *IE web modal
    dialog*
    then you "must use Ruby
    1.8.2-14":http://wiki.openqa.org/display/WTR/Installation
    and not a more recent version. This dialog is
    posted with the showModalDialog() JavaScript command and is
    supported with Watir's
    ie.modal_dialog command.

However, the wiki page for installing recommends 1.8.2-14 for everyone.
    http://wiki.openqa.org/display/WTR/Install+Ruby

I was surprised when i found this and started a discussion with Zeljko 
on the page, but thought the issue might be of more general interest.

Personally, i think that people should be using the latest generally 
available version of Ruby. There continue to be improvements with it. 
For example I recently reported several Ruby bugs that interfered with 
integrating Watir with Cruise Control. 
http://www.io.com/~wazmo/blog/archives/2007_04.html. At this point, we 
see problems in both 1.8.5 and 1.8.6, but expect that 1.8.7 will have 
these problems fixed and will be encouraging a move there when it happens.

Should our recommendation for newer versions of Ruby be more emphatic?

Another question regards the modal dialog support. I don't know if the 
community understands that at this point i am abandoning this 
functionality. I would love to see someone take it over and make it so 
that it was dependent on a specific version of Ruby. But i don't expect 
that to happen. But we can't allow this to say that all users should 
stick with 1.8.2 until the end of time.

For example, rubygems in 1.8.2 does not support the --install-depencies 
argument, which makes installing via gem much more complicated (esp. 
when i publish the gem to rubyforge.org). So once this is done, i will 
probably be telling people NOT to use 1.8.2, because i think it is more 
important to make our install instructions simple. We can have alternate 
instructions for the people who need the modal_dialog support.

I'd appreciate your thoughts and questions.

Bret



_______________________________________________
Wtr-general mailing list
Wtr-general at rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general



From paul.rogers at shaw.ca  Tue Jul 10 13:59:07 2007
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Tue, 10 Jul 2007 11:59:07 -0600
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <4693C1D8.8090305@pettichord.com>
References: <4693C1D8.8090305@pettichord.com>
Message-ID: <ccbeb17af70e.4693748b@shaw.ca>

how about pulling the modal_dialog support into a seperate entity ( gem, plug in what ever) and letting people who use that decide what version to use.
That may also tie in well with my dialog support stuff Im trying to do.

I guess one of the problems will be that people may not know they need? a certain version of ruby until they find they need to test modal dialogs, and then they have to install that version, which is basically a pain - Ive had to do this for rails compatability.

Was there a typo in your original post - you said 
" I would love to see someone take it over and make? it so? that it was dependent on a specific version of Ruby"

but did you mean ?
" I would love to see someone take it over and make? it so? that it was INDEPENDANT on a specific version of Ruby"



Paul


----- Original Message -----
From: Bret Pettichord <bret at pettichord.com>
Date: Tuesday, July 10, 2007 11:32 am
Subject: Recommended version of Ruby]
To: wtr-development at rubyforge.org
Cc: Paul Rogers <paul.rogers at shaw.ca>, Charley Baker <charley.baker at gmail.com>, Zeljko Filipin <zeljko.filipin at gmail.com>, Jeff Fry <jeff.fry at gmail.com>

> (I posted this to wtr-general by mistake. I intended to post it here.)
> 
> What version of Ruby should we recommend?
> 
> After a recent discussion we agreed that the rdoc (readme.rb) 
> should read:
> 
> ?? Best is to use Ruby 1.8.2-14 or later.
> ?? However, if you are using the 
> Watir::IE#modal_dialog method, you must 
> use Ruby 1.8.2-14 and not a more recent version.
> ?? Watir (in general) will not work with Ruby 1.8.1-
> 13. (This version of 
> Ruby has a bad WIN32OLE library.)
> 
> I revised this recommendation to this thus in the new 
> (unpublished) website:
> 
> ??? First you need to "install
> ??? Ruby":http://rubyforge.org/frs/?group_id=167 using
> ??? the one-click installer for Windows.
> ??? *We recommend Ruby 1.8.2-14 or later.*
> 
> ??? However, if you wish to use Watir's support 
> for the *IE web modal
> ??? dialog*
> ??? then you "must use Ruby
> ??? 1.8.2-
> 14":http://wiki.openqa.org/display/WTR/Installation??? and not a more recent version. This dialog is
> ??? posted with the showModalDialog() JavaScript 
> command and is
> ??? supported with Watir's
> ??? ie.modal_dialog command.
> 
> However, the wiki page for installing recommends 1.8.2-14 for 
> everyone.??? 
> http://wiki.openqa.org/display/WTR/Install+Ruby
> I was surprised when i found this and started a discussion with 
> Zeljko 
> on the page, but thought the issue might be of more general interest.
> 
> Personally, i think that people should be using the latest 
> generally 
> available version of Ruby. There continue to be improvements 
> with it. 
> For example I recently reported several Ruby bugs that 
> interfered with 
> integrating Watir with Cruise Control. 
> http://www.io.com/~wazmo/blog/archives/2007_04.html. At this 
> point, we 
> see problems in both 1.8.5 and 1.8.6, but expect that 1.8.7 will 
> have 
> these problems fixed and will be encouraging a move there when 
> it happens.
> 
> Should our recommendation for newer versions of Ruby be more emphatic?
> 
> Another question regards the modal dialog support. I don't know 
> if the 
> community understands that at this point i am abandoning this 
> functionality. I would love to see someone take it over and make 
> it so 
> that it was dependent on a specific version of Ruby. But i don't 
> expect 
> that to happen. But we can't allow this to say that all users 
> should 
> stick with 1.8.2 until the end of time.
> 
> For example, rubygems in 1.8.2 does not support the --install-
> depencies 
> argument, which makes installing via gem much more complicated 
> (esp. 
> when i publish the gem to rubyforge.org). So once this is done, 
> i will 
> probably be telling people NOT to use 1.8.2, because i think it 
> is more 
> important to make our install instructions simple. We can have 
> alternate 
> instructions for the people who need the modal_dialog support.
> 
> I'd appreciate your thoughts and questions.
> 
> Bret
> 
> 
> 
> _______________________________________________
> Wtr-general mailing list
> Wtr-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-general
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070710/9ece9250/attachment-0002.html>

From bret at pettichord.com  Tue Jul 10 14:44:31 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 10 Jul 2007 13:44:31 -0500
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <ccbeb17af70e.4693748b@shaw.ca>
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
Message-ID: <ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>

On 7/10/07, Paul Rogers <paul.rogers at shaw.ca> wrote:
>
> how about pulling the modal_dialog support into a seperate entity ( gem,
> plug in what ever) and letting people who use that decide what version to
> use.


This is an interesting suggestion. I guess it would help make people aware
of what has a separate set of dependencies. I've also been thinking about
making contrib a separate gem.

That may also tie in well with my dialog support stuff Im trying to do.
>
> I guess one of the problems will be that people may not know they need  a
> certain version of ruby until they find they need to test modal dialogs, and
> then they have to install that version, which is basically a pain - Ive had
> to do this for rails compatability.


My goal is to simplify using Watir for everyday users. What i don't know is
how many users are using modal dialog support. I suppose making it be a
separate gem would help give me some numbers.

Was there a typo in your original post - you said
> " I would love to see someone take it over and make  it so  that it was
> dependent on a specific version of Ruby"
>
> but did you mean ?
> " I would love to see someone take it over and make  it so  that it was
> INDEPENDANT on a specific version of Ruby"


Exactly.  Sorry for the confusion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070710/fc44cfe3/attachment-0002.html>

From jeff.fry at gmail.com  Tue Jul 10 19:47:35 2007
From: jeff.fry at gmail.com (Jeff Fry)
Date: Tue, 10 Jul 2007 16:47:35 -0700
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
	<ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
Message-ID: <970956b0707101647i7cc3cee7oe2fb300aa4491da5@mail.gmail.com>

On 7/10/07, Bret Pettichord <bret at pettichord.com> wrote:
>
> On 7/10/07, Paul Rogers <paul.rogers at shaw.ca> wrote:
> >
> > how about pulling the modal_dialog support into a seperate entity ( gem,
> > plug in what ever) and letting people who use that decide what version to
> > use.
>
>
> This is an interesting suggestion. I guess it would help make people aware
> of what has a separate set of dependencies. I've also been thinking about
> making contrib a separate gem.
>
> That may also tie in well with my dialog support stuff Im trying to do.
> >
> > I guess one of the problems will be that people may not know they need
> > a certain version of ruby until they find they need to test modal dialogs,
> > and then they have to install that version, which is basically a pain - Ive
> > had to do this for rails compatability.
>
>
> My goal is to simplify using Watir for everyday users. What i don't know
> is how many users are using modal dialog support. I suppose making it be a
> separate gem would help give me some numbers.
>

I like the keep it simple idea as well, but keeping folks on
1.8.2-14indefinitely (as you suggest) isn't going to keep things
simple either. I
think it might be workable to give folks a simple tree of:

If you want to drive modal dialogs, install ruby 182-14, watir, and the
modal_dialog gem,
Else install the latest ruby and watir.

...Except, I wonder how many folks know what 'modal dialogs' mean, and might
be a bit paralyzed by indecision. So, if we start giving folks this choice,
I'd also want to give folks a good heuristic to figure out if they currently
need to drive modal dialogs.

Maybe that heuristic would be an example page containing them? Maybe the
heuristic could be as simple as "If you don't know, ignore the modal
dialogs". I can't actually suggest a guideline because I still don't really
know what they are about myself (though I'd be curious to see an example of
one, if you know of a publicly viewable one). Perhaps if it's easier to
teach me than to document it, I could do the documenting...but I again don't
know enough to suggest that that'd be the case.  ;0)

Jeff


-- 
http://testingjeff.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070710/084ba077/attachment-0002.html>

From zeljko.filipin at gmail.com  Wed Jul 11 11:09:45 2007
From: zeljko.filipin at gmail.com (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Wed, 11 Jul 2007 17:09:45 +0200
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <04dc01c7c353$b348c0e0$6400a8c0@laptop>
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
	<ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
	<970956b0707101647i7cc3cee7oe2fb300aa4491da5@mail.gmail.com>
	<04dc01c7c353$b348c0e0$6400a8c0@laptop>
Message-ID: <f81b1250707110809j4c57c9aat71a44b6159963935@mail.gmail.com>

On 7/11/07, Paul Rogers <paul.rogers at shaw.ca> wrote:
>
>  this doc may help. Its what I started a few days ago to help understand
> the different types of windows/dialogs and how to access them
>

Paul,

This is great. I would like to see this at our wiki. Would you put it there?

Zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070711/78a6de06/attachment-0002.html>

From bret at pettichord.com  Wed Jul 11 13:39:23 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 11 Jul 2007 12:39:23 -0500
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <f81b1250707110809j4c57c9aat71a44b6159963935@mail.gmail.com>
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
	<ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
	<970956b0707101647i7cc3cee7oe2fb300aa4491da5@mail.gmail.com>
	<04dc01c7c353$b348c0e0$6400a8c0@laptop>
	<f81b1250707110809j4c57c9aat71a44b6159963935@mail.gmail.com>
Message-ID: <ade75c5b0707111039u71220edaqf72ce9eb26402fa3@mail.gmail.com>

On 7/11/07, ?eljko Filipin <zeljko.filipin at gmail.com> wrote:
>
> On 7/11/07, Paul Rogers <paul.rogers at shaw.ca> wrote:
> >
> >  this doc may help. Its what I started a few days ago to help understand
> > the different types of windows/dialogs and how to access them
> >
>
> Paul,
>
> This is great. I would like to see this at our wiki. Would you put it
> there?
>

+1. I would really like to see this published.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070711/d741e83e/attachment-0002.html>

From paul.rogers at shaw.ca  Tue Jul 10 20:37:43 2007
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Tue, 10 Jul 2007 18:37:43 -0600
Subject: [Wtr-development] Recommended version of Ruby]
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
	<ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
	<970956b0707101647i7cc3cee7oe2fb300aa4491da5@mail.gmail.com>
Message-ID: <04dc01c7c353$b348c0e0$6400a8c0@laptop>

this doc may help. Its what I started a few days ago to help understand the different types of windows/dialogs and how to access them

Paul
  ----- Original Message ----- 
  From: Jeff Fry 
  To: Bret Pettichord 
  Cc: Paul Rogers ; wtr-development at rubyforge.org ; Charley Baker ; Zeljko Filipin 
  Sent: Tuesday, July 10, 2007 5:47 PM
  Subject: Re: Recommended version of Ruby]





  On 7/10/07, Bret Pettichord <bret at pettichord.com> wrote:
    On 7/10/07, Paul Rogers <paul.rogers at shaw.ca> wrote: 
      how about pulling the modal_dialog support into a seperate entity ( gem, plug in what ever) and letting people who use that decide what version to use.

    This is an interesting suggestion. I guess it would help make people aware of what has a separate set of dependencies. I've also been thinking about making contrib a separate gem. 



      That may also tie in well with my dialog support stuff Im trying to do. 

      I guess one of the problems will be that people may not know they need  a certain version of ruby until they find they need to test modal dialogs, and then they have to install that version, which is basically a pain - Ive had to do this for rails compatability. 

    My goal is to simplify using Watir for everyday users. What i don't know is how many users are using modal dialog support. I suppose making it be a separate gem would help give me some numbers. 

  I like the keep it simple idea as well, but keeping folks on 1.8.2-14 indefinitely (as you suggest) isn't going to keep things simple either. I think it might be workable to give folks a simple tree of: 

  If you want to drive modal dialogs, install ruby 182-14, watir, and the modal_dialog gem,
  Else install the latest ruby and watir.

  ...Except, I wonder how many folks know what 'modal dialogs' mean, and might be a bit paralyzed by indecision. So, if we start giving folks this choice, I'd also want to give folks a good heuristic to figure out if they currently need to drive modal dialogs. 

  Maybe that heuristic would be an example page containing them? Maybe the heuristic could be as simple as "If you don't know, ignore the modal dialogs". I can't actually suggest a guideline because I still don't really know what they are about myself (though I'd be curious to see an example of one, if you know of a publicly viewable one). Perhaps if it's easier to teach me than to document it, I could do the documenting...but I again don't know enough to suggest that that'd be the case.  ;0) 

  Jeff



  -- 
  http://testingjeff.wordpress.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070710/fea2f5dc/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dialogs.doc
Type: application/msword
Size: 278016 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070710/fea2f5dc/attachment-0002.doc>

From charley.baker at gmail.com  Wed Jul 11 13:54:00 2007
From: charley.baker at gmail.com (Charley Baker)
Date: Wed, 11 Jul 2007 11:54:00 -0600
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <f81b1250707110809j4c57c9aat71a44b6159963935@mail.gmail.com>
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
	<ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
	<970956b0707101647i7cc3cee7oe2fb300aa4491da5@mail.gmail.com>
	<04dc01c7c353$b348c0e0$6400a8c0@laptop>
	<f81b1250707110809j4c57c9aat71a44b6159963935@mail.gmail.com>
Message-ID: <f96821860707111054r552be60bnef169ee57fc7d9c4@mail.gmail.com>

  I'm unfortunately in the position of having to use modal dialog quite a
lot for one of our 3rd party applications which can open up to 8 or more
modals. I've got everyone on ruby 1.8.2-15 which was the last release
1.8.2one click installer. I took a look at the code for the modal
dialog, and
just haven't had the time to make this a priority to dig into since it
currently works.

  While I don't want to lose this support, given the current state of this
feature and the requirement on Ruby 1.8.2, I think a separate gem and moving
that code out makes sense, the dialog functionality in general needs some
work - modal, javascript, proxy, security dialogs, etc.

 Ideally we need some way to encapsulate the dialogs and make them somewhat
more transparent in the longer term roadmap.

Nice job on the document Paul, not only should it help users out but also
gives a clear, concise picture of the various dialog classifications that we
need to contend with.

 I'd second or third the others and say this is something that we should
publish on the site. It belongs in the category of 'doh, i should have
thought of that.'

-Charley

On 7/11/07, ?eljko Filipin <zeljko.filipin at gmail.com> wrote:
>
> On 7/11/07, Paul Rogers <paul.rogers at shaw.ca> wrote:
> >
> >  this doc may help. Its what I started a few days ago to help understand
> > the different types of windows/dialogs and how to access them
> >
>
> Paul,
>
> This is great. I would like to see this at our wiki. Would you put it
> there?
>
> Zeljko
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070711/49ba910b/attachment-0002.html>

From Mark_Cain at RL.gov  Wed Jul 11 13:40:58 2007
From: Mark_Cain at RL.gov (Cain, Mark)
Date: Wed, 11 Jul 2007 10:40:58 -0700
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <4693C1D8.8090305@pettichord.com>
References: <4693C1D8.8090305@pettichord.com>
Message-ID: <74805676EA7D9243BDF45D637BAD341067D9C5@EX01-3.rl.gov>

Do you have a timeline on when the lasted version of ruby will be
supported? 


--Mark


-----Original Message-----
From: wtr-development-bounces at rubyforge.org
[mailto:wtr-development-bounces at rubyforge.org] On Behalf Of Bret
Pettichord
Sent: Tuesday, July 10, 2007 10:29 AM
To: wtr-development at rubyforge.org
Cc: Paul Rogers
Subject: [Wtr-development] Recommended version of Ruby]

(I posted this to wtr-general by mistake. I intended to post it here.)

What version of Ruby should we recommend?

After a recent discussion we agreed that the rdoc (readme.rb) should
read:

   Best is to use Ruby 1.8.2-14 or later.
   However, if you are using the Watir::IE#modal_dialog method, you must
use Ruby 1.8.2-14 and not a more recent version.
   Watir (in general) will not work with Ruby 1.8.1-13. (This version of
Ruby has a bad WIN32OLE library.)

I revised this recommendation to this thus in the new (unpublished)
website:

    First you need to "install
    Ruby":http://rubyforge.org/frs/?group_id=167 using
    the one-click installer for Windows.
    *We recommend Ruby 1.8.2-14 or later.*

    However, if you wish to use Watir's support for the *IE web modal
    dialog*
    then you "must use Ruby
    1.8.2-14":http://wiki.openqa.org/display/WTR/Installation
    and not a more recent version. This dialog is
    posted with the showModalDialog() JavaScript command and is
    supported with Watir's
    ie.modal_dialog command.

However, the wiki page for installing recommends 1.8.2-14 for everyone.
    http://wiki.openqa.org/display/WTR/Install+Ruby

I was surprised when i found this and started a discussion with Zeljko
on the page, but thought the issue might be of more general interest.

Personally, i think that people should be using the latest generally
available version of Ruby. There continue to be improvements with it. 
For example I recently reported several Ruby bugs that interfered with
integrating Watir with Cruise Control. 
http://www.io.com/~wazmo/blog/archives/2007_04.html. At this point, we
see problems in both 1.8.5 and 1.8.6, but expect that 1.8.7 will have
these problems fixed and will be encouraging a move there when it
happens.

Should our recommendation for newer versions of Ruby be more emphatic?

Another question regards the modal dialog support. I don't know if the
community understands that at this point i am abandoning this
functionality. I would love to see someone take it over and make it so
that it was dependent on a specific version of Ruby. But i don't expect
that to happen. But we can't allow this to say that all users should
stick with 1.8.2 until the end of time.

For example, rubygems in 1.8.2 does not support the --install-depencies
argument, which makes installing via gem much more complicated (esp. 
when i publish the gem to rubyforge.org). So once this is done, i will
probably be telling people NOT to use 1.8.2, because i think it is more
important to make our install instructions simple. We can have alternate
instructions for the people who need the modal_dialog support.

I'd appreciate your thoughts and questions.

Bret



_______________________________________________
Wtr-general mailing list
Wtr-general at rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general

_______________________________________________
Wtr-development mailing list
Wtr-development at rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-development


From charley.baker at gmail.com  Wed Jul 11 14:47:01 2007
From: charley.baker at gmail.com (Charley Baker)
Date: Wed, 11 Jul 2007 12:47:01 -0600
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <74805676EA7D9243BDF45D637BAD341067D9C5@EX01-3.rl.gov>
References: <4693C1D8.8090305@pettichord.com>
	<74805676EA7D9243BDF45D637BAD341067D9C5@EX01-3.rl.gov>
Message-ID: <f96821860707111147y6c77f9cchaa0298f154f9447b@mail.gmail.com>

You could theoretically recompile the library extensions against the latest
version of Ruby. I haven't tried and you're kind of on your own on that one.
I've had to backwards compile the wmq library with 1.8.2 to support mq6.
Otherwise vote on jira: http://jira.openqa.org/browse/WTR-1

I seem to be one of the few heavy users of the modal dialogs and should
likely own this. Timeline is tbd, dependent on my time which has been
minimal for quite some time. If you want to chip in and have some
suggestions around this area, I'd be all too happy to work with you. ;)

-c

On 7/11/07, Cain, Mark <Mark_Cain at rl.gov> wrote:
>
> Do you have a timeline on when the lasted version of ruby will be
> supported?
>
>
> --Mark
>
>
> -----Original Message-----
> From: wtr-development-bounces at rubyforge.org
> [mailto:wtr-development-bounces at rubyforge.org] On Behalf Of Bret
> Pettichord
> Sent: Tuesday, July 10, 2007 10:29 AM
> To: wtr-development at rubyforge.org
> Cc: Paul Rogers
> Subject: [Wtr-development] Recommended version of Ruby]
>
> (I posted this to wtr-general by mistake. I intended to post it here.)
>
> What version of Ruby should we recommend?
>
> After a recent discussion we agreed that the rdoc (readme.rb) should
> read:
>
>    Best is to use Ruby 1.8.2-14 or later.
>    However, if you are using the Watir::IE#modal_dialog method, you must
> use Ruby 1.8.2-14 and not a more recent version.
>    Watir (in general) will not work with Ruby 1.8.1-13. (This version of
> Ruby has a bad WIN32OLE library.)
>
> I revised this recommendation to this thus in the new (unpublished)
> website:
>
>     First you need to "install
>     Ruby":http://rubyforge.org/frs/?group_id=167 using
>     the one-click installer for Windows.
>     *We recommend Ruby 1.8.2-14 or later.*
>
>     However, if you wish to use Watir's support for the *IE web modal
>     dialog*
>     then you "must use Ruby
>     1.8.2-14":http://wiki.openqa.org/display/WTR/Installation
>     and not a more recent version. This dialog is
>     posted with the showModalDialog() JavaScript command and is
>     supported with Watir's
>     ie.modal_dialog command.
>
> However, the wiki page for installing recommends 1.8.2-14 for everyone.
>     http://wiki.openqa.org/display/WTR/Install+Ruby
>
> I was surprised when i found this and started a discussion with Zeljko
> on the page, but thought the issue might be of more general interest.
>
> Personally, i think that people should be using the latest generally
> available version of Ruby. There continue to be improvements with it.
> For example I recently reported several Ruby bugs that interfered with
> integrating Watir with Cruise Control.
> http://www.io.com/~wazmo/blog/archives/2007_04.html. At this point, we
> see problems in both 1.8.5 and 1.8.6, but expect that 1.8.7 will have
> these problems fixed and will be encouraging a move there when it
> happens.
>
> Should our recommendation for newer versions of Ruby be more emphatic?
>
> Another question regards the modal dialog support. I don't know if the
> community understands that at this point i am abandoning this
> functionality. I would love to see someone take it over and make it so
> that it was dependent on a specific version of Ruby. But i don't expect
> that to happen. But we can't allow this to say that all users should
> stick with 1.8.2 until the end of time.
>
> For example, rubygems in 1.8.2 does not support the --install-depencies
> argument, which makes installing via gem much more complicated (esp.
> when i publish the gem to rubyforge.org). So once this is done, i will
> probably be telling people NOT to use 1.8.2, because i think it is more
> important to make our install instructions simple. We can have alternate
> instructions for the people who need the modal_dialog support.
>
> I'd appreciate your thoughts and questions.
>
> Bret
>
>
>
> _______________________________________________
> Wtr-general mailing list
> Wtr-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-general
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070711/8abe18a6/attachment-0002.html>

From bret at pettichord.com  Tue Jul 24 18:35:32 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 24 Jul 2007 17:35:32 -0500
Subject: [Wtr-development] Fwd: speeding up Watir to beat Rational
	Functional Tester
In-Reply-To: <20070724210924.5482.qmail@ns6.webmasters.com>
References: <20070724210924.5482.qmail@ns6.webmasters.com>
Message-ID: <ade75c5b0707241535x4855d455jf1ebad0fde7d49c4@mail.gmail.com>

This concept looks pretty worthwhile to me. Comments? I want to think about
the names for the new methods.

Bret

---------- Forwarded message ----------
From: jonathan at kohl.ca <jonathan at kohl.ca>
Date: 24 Jul 2007 21:09:24 -0000
Subject: speeding up Watir to beat Rational Functional Tester
To: bret at pettichord.com

Hi Bret;

So far, even running Watir 1.5 in fast mode on this application is about the
same speed as RFT. I added a new method "set_fast" that just sets the entire
value in a text field, and it is now blazing fast. Also, I needed to not
have the JS events fire because they tend to cause a layer to appear that
changes as you type. This speed issue is a sticking point, but this hack
seems to work.

Here is a very simple test excerpt(assertions fail, and the data handling
variable section needs to be refactored out and improved, I need to do more
work.)

Here is what the code looks like so far in my proof of concept. So far, the
script runs very quickly compared to RFT.

Thanks;

-Jonathan

require 'watir'
require 'watir/testcase'
require 'watir/performance_helper'

class TC_Booking_Engine < Watir::TestCase

     $ie = Watir::IE.new
     time = Time.now
     tomorrow = time + 86400
     next_month =  time + 2592000
     @@date_depart = tomorrow.strftime("%d")
     @@month_depart = tomorrow.strftime("%m")
     @@date_return = tomorrow.strftime("%d")
     @@month_return = next_month.strftime("%m")
     @@test_site = "http://www.westjet.com/index_en.html"

  def test_step_one

    $ie.goto(@@test_site)
    $ie.text_field(:id, "origin1").set_fast("Calgary, AB (YYC)")
    $ie.text_field(:id, "destination1").set_fast("Victoria, BC (YYJ)")
    $ie.text_field(:name, "departDay1_day").set_fast(@@date_depart)
    $ie.text_field(:name, "departMonth1_month").set_fast(@@month_depart)
    $ie.text_field(:name, "departDay2_day").set_fast(@@date_return)
    $ie.text_field(:name, "departMonth2_month").set_fast(@@month_return)
    $ie.button(:value, "Get Flights").click
    assert($ie.contains_text("/Departing/"))
  end

  def test_step_two
    $ie.radio(:index, 4).set
    $ie.radio(:index, 9).set
    $ie.button(:value, "Continue >").click
    assert($ie.contains_text("/Who is Booking?/"))
  end

end

Here is what performance helper looks like:
require 'watir'

module Watir

  class RadioCheckCommon
       def set
           assert_enabled
           highlight(:set)
           @o.scrollIntoView #this is missing in Watir.rb and
                             # bothered users
           set_clear_item(true)
           highlight(:clear)
         end

       end

  class TextField

    #no fire events, and the entire string is set at once
    def set_fast(setThis)
      assert_enabled
      assert_not_readonly
      highlight(:set)
      @o.scrollIntoView
      @o.focus
      @o.select
      @o.value = setThis.to_s
      highlight(:clear)
    end

  end

end
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070724/cbb594c9/attachment-0002.html>

From bret at pettichord.com  Tue Jul 31 11:11:07 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 31 Jul 2007 10:11:07 -0500
Subject: [Wtr-development] performance slow down with 1.5.1.1192 gem
In-Reply-To: <1185894273.649334.281350@b79g2000hse.googlegroups.com>
References: <1185482663.554176.306420@d55g2000hsg.googlegroups.com>
	<46AA0429.9050109@pettichord.com>
	<1185894273.649334.281350@b79g2000hse.googlegroups.com>
Message-ID: <ade75c5b0707310811n13eeff57tda3b573350a7a53c@mail.gmail.com>

That would be great. This is a big concern for me. We are about ready to
release 1.5 to rubyforge but don't want to see performance problems.

Bret

On 7/31/07, sbalek <shyamala98 at gmail.com> wrote:
>
> I will try to make a small test case of my html that I can send in.
>
> On Jul 27, 10:41 am, Bret Pettichord <b... at pettichord.com> wrote:
> > sbalek wrote:
> > > My test initializes a few text fields on a page that trigger
> > > javascript execution. The performace was pretty good in watir 1.4.1. I
> > > uninstalled it and installed watir 1.5.1.1192 gem and the test took
> > > for ever.
> > > I reverted back to 1.4.1 and the test executes just fine.
> >
> > > Anyone seen this?
> >
> > If you can show us an example, that would help us a lot in understanding
> > the possible causes.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070731/427564a3/attachment-0002.html>

From bret at pettichord.com  Tue Jul 10 00:55:51 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Mon, 09 Jul 2007 23:55:51 -0500
Subject: [Wtr-development] Updates
Message-ID: <46931157.9040900@pettichord.com>

I am currently working on a new website for wtr.rubyforge.org -- a new 
set of pages that are up to date and provide more detail than what is 
available. I realize that this addresses a long-standing complaint.

I have been committing my work in progress to 
https://svn.openqa.org/svn/watir/trunk/doc. I plan to post them to 
wtr.rubyforge.org as soon as they are clearly no worse (i.e. no more out 
of date) than what is presently there. You are welcome to review and 
comment on the work in progress. You can read the *.page files yourself 
-- they are in textile, and easy to read markup language. You can also 
install webgen and the build the pages yourself if you want to see them.

My goal is mostly to provide pointers to the most current information 
that is available. I appreciate your help in this regard in particular, 
that is in publishing so much information about Watir.

In the process of doing this, i am uncovering discrepancies and 
inconsistencies that I feel should be discussed. I will be using this 
list (wtr-development) for this discussion and I hope that those of you 
who i have cc'd are reading this list.

Some specific concerns follow shortly.

I have also sent an invite to the members of wtr-general to join the new 
group at google. However, this invitation has been rerouted to the spam 
police at google and i fear it may not be released. So a more indirect 
invitation directly to wtr-general may be in order. I appreciate your 
help with this migration.

Bret




From paul.rogers at shaw.ca  Tue Jul 10 11:28:10 2007
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Tue, 10 Jul 2007 09:28:10 -0600
Subject: [Wtr-development] Updates
In-Reply-To: <46931157.9040900@pettichord.com>
References: <46931157.9040900@pettichord.com>
Message-ID: <cc71fd86ac9c.4693512a@shaw.ca>

this seems like an appropriate time for what I have been doing....

I was hoping to get a lot of work done on a couple of things - a 'rails-like' interface to watir that I think makes more readable code. Ive been using a modified form of it at work for a while and Im mostly pleased. I expect it will be an addon done via contrib or a different project.

Ive also been looking at the dialog ( file downloads, security alerts etc) but really didnt get much done. What I have done however is produce a doc that currently explains all the dialogs, and sample javascript of what produces them. Im then going to get the 'current' way of dealing with them in, and then hopefully come up with a better winclicker ( or whatever )

Paul

----- Original Message -----
From: Bret Pettichord <bret at pettichord.com>
Date: Monday, July 9, 2007 10:58 pm
Subject: Updates
To: wtr-development at rubyforge.org
Cc: Charley Baker <charley.baker at gmail.com>, Jeff Fry <jeff.fry at gmail.com>, Zeljko Filipin <zeljko.filipin at gmail.com>, Paul Rogers <paul.rogers at shaw.ca>

> I am currently working on a new website for wtr.rubyforge.org -- 
> a new 
> set of pages that are up to date and provide more detail than 
> what is 
> available. I realize that this addresses a long-standing complaint.
> 
> I have been committing my work in progress to 
> https://svn.openqa.org/svn/watir/trunk/doc. I plan to post them 
> to 
> wtr.rubyforge.org as soon as they are clearly no worse (i.e. no 
> more out 
> of date) than what is presently there. You are welcome to review 
> and 
> comment on the work in progress. You can read the *.page files 
> yourself 
> -- they are in textile, and easy to read markup language. You 
> can also 
> install webgen and the build the pages yourself if you want to 
> see them.
> 
> My goal is mostly to provide pointers to the most current 
> information 
> that is available. I appreciate your help in this regard in 
> particular, 
> that is in publishing so much information about Watir.
> 
> In the process of doing this, i am uncovering discrepancies and 
> inconsistencies that I feel should be discussed. I will be using 
> this 
> list (wtr-development) for this discussion and I hope that those 
> of you 
> who i have cc'd are reading this list.
> 
> Some specific concerns follow shortly.
> 
> I have also sent an invite to the members of wtr-general to join 
> the new 
> group at google. However, this invitation has been rerouted to 
> the spam 
> police at google and i fear it may not be released. So a more 
> indirect 
> invitation directly to wtr-general may be in order. I appreciate 
> your 
> help with this migration.
> 
> Bret
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070710/0a39e777/attachment-0003.html>

From bret at pettichord.com  Tue Jul 10 13:28:56 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 10 Jul 2007 12:28:56 -0500
Subject: [Wtr-development] Recommended version of Ruby]
Message-ID: <4693C1D8.8090305@pettichord.com>

(I posted this to wtr-general by mistake. I intended to post it here.)

What version of Ruby should we recommend?

After a recent discussion we agreed that the rdoc (readme.rb) should read:

   Best is to use Ruby 1.8.2-14 or later.
   However, if you are using the Watir::IE#modal_dialog method, you must 
use Ruby 1.8.2-14 and not a more recent version.
   Watir (in general) will not work with Ruby 1.8.1-13. (This version of 
Ruby has a bad WIN32OLE library.)

I revised this recommendation to this thus in the new (unpublished) website:

    First you need to "install
    Ruby":http://rubyforge.org/frs/?group_id=167 using
    the one-click installer for Windows.
    *We recommend Ruby 1.8.2-14 or later.*

    However, if you wish to use Watir's support for the *IE web modal
    dialog*
    then you "must use Ruby
    1.8.2-14":http://wiki.openqa.org/display/WTR/Installation
    and not a more recent version. This dialog is
    posted with the showModalDialog() JavaScript command and is
    supported with Watir's
    ie.modal_dialog command.

However, the wiki page for installing recommends 1.8.2-14 for everyone.
    http://wiki.openqa.org/display/WTR/Install+Ruby

I was surprised when i found this and started a discussion with Zeljko 
on the page, but thought the issue might be of more general interest.

Personally, i think that people should be using the latest generally 
available version of Ruby. There continue to be improvements with it. 
For example I recently reported several Ruby bugs that interfered with 
integrating Watir with Cruise Control. 
http://www.io.com/~wazmo/blog/archives/2007_04.html. At this point, we 
see problems in both 1.8.5 and 1.8.6, but expect that 1.8.7 will have 
these problems fixed and will be encouraging a move there when it happens.

Should our recommendation for newer versions of Ruby be more emphatic?

Another question regards the modal dialog support. I don't know if the 
community understands that at this point i am abandoning this 
functionality. I would love to see someone take it over and make it so 
that it was dependent on a specific version of Ruby. But i don't expect 
that to happen. But we can't allow this to say that all users should 
stick with 1.8.2 until the end of time.

For example, rubygems in 1.8.2 does not support the --install-depencies 
argument, which makes installing via gem much more complicated (esp. 
when i publish the gem to rubyforge.org). So once this is done, i will 
probably be telling people NOT to use 1.8.2, because i think it is more 
important to make our install instructions simple. We can have alternate 
instructions for the people who need the modal_dialog support.

I'd appreciate your thoughts and questions.

Bret



_______________________________________________
Wtr-general mailing list
Wtr-general at rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general



From paul.rogers at shaw.ca  Tue Jul 10 13:59:07 2007
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Tue, 10 Jul 2007 11:59:07 -0600
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <4693C1D8.8090305@pettichord.com>
References: <4693C1D8.8090305@pettichord.com>
Message-ID: <ccbeb17af70e.4693748b@shaw.ca>

how about pulling the modal_dialog support into a seperate entity ( gem, plug in what ever) and letting people who use that decide what version to use.
That may also tie in well with my dialog support stuff Im trying to do.

I guess one of the problems will be that people may not know they need? a certain version of ruby until they find they need to test modal dialogs, and then they have to install that version, which is basically a pain - Ive had to do this for rails compatability.

Was there a typo in your original post - you said 
" I would love to see someone take it over and make? it so? that it was dependent on a specific version of Ruby"

but did you mean ?
" I would love to see someone take it over and make? it so? that it was INDEPENDANT on a specific version of Ruby"



Paul


----- Original Message -----
From: Bret Pettichord <bret at pettichord.com>
Date: Tuesday, July 10, 2007 11:32 am
Subject: Recommended version of Ruby]
To: wtr-development at rubyforge.org
Cc: Paul Rogers <paul.rogers at shaw.ca>, Charley Baker <charley.baker at gmail.com>, Zeljko Filipin <zeljko.filipin at gmail.com>, Jeff Fry <jeff.fry at gmail.com>

> (I posted this to wtr-general by mistake. I intended to post it here.)
> 
> What version of Ruby should we recommend?
> 
> After a recent discussion we agreed that the rdoc (readme.rb) 
> should read:
> 
> ?? Best is to use Ruby 1.8.2-14 or later.
> ?? However, if you are using the 
> Watir::IE#modal_dialog method, you must 
> use Ruby 1.8.2-14 and not a more recent version.
> ?? Watir (in general) will not work with Ruby 1.8.1-
> 13. (This version of 
> Ruby has a bad WIN32OLE library.)
> 
> I revised this recommendation to this thus in the new 
> (unpublished) website:
> 
> ??? First you need to "install
> ??? Ruby":http://rubyforge.org/frs/?group_id=167 using
> ??? the one-click installer for Windows.
> ??? *We recommend Ruby 1.8.2-14 or later.*
> 
> ??? However, if you wish to use Watir's support 
> for the *IE web modal
> ??? dialog*
> ??? then you "must use Ruby
> ??? 1.8.2-
> 14":http://wiki.openqa.org/display/WTR/Installation??? and not a more recent version. This dialog is
> ??? posted with the showModalDialog() JavaScript 
> command and is
> ??? supported with Watir's
> ??? ie.modal_dialog command.
> 
> However, the wiki page for installing recommends 1.8.2-14 for 
> everyone.??? 
> http://wiki.openqa.org/display/WTR/Install+Ruby
> I was surprised when i found this and started a discussion with 
> Zeljko 
> on the page, but thought the issue might be of more general interest.
> 
> Personally, i think that people should be using the latest 
> generally 
> available version of Ruby. There continue to be improvements 
> with it. 
> For example I recently reported several Ruby bugs that 
> interfered with 
> integrating Watir with Cruise Control. 
> http://www.io.com/~wazmo/blog/archives/2007_04.html. At this 
> point, we 
> see problems in both 1.8.5 and 1.8.6, but expect that 1.8.7 will 
> have 
> these problems fixed and will be encouraging a move there when 
> it happens.
> 
> Should our recommendation for newer versions of Ruby be more emphatic?
> 
> Another question regards the modal dialog support. I don't know 
> if the 
> community understands that at this point i am abandoning this 
> functionality. I would love to see someone take it over and make 
> it so 
> that it was dependent on a specific version of Ruby. But i don't 
> expect 
> that to happen. But we can't allow this to say that all users 
> should 
> stick with 1.8.2 until the end of time.
> 
> For example, rubygems in 1.8.2 does not support the --install-
> depencies 
> argument, which makes installing via gem much more complicated 
> (esp. 
> when i publish the gem to rubyforge.org). So once this is done, 
> i will 
> probably be telling people NOT to use 1.8.2, because i think it 
> is more 
> important to make our install instructions simple. We can have 
> alternate 
> instructions for the people who need the modal_dialog support.
> 
> I'd appreciate your thoughts and questions.
> 
> Bret
> 
> 
> 
> _______________________________________________
> Wtr-general mailing list
> Wtr-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-general
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070710/9ece9250/attachment-0003.html>

From bret at pettichord.com  Tue Jul 10 14:44:31 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 10 Jul 2007 13:44:31 -0500
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <ccbeb17af70e.4693748b@shaw.ca>
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
Message-ID: <ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>

On 7/10/07, Paul Rogers <paul.rogers at shaw.ca> wrote:
>
> how about pulling the modal_dialog support into a seperate entity ( gem,
> plug in what ever) and letting people who use that decide what version to
> use.


This is an interesting suggestion. I guess it would help make people aware
of what has a separate set of dependencies. I've also been thinking about
making contrib a separate gem.

That may also tie in well with my dialog support stuff Im trying to do.
>
> I guess one of the problems will be that people may not know they need  a
> certain version of ruby until they find they need to test modal dialogs, and
> then they have to install that version, which is basically a pain - Ive had
> to do this for rails compatability.


My goal is to simplify using Watir for everyday users. What i don't know is
how many users are using modal dialog support. I suppose making it be a
separate gem would help give me some numbers.

Was there a typo in your original post - you said
> " I would love to see someone take it over and make  it so  that it was
> dependent on a specific version of Ruby"
>
> but did you mean ?
> " I would love to see someone take it over and make  it so  that it was
> INDEPENDANT on a specific version of Ruby"


Exactly.  Sorry for the confusion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070710/fc44cfe3/attachment-0003.html>

From jeff.fry at gmail.com  Tue Jul 10 19:47:35 2007
From: jeff.fry at gmail.com (Jeff Fry)
Date: Tue, 10 Jul 2007 16:47:35 -0700
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
	<ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
Message-ID: <970956b0707101647i7cc3cee7oe2fb300aa4491da5@mail.gmail.com>

On 7/10/07, Bret Pettichord <bret at pettichord.com> wrote:
>
> On 7/10/07, Paul Rogers <paul.rogers at shaw.ca> wrote:
> >
> > how about pulling the modal_dialog support into a seperate entity ( gem,
> > plug in what ever) and letting people who use that decide what version to
> > use.
>
>
> This is an interesting suggestion. I guess it would help make people aware
> of what has a separate set of dependencies. I've also been thinking about
> making contrib a separate gem.
>
> That may also tie in well with my dialog support stuff Im trying to do.
> >
> > I guess one of the problems will be that people may not know they need
> > a certain version of ruby until they find they need to test modal dialogs,
> > and then they have to install that version, which is basically a pain - Ive
> > had to do this for rails compatability.
>
>
> My goal is to simplify using Watir for everyday users. What i don't know
> is how many users are using modal dialog support. I suppose making it be a
> separate gem would help give me some numbers.
>

I like the keep it simple idea as well, but keeping folks on
1.8.2-14indefinitely (as you suggest) isn't going to keep things
simple either. I
think it might be workable to give folks a simple tree of:

If you want to drive modal dialogs, install ruby 182-14, watir, and the
modal_dialog gem,
Else install the latest ruby and watir.

...Except, I wonder how many folks know what 'modal dialogs' mean, and might
be a bit paralyzed by indecision. So, if we start giving folks this choice,
I'd also want to give folks a good heuristic to figure out if they currently
need to drive modal dialogs.

Maybe that heuristic would be an example page containing them? Maybe the
heuristic could be as simple as "If you don't know, ignore the modal
dialogs". I can't actually suggest a guideline because I still don't really
know what they are about myself (though I'd be curious to see an example of
one, if you know of a publicly viewable one). Perhaps if it's easier to
teach me than to document it, I could do the documenting...but I again don't
know enough to suggest that that'd be the case.  ;0)

Jeff


-- 
http://testingjeff.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070710/084ba077/attachment-0003.html>

From zeljko.filipin at gmail.com  Wed Jul 11 11:09:45 2007
From: zeljko.filipin at gmail.com (=?UTF-8?Q?=C5=BDeljko_Filipin?=)
Date: Wed, 11 Jul 2007 17:09:45 +0200
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <04dc01c7c353$b348c0e0$6400a8c0@laptop>
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
	<ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
	<970956b0707101647i7cc3cee7oe2fb300aa4491da5@mail.gmail.com>
	<04dc01c7c353$b348c0e0$6400a8c0@laptop>
Message-ID: <f81b1250707110809j4c57c9aat71a44b6159963935@mail.gmail.com>

On 7/11/07, Paul Rogers <paul.rogers at shaw.ca> wrote:
>
>  this doc may help. Its what I started a few days ago to help understand
> the different types of windows/dialogs and how to access them
>

Paul,

This is great. I would like to see this at our wiki. Would you put it there?

Zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070711/78a6de06/attachment-0003.html>

From bret at pettichord.com  Wed Jul 11 13:39:23 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Wed, 11 Jul 2007 12:39:23 -0500
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <f81b1250707110809j4c57c9aat71a44b6159963935@mail.gmail.com>
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
	<ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
	<970956b0707101647i7cc3cee7oe2fb300aa4491da5@mail.gmail.com>
	<04dc01c7c353$b348c0e0$6400a8c0@laptop>
	<f81b1250707110809j4c57c9aat71a44b6159963935@mail.gmail.com>
Message-ID: <ade75c5b0707111039u71220edaqf72ce9eb26402fa3@mail.gmail.com>

On 7/11/07, ?eljko Filipin <zeljko.filipin at gmail.com> wrote:
>
> On 7/11/07, Paul Rogers <paul.rogers at shaw.ca> wrote:
> >
> >  this doc may help. Its what I started a few days ago to help understand
> > the different types of windows/dialogs and how to access them
> >
>
> Paul,
>
> This is great. I would like to see this at our wiki. Would you put it
> there?
>

+1. I would really like to see this published.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070711/d741e83e/attachment-0003.html>

From paul.rogers at shaw.ca  Tue Jul 10 20:37:43 2007
From: paul.rogers at shaw.ca (Paul Rogers)
Date: Tue, 10 Jul 2007 18:37:43 -0600
Subject: [Wtr-development] Recommended version of Ruby]
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
	<ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
	<970956b0707101647i7cc3cee7oe2fb300aa4491da5@mail.gmail.com>
Message-ID: <04dc01c7c353$b348c0e0$6400a8c0@laptop>

this doc may help. Its what I started a few days ago to help understand the different types of windows/dialogs and how to access them

Paul
  ----- Original Message ----- 
  From: Jeff Fry 
  To: Bret Pettichord 
  Cc: Paul Rogers ; wtr-development at rubyforge.org ; Charley Baker ; Zeljko Filipin 
  Sent: Tuesday, July 10, 2007 5:47 PM
  Subject: Re: Recommended version of Ruby]





  On 7/10/07, Bret Pettichord <bret at pettichord.com> wrote:
    On 7/10/07, Paul Rogers <paul.rogers at shaw.ca> wrote: 
      how about pulling the modal_dialog support into a seperate entity ( gem, plug in what ever) and letting people who use that decide what version to use.

    This is an interesting suggestion. I guess it would help make people aware of what has a separate set of dependencies. I've also been thinking about making contrib a separate gem. 



      That may also tie in well with my dialog support stuff Im trying to do. 

      I guess one of the problems will be that people may not know they need  a certain version of ruby until they find they need to test modal dialogs, and then they have to install that version, which is basically a pain - Ive had to do this for rails compatability. 

    My goal is to simplify using Watir for everyday users. What i don't know is how many users are using modal dialog support. I suppose making it be a separate gem would help give me some numbers. 

  I like the keep it simple idea as well, but keeping folks on 1.8.2-14 indefinitely (as you suggest) isn't going to keep things simple either. I think it might be workable to give folks a simple tree of: 

  If you want to drive modal dialogs, install ruby 182-14, watir, and the modal_dialog gem,
  Else install the latest ruby and watir.

  ...Except, I wonder how many folks know what 'modal dialogs' mean, and might be a bit paralyzed by indecision. So, if we start giving folks this choice, I'd also want to give folks a good heuristic to figure out if they currently need to drive modal dialogs. 

  Maybe that heuristic would be an example page containing them? Maybe the heuristic could be as simple as "If you don't know, ignore the modal dialogs". I can't actually suggest a guideline because I still don't really know what they are about myself (though I'd be curious to see an example of one, if you know of a publicly viewable one). Perhaps if it's easier to teach me than to document it, I could do the documenting...but I again don't know enough to suggest that that'd be the case.  ;0) 

  Jeff



  -- 
  http://testingjeff.wordpress.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070710/fea2f5dc/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dialogs.doc
Type: application/msword
Size: 278016 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070710/fea2f5dc/attachment-0003.doc>

From charley.baker at gmail.com  Wed Jul 11 13:54:00 2007
From: charley.baker at gmail.com (Charley Baker)
Date: Wed, 11 Jul 2007 11:54:00 -0600
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <f81b1250707110809j4c57c9aat71a44b6159963935@mail.gmail.com>
References: <4693C1D8.8090305@pettichord.com> <ccbeb17af70e.4693748b@shaw.ca>
	<ade75c5b0707101144o7fa6837cx267e497a0efc2b38@mail.gmail.com>
	<970956b0707101647i7cc3cee7oe2fb300aa4491da5@mail.gmail.com>
	<04dc01c7c353$b348c0e0$6400a8c0@laptop>
	<f81b1250707110809j4c57c9aat71a44b6159963935@mail.gmail.com>
Message-ID: <f96821860707111054r552be60bnef169ee57fc7d9c4@mail.gmail.com>

  I'm unfortunately in the position of having to use modal dialog quite a
lot for one of our 3rd party applications which can open up to 8 or more
modals. I've got everyone on ruby 1.8.2-15 which was the last release
1.8.2one click installer. I took a look at the code for the modal
dialog, and
just haven't had the time to make this a priority to dig into since it
currently works.

  While I don't want to lose this support, given the current state of this
feature and the requirement on Ruby 1.8.2, I think a separate gem and moving
that code out makes sense, the dialog functionality in general needs some
work - modal, javascript, proxy, security dialogs, etc.

 Ideally we need some way to encapsulate the dialogs and make them somewhat
more transparent in the longer term roadmap.

Nice job on the document Paul, not only should it help users out but also
gives a clear, concise picture of the various dialog classifications that we
need to contend with.

 I'd second or third the others and say this is something that we should
publish on the site. It belongs in the category of 'doh, i should have
thought of that.'

-Charley

On 7/11/07, ?eljko Filipin <zeljko.filipin at gmail.com> wrote:
>
> On 7/11/07, Paul Rogers <paul.rogers at shaw.ca> wrote:
> >
> >  this doc may help. Its what I started a few days ago to help understand
> > the different types of windows/dialogs and how to access them
> >
>
> Paul,
>
> This is great. I would like to see this at our wiki. Would you put it
> there?
>
> Zeljko
>
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070711/49ba910b/attachment-0003.html>

From Mark_Cain at RL.gov  Wed Jul 11 13:40:58 2007
From: Mark_Cain at RL.gov (Cain, Mark)
Date: Wed, 11 Jul 2007 10:40:58 -0700
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <4693C1D8.8090305@pettichord.com>
References: <4693C1D8.8090305@pettichord.com>
Message-ID: <74805676EA7D9243BDF45D637BAD341067D9C5@EX01-3.rl.gov>

Do you have a timeline on when the lasted version of ruby will be
supported? 


--Mark


-----Original Message-----
From: wtr-development-bounces at rubyforge.org
[mailto:wtr-development-bounces at rubyforge.org] On Behalf Of Bret
Pettichord
Sent: Tuesday, July 10, 2007 10:29 AM
To: wtr-development at rubyforge.org
Cc: Paul Rogers
Subject: [Wtr-development] Recommended version of Ruby]

(I posted this to wtr-general by mistake. I intended to post it here.)

What version of Ruby should we recommend?

After a recent discussion we agreed that the rdoc (readme.rb) should
read:

   Best is to use Ruby 1.8.2-14 or later.
   However, if you are using the Watir::IE#modal_dialog method, you must
use Ruby 1.8.2-14 and not a more recent version.
   Watir (in general) will not work with Ruby 1.8.1-13. (This version of
Ruby has a bad WIN32OLE library.)

I revised this recommendation to this thus in the new (unpublished)
website:

    First you need to "install
    Ruby":http://rubyforge.org/frs/?group_id=167 using
    the one-click installer for Windows.
    *We recommend Ruby 1.8.2-14 or later.*

    However, if you wish to use Watir's support for the *IE web modal
    dialog*
    then you "must use Ruby
    1.8.2-14":http://wiki.openqa.org/display/WTR/Installation
    and not a more recent version. This dialog is
    posted with the showModalDialog() JavaScript command and is
    supported with Watir's
    ie.modal_dialog command.

However, the wiki page for installing recommends 1.8.2-14 for everyone.
    http://wiki.openqa.org/display/WTR/Install+Ruby

I was surprised when i found this and started a discussion with Zeljko
on the page, but thought the issue might be of more general interest.

Personally, i think that people should be using the latest generally
available version of Ruby. There continue to be improvements with it. 
For example I recently reported several Ruby bugs that interfered with
integrating Watir with Cruise Control. 
http://www.io.com/~wazmo/blog/archives/2007_04.html. At this point, we
see problems in both 1.8.5 and 1.8.6, but expect that 1.8.7 will have
these problems fixed and will be encouraging a move there when it
happens.

Should our recommendation for newer versions of Ruby be more emphatic?

Another question regards the modal dialog support. I don't know if the
community understands that at this point i am abandoning this
functionality. I would love to see someone take it over and make it so
that it was dependent on a specific version of Ruby. But i don't expect
that to happen. But we can't allow this to say that all users should
stick with 1.8.2 until the end of time.

For example, rubygems in 1.8.2 does not support the --install-depencies
argument, which makes installing via gem much more complicated (esp. 
when i publish the gem to rubyforge.org). So once this is done, i will
probably be telling people NOT to use 1.8.2, because i think it is more
important to make our install instructions simple. We can have alternate
instructions for the people who need the modal_dialog support.

I'd appreciate your thoughts and questions.

Bret



_______________________________________________
Wtr-general mailing list
Wtr-general at rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general

_______________________________________________
Wtr-development mailing list
Wtr-development at rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-development


From charley.baker at gmail.com  Wed Jul 11 14:47:01 2007
From: charley.baker at gmail.com (Charley Baker)
Date: Wed, 11 Jul 2007 12:47:01 -0600
Subject: [Wtr-development] Recommended version of Ruby]
In-Reply-To: <74805676EA7D9243BDF45D637BAD341067D9C5@EX01-3.rl.gov>
References: <4693C1D8.8090305@pettichord.com>
	<74805676EA7D9243BDF45D637BAD341067D9C5@EX01-3.rl.gov>
Message-ID: <f96821860707111147y6c77f9cchaa0298f154f9447b@mail.gmail.com>

You could theoretically recompile the library extensions against the latest
version of Ruby. I haven't tried and you're kind of on your own on that one.
I've had to backwards compile the wmq library with 1.8.2 to support mq6.
Otherwise vote on jira: http://jira.openqa.org/browse/WTR-1

I seem to be one of the few heavy users of the modal dialogs and should
likely own this. Timeline is tbd, dependent on my time which has been
minimal for quite some time. If you want to chip in and have some
suggestions around this area, I'd be all too happy to work with you. ;)

-c

On 7/11/07, Cain, Mark <Mark_Cain at rl.gov> wrote:
>
> Do you have a timeline on when the lasted version of ruby will be
> supported?
>
>
> --Mark
>
>
> -----Original Message-----
> From: wtr-development-bounces at rubyforge.org
> [mailto:wtr-development-bounces at rubyforge.org] On Behalf Of Bret
> Pettichord
> Sent: Tuesday, July 10, 2007 10:29 AM
> To: wtr-development at rubyforge.org
> Cc: Paul Rogers
> Subject: [Wtr-development] Recommended version of Ruby]
>
> (I posted this to wtr-general by mistake. I intended to post it here.)
>
> What version of Ruby should we recommend?
>
> After a recent discussion we agreed that the rdoc (readme.rb) should
> read:
>
>    Best is to use Ruby 1.8.2-14 or later.
>    However, if you are using the Watir::IE#modal_dialog method, you must
> use Ruby 1.8.2-14 and not a more recent version.
>    Watir (in general) will not work with Ruby 1.8.1-13. (This version of
> Ruby has a bad WIN32OLE library.)
>
> I revised this recommendation to this thus in the new (unpublished)
> website:
>
>     First you need to "install
>     Ruby":http://rubyforge.org/frs/?group_id=167 using
>     the one-click installer for Windows.
>     *We recommend Ruby 1.8.2-14 or later.*
>
>     However, if you wish to use Watir's support for the *IE web modal
>     dialog*
>     then you "must use Ruby
>     1.8.2-14":http://wiki.openqa.org/display/WTR/Installation
>     and not a more recent version. This dialog is
>     posted with the showModalDialog() JavaScript command and is
>     supported with Watir's
>     ie.modal_dialog command.
>
> However, the wiki page for installing recommends 1.8.2-14 for everyone.
>     http://wiki.openqa.org/display/WTR/Install+Ruby
>
> I was surprised when i found this and started a discussion with Zeljko
> on the page, but thought the issue might be of more general interest.
>
> Personally, i think that people should be using the latest generally
> available version of Ruby. There continue to be improvements with it.
> For example I recently reported several Ruby bugs that interfered with
> integrating Watir with Cruise Control.
> http://www.io.com/~wazmo/blog/archives/2007_04.html. At this point, we
> see problems in both 1.8.5 and 1.8.6, but expect that 1.8.7 will have
> these problems fixed and will be encouraging a move there when it
> happens.
>
> Should our recommendation for newer versions of Ruby be more emphatic?
>
> Another question regards the modal dialog support. I don't know if the
> community understands that at this point i am abandoning this
> functionality. I would love to see someone take it over and make it so
> that it was dependent on a specific version of Ruby. But i don't expect
> that to happen. But we can't allow this to say that all users should
> stick with 1.8.2 until the end of time.
>
> For example, rubygems in 1.8.2 does not support the --install-depencies
> argument, which makes installing via gem much more complicated (esp.
> when i publish the gem to rubyforge.org). So once this is done, i will
> probably be telling people NOT to use 1.8.2, because i think it is more
> important to make our install instructions simple. We can have alternate
> instructions for the people who need the modal_dialog support.
>
> I'd appreciate your thoughts and questions.
>
> Bret
>
>
>
> _______________________________________________
> Wtr-general mailing list
> Wtr-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-general
>
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070711/8abe18a6/attachment-0003.html>

From bret at pettichord.com  Tue Jul 24 18:35:32 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 24 Jul 2007 17:35:32 -0500
Subject: [Wtr-development] Fwd: speeding up Watir to beat Rational
	Functional Tester
In-Reply-To: <20070724210924.5482.qmail@ns6.webmasters.com>
References: <20070724210924.5482.qmail@ns6.webmasters.com>
Message-ID: <ade75c5b0707241535x4855d455jf1ebad0fde7d49c4@mail.gmail.com>

This concept looks pretty worthwhile to me. Comments? I want to think about
the names for the new methods.

Bret

---------- Forwarded message ----------
From: jonathan at kohl.ca <jonathan at kohl.ca>
Date: 24 Jul 2007 21:09:24 -0000
Subject: speeding up Watir to beat Rational Functional Tester
To: bret at pettichord.com

Hi Bret;

So far, even running Watir 1.5 in fast mode on this application is about the
same speed as RFT. I added a new method "set_fast" that just sets the entire
value in a text field, and it is now blazing fast. Also, I needed to not
have the JS events fire because they tend to cause a layer to appear that
changes as you type. This speed issue is a sticking point, but this hack
seems to work.

Here is a very simple test excerpt(assertions fail, and the data handling
variable section needs to be refactored out and improved, I need to do more
work.)

Here is what the code looks like so far in my proof of concept. So far, the
script runs very quickly compared to RFT.

Thanks;

-Jonathan

require 'watir'
require 'watir/testcase'
require 'watir/performance_helper'

class TC_Booking_Engine < Watir::TestCase

     $ie = Watir::IE.new
     time = Time.now
     tomorrow = time + 86400
     next_month =  time + 2592000
     @@date_depart = tomorrow.strftime("%d")
     @@month_depart = tomorrow.strftime("%m")
     @@date_return = tomorrow.strftime("%d")
     @@month_return = next_month.strftime("%m")
     @@test_site = "http://www.westjet.com/index_en.html"

  def test_step_one

    $ie.goto(@@test_site)
    $ie.text_field(:id, "origin1").set_fast("Calgary, AB (YYC)")
    $ie.text_field(:id, "destination1").set_fast("Victoria, BC (YYJ)")
    $ie.text_field(:name, "departDay1_day").set_fast(@@date_depart)
    $ie.text_field(:name, "departMonth1_month").set_fast(@@month_depart)
    $ie.text_field(:name, "departDay2_day").set_fast(@@date_return)
    $ie.text_field(:name, "departMonth2_month").set_fast(@@month_return)
    $ie.button(:value, "Get Flights").click
    assert($ie.contains_text("/Departing/"))
  end

  def test_step_two
    $ie.radio(:index, 4).set
    $ie.radio(:index, 9).set
    $ie.button(:value, "Continue >").click
    assert($ie.contains_text("/Who is Booking?/"))
  end

end

Here is what performance helper looks like:
require 'watir'

module Watir

  class RadioCheckCommon
       def set
           assert_enabled
           highlight(:set)
           @o.scrollIntoView #this is missing in Watir.rb and
                             # bothered users
           set_clear_item(true)
           highlight(:clear)
         end

       end

  class TextField

    #no fire events, and the entire string is set at once
    def set_fast(setThis)
      assert_enabled
      assert_not_readonly
      highlight(:set)
      @o.scrollIntoView
      @o.focus
      @o.select
      @o.value = setThis.to_s
      highlight(:clear)
    end

  end

end
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070724/cbb594c9/attachment-0003.html>

From bret at pettichord.com  Tue Jul 31 11:11:07 2007
From: bret at pettichord.com (Bret Pettichord)
Date: Tue, 31 Jul 2007 10:11:07 -0500
Subject: [Wtr-development] performance slow down with 1.5.1.1192 gem
In-Reply-To: <1185894273.649334.281350@b79g2000hse.googlegroups.com>
References: <1185482663.554176.306420@d55g2000hsg.googlegroups.com>
	<46AA0429.9050109@pettichord.com>
	<1185894273.649334.281350@b79g2000hse.googlegroups.com>
Message-ID: <ade75c5b0707310811n13eeff57tda3b573350a7a53c@mail.gmail.com>

That would be great. This is a big concern for me. We are about ready to
release 1.5 to rubyforge but don't want to see performance problems.

Bret

On 7/31/07, sbalek <shyamala98 at gmail.com> wrote:
>
> I will try to make a small test case of my html that I can send in.
>
> On Jul 27, 10:41 am, Bret Pettichord <b... at pettichord.com> wrote:
> > sbalek wrote:
> > > My test initializes a few text fields on a page that trigger
> > > javascript execution. The performace was pretty good in watir 1.4.1. I
> > > uninstalled it and installed watir 1.5.1.1192 gem and the test took
> > > for ever.
> > > I reverted back to 1.4.1 and the test executes just fine.
> >
> > > Anyone seen this?
> >
> > If you can show us an example, that would help us a lot in understanding
> > the possible causes.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20070731/427564a3/attachment-0003.html>