On 2004-09-28, Cees Hek <[EMAIL PROTECTED]> wrote:
>
> If we are looking for a way to simplify (and/or standardize) this patch,
> we could just drop the ordering option all together and just go by
> insertion order (like Class:Trigger does). It would then be pretty
> simple to use Class::Trigger to implement this patch. I am just worried
> that it could introduce subtle bugs where execution order is critical
> (ie closing a database handle before a session is flushed).
>
> An alternate solution would be to ask Tony to add ordering support to
> Class::Trigger.
Class::Trigger does seem to have ordering. Here's the example from the
SYNOPSIS:
sub foo {
my $self = shift;
$self->call_trigger('before_foo');
# some code ...
$self->call_trigger('middle_of_foo');
# some code ...
$self->call_trigger('after_foo');
}
So you can set up something things to run "before" other things.
If we used this, we would end up documenting it something like this:
CGI::Application->add_trigger(before_cgiapp_init => \&sub1);
[ Thinks. ]. Actually, doesn't this illustrate a problem with this technique?
The triggers are added in the CGI::App namespace. In a mod_perl environment,
you could end up with plug-ins you don't want. Maybe this would work?:
__PACKAGE__->add_trigger(before_cgiapp_init => \&sub1);
I think the syntax in Cees original patch seemed clearer, and I'm sure some
people will appreciate not adding an extra dependency for a feature that
may not be commonly used.
Mark
--
http://mark.stosberg.com/
---------------------------------------------------------------------
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]
