[Webtest] [dev] support for js confirm()...

[Paul King]

I could try to modify the following extension to work with the HtmlUnit 
version of webtest:

   http://webtest-community.canoo.com/wiki/space/DialogSteps

I was waiting for things to stabilise a little but I guess now is as 
good a time as any.

It generalises verifyAlertText (with verifyDialogText) but also provides 
a setConfirmDialogDefaults task which is called prior to calling 
clicklink or clickbutton. It currently (in the HttpUnit version) 
registers itself as a DialogListener. I guess it would now need to 
register itself as a ConfirmHandler.

It currently has a "stack size" of 1 - but does support whether the 
Dialog should be dismissed or not. If multiple Dialogs can be invoked 
from a single clicklink or clickbutton and they need to have different 
responses (i.e. not all "OK" and not all "cancel") then we would need to 
generalise this to a stack of responses. I can have a look at that too 
if there is interest.

Paul.



Marc Guillemot wrote:
> Hi Costin,
> 
> 
>>> What do you think (I can develop more if needed)?
>>
>>
>> Why do you need two threads? Isn't that going to make the architecture
>> more complex? 
> 
> 
> it does, but if we can find a better solution, I'm interested in.
> 
>  > Why not enable some sort of interceptor (additional
> 
>> plugable layer) for the javascript functionality?
>>
>> If the button or link has some javascript properties, the
>> 'interceptor' will check the condition and affect the overall result.
>>
>> On short, in our project we had this 'places' where the user could
>> insert certain conditions in the workflow - to deal with them we
>> created a stack of event, user configurable, that were executed before
>> the result was concluded by the same thread.
>>
>> Just an idea..
> 
> 
> the problem is as follows:
> 1- the execution of a clickbutton (for instance) calls webPage.click(...)
> 2- this trigers the execution of a javascript:confirm
> 3- htmlunit calls back the ConfirmHandler we have registered
> 
> what to do now:
> we are always in the <clickbutton> step and we have to terminate it 
> before executing the next step. With  2 threads, the "webclient" thread 
> could start sleeping in the ConfirmHandler until we notify it that is 
> has to check for a js confirmation. With a single thread... it would 
> require that the ConfirmHandler knows what to do before the 
> <clickbutton> step terminates. In other terms that a step (the 
> <jsConfirm>) gets evaluated before the previous step in the queue (the 
> <clickbutton> step). Quite complex. I think that in this case 2 threads 
> would reduce the complexity, but perhaps can you convince me that I'm 
> wrong.
> 
> Marc.
> _______________________________________________
> WebTest mailing list
> WebTest@lists.canoo.com
> http://lists.canoo.com/mailman/listinfo/webtest
> 
>