Cees Hek wrote:
So in the current system, we have 4 methods that act as hooks (cgiapp_init,So, these are like Class::Trigger triggers?
cgiapp_prerun, cgiapp_postrun, teardown). I think it might clear things up if
we actually call the hooks like this (init prerun postrun teardown), and then
refer to the default callbacks that are registered at those hooks as
(cgiapp_init, cgiapp_prerun, cgiapp_postrun, teardown).
So as an example, the cgiapp_prerun callback will automatically be registered at
the prerun hook with the default ordering (DONTCARE).
Yes and no. The add_trigger and call_trigger seem to correspond well to the register_hook and call_hook methods.
The only real difference is the ordering that we define when we call register_hook (FIRST DONTCARE LAST). There is no way to specify an execution order in Class::Trigger. It executes the trigger in the order that the triggers were registered. The FIRST DONTCARE and LAST indentifiers are intended to give at least a hint as to the ordering, even though it is not a guaranteed ordering (if multiple callbacks are registered with the FIRST identifier, then insertion order is used for those callbacks).
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.
Cheers,
Cees
--------------------------------------------------------------------- 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]
