Quoting William McKee <[EMAIL PROTECTED]>:
> On Fri, Sep 24, 2004 at 02:01:35PM +1000, Cees Hek wrote:
> > Sounds good to me. The MIDDLE or DONTCARE are really the default, so
> > they could be eliminated as well. ie specify FIRST or LAST, or leave
> > blank for the default.
>
> Couldn't MIDDLE/DONTCARE/default be synonmous? That would keep the
> design in sync with the Apache inspiration while also appeasing Mark's
> request for more accurate nomenclature.
Good idea. I'll see how feasable that is.
> > What this is doing is registering the default hooks. VALID_HOOKS
> > contains (cgiapp_init cgiapp_prerun cgiapp_postrun teardown), so in
> > effect we are registering the function 'cgiapp_init' in the
> > 'cgiapp_init' hook. So when call_hooks is called for the 'cgiapp_init'
> > phase, the standard 'cgiapp_init' method is also called.
>
> But if all the standard callback are being called in the default hooks
> (not sure if I'm using the right terminology there so let me know if
> that doesn't make sense), how do you control the order? I thought that
> was one of the issues under discussion.
The terminology is somewhat confusing, and I've confused myself a couple of
times while writing these messages to the list :). Here is how I see it:
A hook is a place in the execution path of a program where you can execute a bit
of your own code. So the cgiapp_init and cgiapp_prerun methods are examples of
hooks into the execution path of a CGI::App program. We are looking to add the
ability to execute multiple bits of code at each hook. I prefer to think of
these bits of code as callbacks. So we can register multiple callbacks at each
hook. We also want to be able to specify the order that the callbacks get
executed in.
So in the current system, we have 4 methods that act as hooks (cgiapp_init,
cgiapp_prerun, cgiapp_postrun, teardown). I think it might clear things up if
we actually call the hooks like this (init prerun postrun teardown), and then
refer to the default callbacks that are registered at those hooks as
(cgiapp_init, cgiapp_prerun, cgiapp_postrun, teardown).
So as an example, the cgiapp_prerun callback will automatically be registered at
the prerun hook with the default ordering (DONTCARE).
Now if later on in the code another callback is registered at the prerun hook,
it could be done like this:
$self->register_hook('prerun', \&my_prerun_callback, 'FIRST');
That will register the my_prerun_callback callback at the prerun hook and it
asks to be run FIRST in the order.
So when we get to the prerun stage of execution, the program will first execute
the my_prerun_callback callback, and then the cgiapp_prerun callback method.
I hope that clarifies the terminology a little bit. I am in the process of
solidifying these ideas in a couple of new plugins, and I hope to have these
available soon.
Cheers,
Cees
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
