Ok,
I know we've sorta set this aside for a bit, but I'd like to bring it up
again and see if the consensus has shifted or not...
Right now the order of execution for callbacks is based on the class
inheritance tree which in turn is controlled by the order the user
'uses' the plugins. So, anything added to an existing callback would
always be run before the built in sub (ie, cgiapp_prerun, etc).
This limitation has already been reached with the C::A::P::HTMLTidy. It
cannot process the final output if a teardown method is implemented.
I'm not proposing something really complicated, but just a simple
before/after mechanism. Besides the above, here is another use case...
I am using both a config plugin and a dbh plugin. I don't really care
when the dbh plugin does it setup stuff just as long as it's after the
config. I would like to do this:
# in config plugin
# create my new hook
$self->new_hook('config');
$self->add_callback(
config => \&_setup_config
);
# set the new hook to run during the 'init' phase
$self->add_callback(
init => sub { shift->call_hook('config') }
);
# now inside of my dbh plugin
$self->add_callback(
after_config => \&_setup_dbh
);
Then my base class can simply:
use C::A::P::MyConfig;
use C::A::P::MyDBH;
And I never have to worry about calling any of those methods myself in
my base class or sub classes.
It seems to me that most use cases for plugin execution order aren't
about when something happens, but when it happens in relation to
something else.
--
Michael Peters
Developer
Plus Three, LP
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/suppressed/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.