I can definitely understand where McGrath is coming from… I’ve seen browser-based tools that rely on Javascript *too* much (e.g. a form won’t work unless it’s post-processed by an ‘onsubmit’ javascript event-handler).
That was preventing me from getting information out of some web-based tools because I couldn’t access them via a normal web-spider (in Perl, my preferred development language).
(As an aside, if you are writing web-spiders in Perl and not using WWW::Mechanize, it’s like you’re programming with an abacus.)
Win32-IE-Mechanize supports the WWW::Mechanize API while driving an IE browser!!!
The inadvertent blocking of information flow that a dependency of javascript caused can (usually) be sidestepped by just driving a browser directly.
I haven’t tried this technique with AJAX-heavy sites yet. But, I think this is a solid path to automation.
I imagine there are equivalents for Win32::IE::Mechanize for other languages (and while there’s a Firefox/Mozilla equivalent I couldn’t get it to install) since (I think) this module is really just a very thin layer on top of a InternetExplorer COM object.
So, in this case MS did something right… Jon, I hope you can help them continue 🙂
If you architect things allright, the AJAX interface would be innerhtml-xmlhttping a restian setup to get its data. Since one can orthogonally handle context and authorization through cookies and headers, the restian url can be exposed for composability whereas the ajax does the UI.
In other words, the UI ought to be a client for the restian interface. Hopefully, web2.0 platforms expose this in a systematic way.
A question though: can one extend this architecture so that the javascript UI can work offline, allowing ajax applications to be carried around. This would seem to need some caching and a local ‘replay’ web server which has a local copy of the data…
> For these two reasons — the transparency of the HTTP pipeline, and the accessibility of
> the JavaScript object model — I think that AJAX is inherently more automatable than conventional
> GUI apps ever have been.
Well you *would* say that. You work for Microsoft.
Jon's Radio Comments 
I can definitely understand where McGrath is coming from… I’ve seen browser-based tools that rely on Javascript *too* much (e.g. a form won’t work unless it’s post-processed by an ‘onsubmit’ javascript event-handler).
That was preventing me from getting information out of some web-based tools because I couldn’t access them via a normal web-spider (in Perl, my preferred development language).
(As an aside, if you are writing web-spiders in Perl and not using WWW::Mechanize, it’s like you’re programming with an abacus.)
After trying to imitate the actions (setting cookies, creating hidden fields) that javascript would have performed in Perl, I found this module:
http://search.cpan.org/~abeltje/Win32-IE-Mechanize-0.009/
Win32-IE-Mechanize supports the WWW::Mechanize API while driving an IE browser!!!
The inadvertent blocking of information flow that a dependency of javascript caused can (usually) be sidestepped by just driving a browser directly.
I haven’t tried this technique with AJAX-heavy sites yet. But, I think this is a solid path to automation.
I imagine there are equivalents for Win32::IE::Mechanize for other languages (and while there’s a Firefox/Mozilla equivalent I couldn’t get it to install) since (I think) this module is really just a very thin layer on top of a InternetExplorer COM object.
So, in this case MS did something right… Jon, I hope you can help them continue 🙂
Thank you for your time,
Daniel Fisher
Comment by Daniel Fisher — December 12, 2006 @ 5:15 pm |
If you architect things allright, the AJAX interface would be innerhtml-xmlhttping a restian setup to get its data. Since one can orthogonally handle context and authorization through cookies and headers, the restian url can be exposed for composability whereas the ajax does the UI.
In other words, the UI ought to be a client for the restian interface. Hopefully, web2.0 platforms expose this in a systematic way.
A question though: can one extend this architecture so that the javascript UI can work offline, allowing ajax applications to be carried around. This would seem to need some caching and a local ‘replay’ web server which has a local copy of the data…
Comment by Rahul Dave — December 12, 2006 @ 8:42 pm |
> For these two reasons — the transparency of the HTTP pipeline, and the accessibility of
> the JavaScript object model — I think that AJAX is inherently more automatable than conventional
> GUI apps ever have been.
Well you *would* say that. You work for Microsoft.
Joke… 😉
Comment by Jason R Briggs — December 14, 2006 @ 10:15 am |