[Windmill-dev] https; file uploads; extjs and click support

[Adam Christian]

Comments inline,

On Dec 16, 2007, at 5:34 PM, Gary Poster wrote:

> Hi Adam and Mikeal, and thanks for your several replies.  I'm going  
> to try and assemble the points from all of the emails to which I  
> want to reply here, and hope that it still makes sense.
>
> First, the most recent, from Adam.
>
>> Gary,
>>
>> Again in this case, for the time being I am going to blame the  
>> JavaScript framework for stopping propagation in a way that makes  
>> recording these actions nearly impossible.
>
> Maybe we have a chance to set up a dialog between authors of a  
> browser testing framework and a JS development framework.  The  
> development framework is not stopping the propagation arbitrarily;  
> for instance, in the page I sent, clicking the checkbox div should  
> change the data value and display, but should not perform the usual  
> behavior of highlighting the grid cell in which you have clicked.   
> Stopping event propagation is a reasonable approach.
>
> But what could be better?  What could they do that would accomplish  
> what they need and what you could catch?  They could fire an  
> alternate event-ish thing when they stop the propagation, and there  
> could be an ext plugin for windmill to listen to it, perhaps.  Or,  
> what would you suggest? :-)  I'd like to bring this up with them,  
> and having some reasonable starter ideas can help technical  
> conversations along, and can also be a part of explaining what the  
> problem is.
>
Just to clarify, I don't mean "I'm blaming the JS Frameworks" in a  
negative way, I just meant for the moment I don't have a perfect  
solution to the various complexities provided by the web, so making  
things testable does partially fall on the developers for cooperation.  
I would love to work with all of them and come to some common ground.

I'm wondering if relying on the bubble/propagation behavior is such a  
good idea when it comes to web development in general, if you want to  
support Safari it isn't. All of the propagation issues simply don't  
exist in Safari because they are expecting the developer to attach the  
correct events to each of the nodes individually instead of a  
catchall. It appears that IE and Firefox both do support this, but  
they do it a bit differently.

I have no doubt that there is a good solution to this, I will keep  
investigating. If anyone has ideas please chime in!

>> However, I fixed a bug in the click function keeping it from firing  
>> the mousedown correctly which stopped it from playing back.
>
> Great!
>
>> So the solution for now is to click 'Add Action' and set the  
>> locator using the DOM explorer. As I said earlier, if you want the  
>> action to work in the future I would set the 'Use XPath only for  
>> explorer/recorder' when exploring this action, because those ID's  
>> change constantly.
>
> Yep, saw that too.  I'm hoping I can get some ideas on reliable  
> XPath spellings from the ext guys too.  If Windmill had a plugin  
> story, and one could say "ah, this is ext; try spelling your XPath  
> this way because this is the blessed, cross-release approach" that  
> might help.

Currently xpath should work as expected when recording and playing  
back in Firefox/Safari but I am still working on my own library for  
doing this in IE as currently the majority of the xpath lookups are  
failing. I hope to have this into the 0.4.0 release.

>
>
>> The fix is checked into the trunk and will be released in 0.3.6  
>> within the next few days.
>>
>> Sorry we couldn't make this work OOTB, but I will keep my eye out  
>> for a slicker fix for this rather large issue.
>
> Understood and thanks.
>
> Next, Mikeal, in regards to HTTPS.
>
>> I spent a good chunk of my weekend giving this another go.
>
> Thanks!
>
>> I finally know how Selenium does this. You have to generate a  
>> certificate for each target site and make the next socket  
>> connection after an HTTP CONNECT method respond with that  
>> certificate.
>
> I think sahi does the same thing, fwiw.
>
>> This means seriously tearing in to the server layer of windmill,  
>> which to date we don't actually control. We use cherrypy as a WSGI  
>> server, and the rest of our app works strictly at the WSGI  
>> application level.
>>
>> Supporting SSL is a huge amount of work -- significantly more work  
>> than anything else we're considering in windmill. We'll either have  
>> to swap out various cherrypy wsgi server components, write our own  
>> server, or move to a new server that provides us some way of  
>> getting at this layer. I do know that there is a working https  
>> proxy implementation in twisted, so it might be possible to mess  
>> with that.
>
> They also have some WSGI support, though my possibly misguided  
> impression from the sidelines there is that WSGI support is not a  
> top priority.  But it might still work, and might even be drop-in-ish.
>
> Finally, Mikeal, in regards to FileUploads:
>
>> Actually, what we want to try and do for this is set it in the  
>> browser via javascript.
>>
>> If we try to handle this on the backend (shoving the file stream  
>> into the multi-post stream) it's a HUGE hack and is extremely far  
>> from what a normal user would do. This also bypasses anything  
>> someone might have done with javascript and/or form validation on  
>> the browser.
>>
>> If there is no other way, i'll do it in the Service, but this is  
>> worst case scenario.
>
> Agreed that it's a hack, but...hey, if you figure out another way  
> that would be awesome. :-)  I don't think the browsers give you much  
> control at all over their FileUpload widgets.
>
> Thanks again to both of you.
Thanks for your patience, please keep mailing the list with any future  
woes!

Adam
>
>
> Gary
> _______________________________________________
> Windmill-dev mailing list
> Windmill-dev at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/windmill-dev