On 6/18/05, Rhesa Rozendaal <[EMAIL PROTECTED]> wrote: > I've taken some time to see if I could rewrite the hook system with > Class::Trigger, and it works except for all the tests in t/11callbacks.t > (due to the different order in which callbacks are executed):
Cool > Before I continue, can I ask some questions about some of the design > decisions you guys made? > > - add_callback() accepts both a coderef and a string. Class::Trigger > only accepts coderefs. Why did you decide to accept sub names as well? I did this because runmodes accept a string or a coderef, so it would be consistent with the rest of CGI::Application. Also, it makes subclassing easier. > - CT doesn't have the analog of new_hook(); it just creates the hook > point when add_trigger is called for the first time. That looks sensible > to me at first sight. What was the reason for the explicit new_hook()? To me it acts more like 'use strict'. It catches typos and silly mistakes that can be very hard to track down. > - CT says it executes hooks in the order they were registered. I _think_ > this may be a drawback for us in the long run, as it doesn't give us > control over the execution order at all. On the other hand, Mark decided > to avoid the entire issue for now. The new callbacks work like a FIFO as well. First registered gets executed first. But that is at the package level. We also walk up the inheritance tree and execute all calbacks registered in any parent classes. So to be clear, the order is determined by the order in which you register at each package level, and the order that the packages are in the inheritance tree. (Not sure if that made sense) > I'd like to stress that it's not my intention to change the current > implementation. I'm just curious to see if I can get it to work with an > already existing framework for triggers. > I've read the posts that mentioned CT in the archives. It seems the > execution order was the big thing back then, which is why it had never > been seriously considered. I think that is right. The execution order was heavily influenced by mod_perl, and since CT didn't support that, I never looked at it seriously. But in the end we went with a simple implementation that we could build on later. > As Mark noted quite correctly, it would add a dependency that many users > wouldn't need. Then again, the callback code is _in_ cgiapp now, so that > may not be such a big objection anymore. Dependancies don't worry me that much, as long as we are using 60-80% of the functionality of the module. If we are using a tiny piece of a huge module, then I might speak up against it. > So far this is just a weekend excursion for me. If there's any feedback, > I might start to take it more seriously :-) Thanks for looking into it. I don't think all of this is set in stone yet (but the cement is drying fast). We have a basic system of callbacks in place that I think will work for most people. It will take some time to cater to every possibility though. Cheers, Cees --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
