Re: [Wtr-general] Fwd: Managing the Watir Project -- Wikipedia entry
Bret Pettichord wrote: I've been getting some private emails from people who are upset by this. But the only thing that will convince me to change my mind about putting stuff in contrib is unit tests. FWIW, I agree with you on this :-) I usually barely skim the email list, but this thread caught my attention and I'd been following it a little more closely. -- Chris http://clabs.org/blogki ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Fwd: Managing the Watir Project -- Wikipedia entry
Sun wrote: A separate issue is whether the Wikipedia article should include code that only works with an experimental library in an unreleased version of Watir. A valid point. I do point out immediately following the example that it may be necessary to download and install the current development Watir gem rather than using the standard Watir release to make sure people are aware of this. I assume that when the 1.5.x release is available, that this feature will be incorporated even if it is from that separate directory. In the mean time, people who read the article are informed that if they want to use this bit of code, they need the development gem and not the standard release. The feature will be incorporated in 1.5, one way or another, but the way it is used may change. No one should assume that this code on the Wikipedia will work with the released version of 1.5 without modification. Everything in contrib should be considered to be experimental and therefore subject to change. We have a lot of code that is currently in the main Watir package that we plan to move to contrib because it currently lacks unit tests (or has weak unit tests) and therefore has been difficult to support and is sometimes buggy. We will also provide mechanisms to minimize the complications for those upgrading from from 1.4 who have been using such code. I suspect that some people will want to only use the reliable and supported parts of Watir and not the experimental code. If there is demand for it, we will package separate Standard Watir and Experimental Watir distributions for 1.5. Other open-source projects do this. I've been getting some private emails from people who are upset by this. But the only thing that will convince me to change my mind about putting stuff in contrib is unit tests. Please write unit tests instead of sending me pleading emails. Unit tests allow us to refactor the code, making it easier to use, more reliable, and ensuring that it continues to work with future releases. Without unit tests, we cannot support code. In the past we made some exceptions, but this rule will be much more strictly enforced with 1.5. Bret ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Fwd: Managing the Watir Project -- Wikipedia entry
A separate issue is whether the Wikipedia article should include code that only works with an experimental library in an unreleased version of Watir. A valid point. I do point out immediately following the example that it may be necessary to download and install the current development Watir gem rather than using the standard Watir release to make sure people are aware of this. I assume that when the 1.5.x release is available, that this feature will be incorporated even if it is from that separate directory. In the mean time, people who read the article are informed that if they want to use this bit of code, they need the development gem and not the standard release. - Posted via Jive Forums http://forums.openqa.org/thread.jspa?threadID=4501messageID=12677#12677 ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Fwd: Managing the Watir Project -- Wikipedia entry
David Schmidt wrote: I disagree that the code *should* look like that. That is nice code if you *know* that a dialog has appeared. The problem is that after performing a click_no_wait you don't know what kind of popup may appear (or even IF one will appear). If you were a tester, i think you would know what kind of popup you were expecting. At issue here is how to make the API for Watir intuitive for testing. This is not a question of implementation, but rather of psychology and design and usage. I like to be open to a broad range of views on how to use Watir for testing and i have occassionally made it work to support testing practices that i may not personally appreciate. Testers and developers using watir for testing get one vote. Developers using watir to build web-scraping apps get zero votes. This is not a democracy. It is a testing tool. If we can find a way to also make Watir usable for other uses, that that is fine. But it will not be optimized at the risk of making it less intuitive for testers. Bret ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Fwd: Managing the Watir Project -- Wikipedia entry
Sun wrote:
I don't want to get into the middle of the discussion that you guys are
having. However I do want to point something out. Which is -- none of the
popup handling referenced in the FAQ worked for me.
(1) Not the one using the def startClicker(button , waitTime = 3) etc.
approach,
(2) nor the one using the def check_for_popups autoit =
WIN32OLE.new('AutoItX3.Control') etc. approach. They simply did nothing. The
popup was not handled in either case.
(3) But -- the approach using hwnd = ie.enabled_popup(5) etc. did work.
I think all these approaches are ugly. The thing to do is take what
works best and then improve its usability.
Bret
___
Wtr-general mailing list
Wtr-general@rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Fwd: Managing the Watir Project -- Wikipedia entry
Bret Pettichord wrote:
On 9/26/06, *Sun* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Regarding documentation, please see:
http://en.wikipedia.org/wiki/Watir
Thank you for taking the time to do this. I do have a comment that i
hope you won't take personally.
I find code like this to be rather embarrassing:
# To handle general popups, use WinClicker.
ie.button(:name, btnG).click_no_wait # ensure popup won't block Watir
hwnd = ie.enabled_popup(5) # get a handle if one exists
if (hwnd)# yes there is a popup
w = WinClicker.new
w.makeWindowActive(hwnd)
w.clickWindowsButton_hwnd
(hwnd, Yes) # click the Yes button
end
I keep meaning to write a simpler way of doing this kind of thing, but
then never really have the time to follow through. In my opinion, The
code should actually look like this:
ie.button(:name, btnG).click_no_wait # ensure popup won't block Watir
ie.dialog.button('OK').click
I disagree that the code *should* look like that. That is nice code if
you *know* that a dialog has appeared. The problem is that after
performing a click_no_wait you don't know what kind of popup may appear
(or even IF one will appear). It could be an IE security warning, or a
Javascript dialog, or a modal dialog. I have sites that I use Watir for
that DO just that type of thing. After clicking a button I may get a
Javascript popup with an error warning, or I may get a modal dialog with
additional input fields.
The reason I wrote enabled_popup is because Windows uses an
enabled_popup call to give you a window handle to *whichever* popup
window is active. I often use it in combination with
Watir::until_with_timeout to detect when either a popup has appeared OR
the browser has finished loading (with no popup). If a popup is
detected then you can do various tests to determine which type of popup
is present and handle it as needed.
Also, since we get error messages in Javascript popups we also need to
be able to access any text in them, which WinClicker also provides.
I did begin implementing an interface like this in watir once (see
watir/dialog.rb and unittests/dialog_test.rb), but didn't finish. It
used the Autoit library, which i also now think is not the best approach.
I would love to see someone finish this work. Clearly, this is a
common problem for Watir users, but my view is that the problem is not
a lack of documentation, but rather a hard-to-user interface. I would
love to get this cleaned up for the full release of 1.5.
Bret
Perhaps you'd find more people willing to finish the work if their work
wasn't partially merged without notice. Or perhaps people would be more
willing to contribute if their functioning code, used by other Watir
users, wasn't removed from Watir without notice. Maybe folks would be
happy to contribute their hard work if they weren't summarily removed
from the commit group after they admitted to breaking a method used by
some users (searching for :id by regexp) but for which there were NO
unit tests AND THEN FIXING THAT BUG AND ADDING IN THE MISSING UNIT
TESTS. Referring to their code as unreliable with no evidence of any
problem with that code or any failures of any unit tests, especially
when the problem someone was having was not related to that code also
shows a certain pre-disposition towards that code.
I've seen another list member censored by having all of HIS posts
moderated after he made some statements disagreeing with some of the
decisions being made by the Watir developers.
I believe it's better to have code that solves people's problems, and in
making that code available to them as soon as possible rather than
waiting to release a new version until the code is finished or
perfect. This is because almost NO code is ever finished or
perfect. Different people have different uses for Watir, and need
different functionality. Just because a particular method isn't useful
for one user doesn't mean it isn't required by other users. The best
way for code to be tested by the community and peer reviewed is to have
it USED by that community in development builds. I'm not saying my
contributions have all been perfect or the best they could be, but my
code is working in production systems, and working well. I think I've
also shown a willingness to promptly fix any problems that are shown.
Sorry to vent, but I'm the author of the enabled_popup() method (which
has been removed from watir.rb) and the one that helped Sun solve his
problem when he presented it to the list. Statements welcoming
contributions aren't entirely consistent with the treatment those
contributions receive.
I fully expect comments explaining that my code was inappropriate or
didn't work, but I'll let my code and methods stand for themselves and I
welcome peer review, comments and improvements to my contributions.
David Schmidt
Re: [Wtr-general] Fwd: Managing the Watir Project -- Wikipedia entry
Sorry to vent, but I'm the author of the enabled_popup() method (which has been removed from watir.rb) and the one that helped Sun solve his problem when he presented it to the list. If enabled_popup() has in fact been removed entirely, this will be a problem I think -- since I need the WinClicker to handle my popups. Other techniques (identified in the FAQ) in fact did not function for me -- at all -- which is why I used the code I did. Sowhat is the story? - Posted via Jive Forums http://forums.openqa.org/thread.jspa?threadID=4501messageID=12622#12622 ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Fwd: Managing the Watir Project -- Wikipedia entry
Original Message
Subject:Re: [Wtr-general] Fwd: Managing the Watir Project -- Wikipedia
entry
# To handle general popups, use WinClicker.
ie.button(:name, btnG).click_no_wait # ensure popup won't block Watir
hwnd = ie.enabled_popup(5) # get a handle if one exists
if (hwnd)# yes there is a popup
w = WinClicker.new
w.makeWindowActive(hwnd)
w.clickWindowsButton_hwnd
(hwnd, Yes) # click the Yes button
end
I keep meaning to write a simpler way of doing this kind of thing, but
then never really have the time to follow through. In my opinion, The
code should actually look like this:
ie.button(:name, btnG).click_no_wait # ensure popup won't block Watir
ie.dialog.button('OK').click
I disagree that the code *should* look like that. That is nice code if
you *know* that a dialog has appeared. The problem is that after
performing a click_no_wait you don't know what kind of popup may appear
(or even IF one will appear). It could be an IE security warning, or a
Javascript dialog, or a modal dialog. I have sites that I use Watir for
that DO just that type of thing. After clicking a button I may get a
Javascript popup with an error warning, or I may get a modal dialog with
additional input fields.
This is a design decision which can be discussed on the Watir
development list. I generally know what dialogs I'm expecting when I
call click_no_wait and handle them appropriately. If I don't get the
expected dialog then that usually indicates either a flaw in my test
script or a defect in the application I'm testing. This may be a
difference between the philosophy of screen scraping versus testing.
I personally prefer the solution that Bret suggested. The details of
what type of dialog and how to handle it can then carried out behind
the scenes - there's a lot of confusion regarding the various types of
dialogs - modals, js dialogs - which is best to encapsulate in a
simple dialog class tied to ie, enabled_popup could be called
internally and could support exist? if you want it to:
if ie.dialog.exist?
ie.dialog.button(OK).click
assert(ie.dialog.text.include?(foo))
This to me is more intuitive and straight forward, hiding the
implementation details of the dialog itself.
The reason I wrote enabled_popup is because Windows uses an
enabled_popup call to give you a window handle to *whichever* popup
window is active. I often use it in combination with
Watir::until_with_timeout to detect when either a popup has appeared OR
the browser has finished loading (with no popup). If a popup is
detected then you can do various tests to determine which type of popup
is present and handle it as needed.
Also, since we get error messages in Javascript popups we also need to
be able to access any text in them, which WinClicker also provides.
I did begin implementing an interface like this in watir once (see
watir/dialog.rb and unittests/dialog_test.rb), but didn't finish. It
used the Autoit library, which i also now think is not the best approach.
I would love to see someone finish this work. Clearly, this is a
common problem for Watir users, but my view is that the problem is not
a lack of documentation, but rather a hard-to-user interface. I would
love to get this cleaned up for the full release of 1.5.
Bret
Perhaps you'd find more people willing to finish the work if their work
wasn't partially merged without notice. Or perhaps people would be more
willing to contribute if their functioning code, used by other Watir
users, wasn't removed from Watir without notice. Maybe folks would be
happy to contribute their hard work if they weren't summarily removed
from the commit group after they admitted to breaking a method used by
some users (searching for :id by regexp) but for which there were NO
unit tests AND THEN FIXING THAT BUG AND ADDING IN THE MISSING UNIT
TESTS. Referring to their code as unreliable with no evidence of any
problem with that code or any failures of any unit tests, especially
when the problem someone was having was not related to that code also
shows a certain pre-disposition towards that code.
I've seen another list member censored by having all of HIS posts
moderated after he made some statements disagreeing with some of the
decisions being made by the Watir developers.
I believe it's better to have code that solves people's problems, and in
making that code available to them as soon as possible rather than
waiting to release a new version until the code is finished or
perfect. This is because almost NO code is ever finished or
perfect. Different people have different uses for Watir, and need
different functionality. Just because a particular method isn't useful
for one user doesn't mean it isn't required by other users. The best
way for code to be tested by the community and peer reviewed is to have
it USED
Re: [Wtr-general] Fwd: Managing the Watir Project -- Wikipedia entry
Sun wrote: If enabled_popup() has in fact been removed entirely, this will be a problem I think -- since I need the WinClicker to handle my popups. Other techniques (identified in the FAQ) in fact did not function for me -- at all -- which is why I used the code I did. Sowhat is the story? David is upset that i moved this method to a different file. It is still part of the distribution. Please see this for a detailed explanation for why this was done. http://rubyforge.org/pipermail/wtr-development/2006-September/15.html One of the reasons for moving this code was to make it clear that this code was untested and subject to unpredicable changes. A separate issue is whether the Wikipedia article should include code that only works with an experimental library in an unreleased version of Watir. Bret ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Fwd: Managing the Watir Project -- Wikipedia entry
A comment -- when substituting this:
===
#Ensure popup won't block Watir
ie.button(:name, btnG).click_no_wait
ie.dialog.button('OK').click
===
for this:
===
#Ensure popup won't block Watir
ie.button(:name, btnG).click_no_wait
#Handle the popup
hwnd = ie.enabled_popup(5)
if (hwnd) #yes there is a popup
p hwnd
w = WinClicker.new
w.makeWindowActive(hwnd)
w.clickWindowsButton_hwnd(hwnd, Yes)
end
===
I get the following error:
1) Error:
test_search(TC_article_example):
NoMethodError: undefined method `dialog' for #Watir::IE:0x27e62e0
So while the code I posted in wikipedia may not be the prettiest -- it DOES
work -- and works reliably.
-
Posted via Jive Forums
http://forums.openqa.org/thread.jspa?threadID=4501messageID=12545#12545
___
Wtr-general mailing list
Wtr-general@rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Fwd: Managing the Watir Project -- Wikipedia entry
Sun wrote: So while the code I posted in wikipedia may not be the prettiest -- it DOES work -- and works reliably. Exactly. Sorry i wasn't clear. The embarrassing thing to me is that you have to write non-pretty to code to make Watir work sometimes. (You could make the code i wrote work somewhat better if you add a require 'watir/dialog' to it, but it still has serious reliability problems.) Bret ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Fwd: Managing the Watir Project -- Wikipedia entry
Sun, Thanks again for the Wikipedia article. It is helpful in many ways to have this information written up. I am happy that you wrote it (or expanded it). Bret ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Fwd: Managing the Watir Project -- Wikipedia entry
Thank you for taking the time to do this. I do have a comment that i hope you won't take personally. I find code like this to be rather embarrassing:It's wikipedia, you can edit it. :) ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
