I do a lot of Movable Type work and some CGI::App work too. Their application model are virtually identical, thought the implementations vary. CGI::App makes less decisions for the developer and is therefore more flexible, but MT::App (CGI::App's object equivalent) packs in a lot more functionality, some of what is being discussed here as future additions to the package.
Recent releases of MT implemented callbacks which from what I can tell are more specific implementations of triggers. (Reading the definitions[1,2] on Wikipedia does clarify a difference really.) I've looked at Class:Trigger in the past because I've become accustom to making my apps extensible using the callback/trigger model now. I think adding them is a great idea. I'm not sure if MT's implementation is the right thing for CGI::App (more on that at the end), but I thought I'd explain how MT does it as food for thought.
(This is loosely adapted from a tutorial I've written and not released on the topic yet.)
--
Movable Type implements two classes of callbacks -- object and application types.
MT uses an object-oriented model coupled with a database abstraction layer for working with any application data. In true OO form all of these data objects inherit from one base class. This base class has all the BREAD methods and in those methods are checks for callbacks. These callback events are call things like pre_load, post_load, pre_save, post_save etc. (These are not applicable to CGI::App other then the naming of pre_(event) and post_(event) as Mark was just discussing.)
More recently MT added application callbacks. These are "special" events in a specific application built on the MT core. MT's implementation of these are a bit selective based on what they thought a developer would like to hook. (In addition to these I wish they would have implemented something more generic like a pre_(runmode) and post_(runmode), but they haven't yet.) These are more applicable to CGI::App and its developers.
Registering a callback follows the general form of:
CLASS->add_callback($name,$priority, $plugin, \&code);
The first argument is the name of the callback hook to attach. Typically you'll use a literal value rather then a scalar like $name.
In all actuality, MT keeps a single registry of all callbacks for all parts of the system. All of these add_callback methods are actually aliases that were added for API clarity.
Here is one area were Class::Trigger and what is being discussed here varies. Each hook can have multiple callbacks attached to it. Since each hook can have multiple callback routines associated to it, the relative order in which the callback is called must be defined. Here $priority is an integer between 1 and 10. MT will run callbacks in
ascending order so priority 1 routines will be called before 2 and so on. MT interprets a priority of 0 and 11 (they admit this is a nod to Spinal Tap) as "must run first" and "must run last" respectively. Only one callback per hook can use one of these priorities, otherwise an error is thrown. Determining the correct priority is a matter of thinking about your plugin in relation to others, and adjusting the priority based on experience.
Another area were MT varies is that it create a simple object container for callbacks -- most for error handling and data encapsulation. $plugin and "\&code" are the two parameters used to create the "MT::Callback" object. $plugin is actually a MT::Plugin object which the system uses for similar reasons. This is probably going too far for CGI::App's purposes.
Here are two "real" callback registration commands.
# register an object callback to run after an entry save
MT::Entry->add_callback('post_save',5,$plugin,\&code); # register an application callback to run before a file
# is written
MT->add_callback('BuildFile',1,$plugin,\&code);All callbacks are run with an eval and generally will not stop operation if the application if they fail. Some can though based on their purpose.
--
Enough about MT now. I guess what is appropriate from all of this depends on the purpose of these triggers/callbacks (I prefer callbacks because triggers reminds me of database development and not applications) in CGI::App. Are they for the developer of the applications use only OR are they also there to give other developers the option of extending/hooking the original authors code? If its the former then Class::Trigger as proposed would do the trick and all that is needed is a discussion of where (if any) CGI::App will implement callback events. If its the later, then the priority scheme needs to be a consideration.
Thoughts?
Hope this helps and the long post was worth it.
<tim/>
[1] http://en.wikipedia.org/wiki/Trigger [2] http://en.wikipedia.org/wiki/Callback_%28computer_science%29
--------------------------------------------------------------------- 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]
