Comments inline
Bret Pettichord wrote:
I wanna hear from the WET guys on this. Satti? Raghu?
There are two parts of the problem.
1. Just click the buttons and working the controls. WET has this licked.
2. Avoiding the thread-locking. WET uses a method similar to our
IE#remote_eval. But i have ideas on how to make this better.
Are you suggesting that every method call (or atleast the clicks,
sets,etc.) will be called in a separate process?
If yes, I am concerned that this may not be the intended behavior
always. Most of the times the desired intention
may be to wait for current line of invocation before moving on to the
next line. I think that making this choice between
invoking a method call in a separate process should be left to the
tester. Say, the click method could take an
optional parameter:
Click(inprocess=true)
{
}
The second point that we need to be careful about when invoking methods
out of process is the 'object identification'. We
need to make sure that the object identified when called in a method
'outofprocess', is exactly the same as the object on
which the method was invoked. This could be slightly tricky (and usually
source for errors). Consider this - If you have
a web application whose browser title is 'FooBar' and this browser opens
more browser windows with the same title.
Making an assumption that the outofprocess method call should look for a
browser with the title of 'FooBar' is clearly
a source for errors.
My two cents.
Bret
At 05:36 PM 8/17/2005, Jonathan Kohl wrote:
> 4. rip out winclicker and autoit and use wet/winobjects
> instead
+100
We need a good solution for modal dialog boxes, alerts, popups, etc.
This is
the feature I get asked about most frequently (even just a couple of
hours
ago).
-Jonathan
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bret
> Pettichord
> Sent: August 17, 2005 4:32 PM
> To: wtr-general@rubyforge.org
> Subject: [Wtr-general] next steps
>
> 1. finish purging all camelCase names in methods and local
> and instance variables.
> 2. finish renaming stuff that has the wrong name (like all
> the references to containers called 'ieController') 3.
> separate logic for locating objects (get_object) so it can be
> configured separately without having to what the WET people
> did (change overriding syntax).
> 4. rip out winclicker and autoit and use wet/winobjects
> instead 5. make it so that anything that be a container;
> refactor different methods currently used for this (frames & forms)
>
> and then
>
> 6. defer invokation of COM calls until necessary
>
> I've been pushing us this way for a while and believe that it
> is more important than ever. The simplest example of what
> this means is that code like this will work:
>
> table = ie.frame(:name, 'foo').table(:index, 4)
> # do stuff
> table[3][4].button(:index, 1).click
>
> This is convenient and often what casual users expect.
> Currently watir supports this to one level only.
>
> Once we have this, this gives us a platform that we can do
> several other
> things:
> a. invoke method in a separate process, so we never run into
> thread blocking problems again.
> b. invoke selenium or xcom/mozilla or another browser-driving
> technology instead of IE/COM c. attach a logger so we get
> cheap, decent, accurate logging
>
>
>
> _____________________
> Bret Pettichord
> www.pettichord.com
>
> _______________________________________________
> Wtr-general mailing list
> Wtr-general@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-general
>
_______________________________________________
Wtr-general mailing list
Wtr-general@rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general
_____________________
Bret Pettichord
www.pettichord.com
_______________________________________________
Wtr-general mailing list
Wtr-general@rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general
_______________________________________________
Wtr-general mailing list
Wtr-general@rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general
