> -------- 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 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
Watir now has a contrib directory with both the enabled_popup method
and the visible? method for controls that you've added. Both of these
provide great examples for extending Watir to provide additional
functionality. I'd agree that peer review and suggestions are
important as we move towards the next release, particularly in making
api changes, we need to start disussing these in the Watir development
list for those who are interested.
Thanks David,
Charley
_______________________________________________
Wtr-general mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wtr-general
