Michael Peters wrote:
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...
Not as far as I'm concerned. I plan to write a more definitive evaluation of Class::Trigger, but the redux will be "never mind" anyway.
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).
Yes. In effect, all current callbacks are before_* triggers.
This limitation has already been reached with the C::A::P::HTMLTidy. It cannot process the final output if a teardown method is implemented.
Not quite correct. I would be able to make use of an after_postrun hook though. In any case, I have postponed a callback implementation pending the RFC period.
I'm not proposing something really complicated, but just a simple before/after mechanism. Besides the above, here is another use case...
I think if the core would contain additional after_* hooks right after every cgiapp stage, we'd be almost there. They would run with the same arguments as the existing hooks.
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') }
);
I suppose you could implement this by doing:
$self->new_hook('after_config');
and make sure that _setup_config() calls that hook after it's done.
# now inside of my dbh plugin
$self->add_callback(
after_config => \&_setup_dbh
);
This would be called at the appropriate time now.
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.
I think we can achieve that to a great degree if we collectively agree on publishing our plugins' hook points. If we additionally promise to add hook points to our plugins as well, all plugins should be able to work together and play nice. In your use case, your plugins would also register a before_config, and a before_dbh and after_dbh.
So basically what I propose is:1) add after_init, after_prerun, after_postrun, and after_teardown hooks to cgiapp 2) agree that plugins register before_foo and after_foo hooks around their own hooks
That should provide us with enough granularity to make this all work, wouldn't it?
Rhesa
---------------------------------------------------------------------
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.