>
> Is there like a collection of Mechanize scripts out there? It'd be an
> awesome way to learn.
Read the docs. There are two collections of Mech programs that come
with Mech. Also make sure you read the FAQ about the part that says
you can't do JavaScript with Mech, because chances are you're going to
run into that.
xoxo,
Andy
--
Andy Lester => an...@petdance.com => www.petdance.com => AIM:petdance
> But Andy! What about the new Javascript changes!?
Oh yeah, those. Has anyone vetted them?
> really want to see it released ASAP.
That's good to hear. Anything you can do to test them out would be
helpful.
>
>
> On Sep 20, 2008, at 5:26 AM, Fayland Lam wrote:
>
>> really want to see it released ASAP.
>
>
> That's good to hear. Anything you can do to test them out would be
> helpful.
Actually, I’ve found a few problems myself. At first, in my naïveté, I
thought that a few hooks to attach the DOM were all that was needed;
and voila! you have scripting support. It turns out that there’s more
to it than that, because we need more complex history manipulation, a
sine qua non for testing Ajax applications. Anyway, here are the
problems I’ve found:
1) follow_link needs a callback hook (trivial)
2) The get_frame method is starting to bother me. I never use it. I
doubt anyone else will. A method to access the DOM more directly than
going through the plugin object would be more useful. I think what we
need is a way for plugins to add methods (via AUTOLOAD or some such),
but that can wait till a future release (Mech 3?). I’d like simply to
remove get_frame for now.
3) The history mechanism needs to be revamped. I’m currently working
on it. My own incoherent notes are pasted below, if anyone wants to
read them.
4) The uri method dies when no browsing has occurred. In DOMmy
browsers, it is set to ‘about:blank’. This is solved in my notes below.
Father Chrysostomos
---
_push_page_stack and _pop_page_stack need to run callback routines:
$mech->add_handler(push_page_stack => sub { ... });
(Or should it be push_stack or push_state [HTML 5 terminology]?)
We also need a push_state method, which adds random user data to the
page
stack, in which case we also need a way to distinguish between those and
actual Mech clones. Actually, we need it to *appear* that the current
page
is already on the stack. So push_state will set the Mech object’s
‘current
state object’, while pushing the previous one, or undef if there is no
state object, on to the stack.
The args to the callback rotines above would be
push/pop_whatever($mech, $state_obj if applicable )
$mech->push_state($custom_obj);
$mech->back(); # undoes it
When you go from http://localhost/ to http://localhost/#bar:
1. A modify_request handler is called, which sees that the URIs are the
same and
2. calls $mech->push_state({url => 'http://localhost/#bar'}), which in
turn
3. pushes the old state obj or undef on to the page stack and
4. calls a push_page_stack callback (we can put an unload hook here).
5. The m_r handler then aborts.
The back() method (or _pop_page_stack) then
1. Sets aside the current state object,
2. pulls the state off the stack, making it the ‘current state’, and
3. calls a pop_page_stack handler, passing in the reserved state thingy.
4. That handler will then trigger a hashchanged event.
A get_uri handler will have to check the current state object (so it
needs
to be publickly accessible) to see whether it has a URL, and fall back
to
->res->uri or about:blank.
Along with all that it makes sense to add a forward method, in
addition to
back. history_length (or stack_length/stack_height?) (and
history_position?) would also be nice.