Cees Hek wrote:
On 6/17/05, Michael Peters <[EMAIL PROTECTED]> wrote:
Just so that I'm not misunderstood, I don't like either approach. Maybe
we should have the before_hook/after_hook hooks? So call_hook() would
execute the before_hook(), hook() and after_hook(). And these
before/after hooks would act just like normal hooks.
I think that would go a long way. What I'd like to see is, for every
hook point we have no, a set of before_foo and after_foo hooks.
I think I am starting to go hook crazy... And not crazy in a good way ;)
Bear with us, it's not as complicated as it seems :)
Let me see if I can decifer what you meant here with an example using postrun:
I'll go along with that.
cgiapp_postrun is the legacy method that implements the hook. We can
now register a callback at the 'postrun' stage, and they all run just
before legacy cgiapp_postrun method gets called.
yes.
What you are proposing is that we also allow the registering of a
callback after the call to cgiapp_postrun. Is that correct? That is
not as major a change as I initially thought when I read your comments
above.
I would suggest the following:
- a before_postrun hook
- an after_postrun hook
And then in CGI::Application, we'd have
$self->call_hook('before_postrun', @args);
$self->postrun(@args);
$self->call_hook('after_postrun', @args);
I would suggest doing the same for the other hooks as well. That way
plugin writers can choose where to run their code, either immediately
before the cgi-app stages, or immediately after.
That could be easily done (in a backwards compatible way) by having a
positional arguement to add_callback that is either 'before' or
'after' and it defaults to 'before'. This is only slightly different
from our first attempt using 'first', 'last' and 'middle', but I think
it is actually quite a bit clearer. It still doesn't really cover
strict ordering, but gives a bit more flexibility.
I don't think we need a positional argument just yet. Just increasing
the number of hook points should suffice for now, I feel.
I have another (admittedly radical) idea about dealing with ordering
of callbacks. If we created a method that allowed us to view a list
of callbacks that are registered, then when a callback is executed, it
could check to see if there are any more callbacks registered after
itself (ie am I the last callback or is there another one after me).
If there is another callback waiting, then this callback could
register itself again at the end of the list, and then return without
actually doing what it is supposed to do. Now the rest of the
callbacks go through, and we get to the last one again, and it now
executes as it normally would as the last callback (the callback must
make sure that it doesn't bump itself to the end more than once).
This idea sounds kind of dangerous to me, but might be workable in
extreme situations.
Sounds risky to me. It certainly destroys the logical flow of cgi-app,
and has the danger of introducing endless loops.
Using param() is fine for callbacks registered to an object, but what
about class based callbacks? You have to remember that you will not
always have $self to work with. So in that case you need to work with
Class variables (Globals).
I was concerned about that at first too. But then I realised that you
don't always need access to the data when you're registering callbacks.
Once your callbacks get called, you will have access to $self, and thus
to param() values.
That means even class-based hooks can be configured in the normal way;
either through params in the instance script, or by adding params in
setup() (that would be a good example where a post_setup hook could be
useful).
Rhesa
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
