I've chatted with Mark offline about what it would take to merge
Class::Trigger and the callback functionality in CGI::App. Before I
start submitting and code patches to that end I wanted to run what I
was thinking by the list.
The implementations of both are remarkably close that I don't see any
major hurdle why this can't and shouldn't happen. (Feel free to
disagree.) From reviewing the code and documentation of both
implementations I've noted a handful differences.
* Methods names. We say callback they say trigger.
The method signatures are the same though so this can easily be
remedied in CGI::App with an alias.
* Hooks in CGI::App are case insensitive while Class::Trigger are case
sensitive.
I can suggest this change. This could also be remedied by overriding
logic if necessary otherwise.
* add_callback will accept a scalar that maps to a method name while
add_trigger accepts code references only.
Once again I can suggest this change, however it can be just as easily
implemented in CA with a bit of overriding.
* Hook registration.
Class::Trigger only explicitly supports hooks being added when
Class::Trigger's use is declared. CGI::App's new_hook method allows
for hooks to be declared (essentially) at any given time.
Rather then add a method to Class::Trigger I would propose that the
new_hook method in CGI::App handle working with Class::Trigger's class
data in declaring new hooks. Or should I propose a new_trigger method
be added to Class::Trigger? I could go either way here really.
* Triggers/callbacks fetching.
This is the most substantial difference. Class::Trigger fetches either
object OR that object's class. CGI::Application fetches the object AND
the entire class hierarchy of that object.
This logic can be easily added of course, but inserting that logic
without penalizing other Class::Trigger users isn't as straight
forward. What I'm considering is a "deep" fetch method that could be
optionally run to execute triggers/callbacks as CGI::App does with a
boolean flag. Since Class::Trigger is a mix-in I'm thinking the way
to go with that boolean flag is as a class::data accessor. In
Class::Trigger that would like something like....
sub __fetch_triggers {
my $proto = shift;
return ((ref $proto and $proto->{__triggers}) ||
$proto->__triggers) unless $proto->__deep_exec;
# __deep_exec would default to false (undefined)
# CGI::App like deep execution code here.
# walk object and class hierarchy assembling the
# return array.
}
Thoughts on this?
--
Timothy Appnel
http://www.timaoutloud.org/
---------------------------------------------------------------------
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]
