On 2004-09-24, Cees Hek <cees-6dSDdTwHM5kJY7gZg3T8ig@xxxxxxxxxxxxxxxx> 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.
I was thinking that FIRST and LAST and "null" would be highlighted in
the documentation, although the position would remained named DONTCARE.
>> - There's something I don't understand in the patch, which looks like a
>> bug to me:
>>
>> # clean up operations
>> - $self->teardown();
>> + #$self->teardown();
>> + $self->call_hooks('teardown');
>>
>> This seems to indicate that "teardown()" is no longer called at all,
>> which didn't make sense to me.
>
> This is not actually a bug. If you look at the top of the patch you
> will see the following line:
>
> # Setup the default callbacks
> $self->register_hook($_ => $_) foreach VALID_HOOKS;
>
> 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.
Thanks for clarifying that.
>> - Would it be true that "call_hooks" could be considered a private
>> method? It seems like something a normal users would never use, and
>> it would simply the docs a bit to exclude it there.
>
> Yes, I would think so. However, I can see a plugin adding a new hook
> into CGI::App, and hence it would need to call 'call_hook' in that case.
It could also be tucked away in the "plug-in" documentation area then.
> If you look at the new C::A::P::TT module, you will see that I added two
> new hooks specific to that module (tt_pre_process and tt_post_process)
> that get called before and after a template gets processed. These hooks
> get called during every call to tt_process. But they work like the
> current hooks in that you can only have one method that is called
> (unless you play with SUPER::). If we carefully craft the patch, we
> could make it possible to have the hooks system extensible so that new
> hook locations could be added through plugins.
I wonder if this would work from a plug-in:
use constant CGI::Application::VALID_HOOKS
=> qw( cgiapp_init cgiapp_prerun cgiapp_postrun teardown );
Otherwise, moving from constants to globals would allow this:
# In CGI::App
use vars qw/@VALID_HOOKS/);
@VALID_HOOKS = qw( cgiapp_init cgiapp_prerun cgiapp_postrun teardown );
# In Plug-in
@CGI::Application::VALID_HOOKS = qw( my custom list );
Using globals may also have other minor advantages: slightly less overhead,
and removed dependence on 'constants' support. (I don't know when it became in
core).
Really though, whether or not the 'constants' style is used is not a key point
for me.
Mark
--
http://mark.stosberg.com/
---------------------------------------------------------------------
Web Archive:
http://www.mail-archive.com/cgiapp-svx1JCNWaqPWzzAP45jFb16hYfS7NtTn@xxxxxxxxxxxxxxxx/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail:
cgiapp-unsubscribe-svx1JCNWaqPWzzAP45jFb16hYfS7NtTn@xxxxxxxxxxxxxxxx
For additional commands, e-mail:
cgiapp-help-svx1JCNWaqPWzzAP45jFb16hYfS7NtTn@xxxxxxxxxxxxxxxx
|
