[wtr-general] Re: [Wtr-development] Vapir

2010-05-11 Thread b...@pettichord.com
On May 8, 8:12 am, Jarmo Pertman jarm...@gmail.com wrote:
 Maybe this is a completely different problem? Maybe we should ask,
 what is the main reasons why classes get extended or monkey-patched.
 Maybe
 there even isn't so many users who have been doing that or do we know
 that for certain that there really is?

I know that this has happened a lot at my company (Convio). Sometimes
it is to fix a bug -- I'm working to merge these changes back in.
Sometimes it is to handle an odd application-specific problem.
Sometimes it is to add new, convenience methods that maybe we should
add to Watir as well.

 I, myself, have been doing these only if there's something broken or
 not working well and after that i have been trying (and will try even
 more) to push
 these changes into main Watir's codebase.

Thanks for your help with this.

If we change the class names, it not only causes compatibility
problems, but it also makes it nearly impossible to accept these kinds
of fixes. We have a backlog of submitted fixes in pull requests and
jira, and it seems like the right thing to do would be to process
these submissions before changing the class names.

Bret

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

You received this message because you are subscribed to 
http://groups.google.com/group/watir-general
To post: watir-general@googlegroups.com
To unsubscribe: watir-general+unsubscr...@googlegroups.com


[wtr-general] Re: [Wtr-development] Vapir

2010-05-11 Thread b...@pettichord.com
On May 8, 8:12 am, Jarmo Pertman jarm...@gmail.com wrote:
 Maybe this is a completely different problem? Maybe we should ask,
 what is the main reasons why classes get extended or monkey-patched.
 Maybe
 there even isn't so many users who have been doing that or do we know
 that for certain that there really is?

There has been a lot of this at my company (Convio). Much of this
happened before I arrived.

Some extensions fix bugs, some support weird application-specific
behavior. Some add methods that people thought should be added to
Watir.

I am working to merge the good stuff back in the public code base.

 I, myself, have been doing these only if there's something broken or
 not working well and after that i have been trying (and will try even
 more) to push
 these changes into main Watir's codebase.

That's great. I'd like to get these changes merged in before changing
class names. We have a backlog of pull requests and code submissions
in Jira that I'd live to tackle first.

Bret

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

You received this message because you are subscribed to 
http://groups.google.com/group/watir-general
To post: watir-general@googlegroups.com
To unsubscribe: watir-general+unsubscr...@googlegroups.com


[wtr-general] Re: [Wtr-development] Vapir

2010-05-08 Thread Jarmo Pertman
Maybe this is a completely different problem? Maybe we should ask,
what is the main reasons why classes get extended or monkey-patched.
Maybe
there even isn't so many users who have been doing that or do we know
that for certain that there really is?

I, myself, have been doing these only if there's something broken or
not working well and after that i have been trying (and will try even
more) to push
these changes into main Watir's codebase.

Jarmo

On May 7, 10:16 pm, b...@pettichord.com bpettich...@gmail.com
wrote:
 The biggest change in Vapir is that class names have been
 systematically changed. We've been reluctant to make these changes in
 Watir because it would lead to a lot of compatibility problems for
 people who have extended the existing Watir classes. I'm happy to
 reconsider if there really is a demand for this kind of change.

 If I was starting from scratch and didn't have any legacy users, I'd
 probably propose making most of the changes that Ethan made. But I
 have found that Watir users have very little stomach for introducing
 incompatible changes.

 If there is stuff you like in Vapir that is compatible, please let us
 know.

 Bret

 On May 5, 2:39 pm, Tim Koopmans tim.ko...@gmail.com wrote:





  This makes no sense to me. Shouldn't we just merge important changes  
  like modal support into Watir main? Or am I missing something? Is  
  vapir a silent protest of sorts?

  Regards,
  Tim

  On 06/05/2010, at 3:47, Ethan notet...@gmail.com wrote:

   Dear Watir people,
   I am happy to announce the release of the Vapir library, which is a
   fork of Watir and FireWatir.

   It is documented primarily at the github wiki at
  http://wiki.github.com/vapir/vapir/
   Documentation is sorely lacking at the moment, and improving it is my
   highest priority, but putting the code out for people to use preceded
   that.

   Links to other aspects of the forked project are listed 
   athttp://vapir.org/

   The API is in most cases the same, with some changes where I felt it
   was best; these are enumerated at
  http://wiki.github.com/vapir/vapir/differences-from-watir-api

   It is a release candidate currently, and can be installed using the
   --pre flag to rubygems (rubygems 1.3.6 is required; run gem update
   --system if you are on an earlier version).
   gem install --pre vapir-firefox
   gem install --pre vapir-ie

   Major improvements over Watir are:
   - Modal dialog API which is (mostly) consistent between IE and Firefox
   -http://wiki.github.com/vapir/vapir/modal-dialogs
   - Unified codebase for both Firefox and IE interaction - basically,
   everything that works in IE works in Firefox as well, which is not the
   case with FireWatir.
   - Many bug fixes and feature enhancements for issues in Watir's issue
   tracker, which will be documented more thoroughly on the wiki in the
   coming days.

   I would encourage any questions or discussion to go to Vapir's mailing
   list, not Watir's. The forked project is intended to stand on its own,
   separate from the Watir library due to a great deal of changes in the
   codebase which make it to some degree (a small degree, hopefully)
   incompatible. Support will be on Vapir's mailing list at
  http://groups.google.com/group/vapir

   -Ethan
   ___
   Wtr-development mailing list
   wtr-developm...@rubyforge.org
  http://rubyforge.org/mailman/listinfo/wtr-development

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

  You received this message because you are subscribed 
  tohttp://groups.google.com/group/watir-general
  To post: watir-general@googlegroups.com
  To unsubscribe: watir-general+unsubscr...@googlegroups.com

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

 You received this message because you are subscribed 
 tohttp://groups.google.com/group/watir-general
 To post: watir-general@googlegroups.com
 To unsubscribe: watir-general+unsubscr...@googlegroups.com

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

You received this message because you are subscribed to 
http://groups.google.com/group/watir-general
To post: watir-general@googlegroups.com
To unsubscribe: watir-general+unsubscr...@googlegroups.com


[wtr-general] Re: [Wtr-development] Vapir

2010-05-07 Thread b...@pettichord.com
The biggest change in Vapir is that class names have been
systematically changed. We've been reluctant to make these changes in
Watir because it would lead to a lot of compatibility problems for
people who have extended the existing Watir classes. I'm happy to
reconsider if there really is a demand for this kind of change.

If I was starting from scratch and didn't have any legacy users, I'd
probably propose making most of the changes that Ethan made. But I
have found that Watir users have very little stomach for introducing
incompatible changes.

If there is stuff you like in Vapir that is compatible, please let us
know.

Bret

On May 5, 2:39 pm, Tim Koopmans tim.ko...@gmail.com wrote:
 This makes no sense to me. Shouldn't we just merge important changes  
 like modal support into Watir main? Or am I missing something? Is  
 vapir a silent protest of sorts?

 Regards,
 Tim

 On 06/05/2010, at 3:47, Ethan notet...@gmail.com wrote:



  Dear Watir people,
  I am happy to announce the release of the Vapir library, which is a
  fork of Watir and FireWatir.

  It is documented primarily at the github wiki at
 http://wiki.github.com/vapir/vapir/
  Documentation is sorely lacking at the moment, and improving it is my
  highest priority, but putting the code out for people to use preceded
  that.

  Links to other aspects of the forked project are listed athttp://vapir.org/

  The API is in most cases the same, with some changes where I felt it
  was best; these are enumerated at
 http://wiki.github.com/vapir/vapir/differences-from-watir-api

  It is a release candidate currently, and can be installed using the
  --pre flag to rubygems (rubygems 1.3.6 is required; run gem update
  --system if you are on an earlier version).
  gem install --pre vapir-firefox
  gem install --pre vapir-ie

  Major improvements over Watir are:
  - Modal dialog API which is (mostly) consistent between IE and Firefox
  -http://wiki.github.com/vapir/vapir/modal-dialogs
  - Unified codebase for both Firefox and IE interaction - basically,
  everything that works in IE works in Firefox as well, which is not the
  case with FireWatir.
  - Many bug fixes and feature enhancements for issues in Watir's issue
  tracker, which will be documented more thoroughly on the wiki in the
  coming days.

  I would encourage any questions or discussion to go to Vapir's mailing
  list, not Watir's. The forked project is intended to stand on its own,
  separate from the Watir library due to a great deal of changes in the
  codebase which make it to some degree (a small degree, hopefully)
  incompatible. Support will be on Vapir's mailing list at
 http://groups.google.com/group/vapir

  -Ethan
  ___
  Wtr-development mailing list
  wtr-developm...@rubyforge.org
 http://rubyforge.org/mailman/listinfo/wtr-development

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

 You received this message because you are subscribed 
 tohttp://groups.google.com/group/watir-general
 To post: watir-general@googlegroups.com
 To unsubscribe: watir-general+unsubscr...@googlegroups.com

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

You received this message because you are subscribed to 
http://groups.google.com/group/watir-general
To post: watir-general@googlegroups.com
To unsubscribe: watir-general+unsubscr...@googlegroups.com


[wtr-general] Re: [Wtr-development] Vapir

2010-05-05 Thread Tim Koopmans
This makes no sense to me. Shouldn't we just merge important changes  
like modal support into Watir main? Or am I missing something? Is  
vapir a silent protest of sorts?


Regards,
Tim



On 06/05/2010, at 3:47, Ethan notet...@gmail.com wrote:


Dear Watir people,
I am happy to announce the release of the Vapir library, which is a
fork of Watir and FireWatir.

It is documented primarily at the github wiki at
http://wiki.github.com/vapir/vapir/
Documentation is sorely lacking at the moment, and improving it is my
highest priority, but putting the code out for people to use preceded
that.

Links to other aspects of the forked project are listed at http://vapir.org/

The API is in most cases the same, with some changes where I felt it
was best; these are enumerated at
http://wiki.github.com/vapir/vapir/differences-from-watir-api

It is a release candidate currently, and can be installed using the
--pre flag to rubygems (rubygems 1.3.6 is required; run gem update
--system if you are on an earlier version).
gem install --pre vapir-firefox
gem install --pre vapir-ie

Major improvements over Watir are:
- Modal dialog API which is (mostly) consistent between IE and Firefox
- http://wiki.github.com/vapir/vapir/modal-dialogs
- Unified codebase for both Firefox and IE interaction - basically,
everything that works in IE works in Firefox as well, which is not the
case with FireWatir.
- Many bug fixes and feature enhancements for issues in Watir's issue
tracker, which will be documented more thoroughly on the wiki in the
coming days.

I would encourage any questions or discussion to go to Vapir's mailing
list, not Watir's. The forked project is intended to stand on its own,
separate from the Watir library due to a great deal of changes in the
codebase which make it to some degree (a small degree, hopefully)
incompatible. Support will be on Vapir's mailing list at
http://groups.google.com/group/vapir

-Ethan
___
Wtr-development mailing list
wtr-developm...@rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-development


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

You received this message because you are subscribed to 
http://groups.google.com/group/watir-general
To post: watir-general@googlegroups.com
To unsubscribe: watir-general+unsubscr...@googlegroups.com