On Tue, Nov 06, 2012 at 03:32:13PM -0500, Mark Stosberg wrote: > > > You call init in BUILD, but then explicitly run down the callback list in > > the run() method. What I am wondering is if you could bridge the gap to the > > other side that would allow one to munge around with the *ordered contents > > of %CLASS_CALLBACKS. > > > > my %CLASS_CALLBACKS = ( > > # hook name package sub > > init => { 'PSGI::Application' => [ 'init' ] }, > > prerun => { 'PSGI::Application' => [ 'prerun' ] }, > > > > # for example, add > > authentication => { 'My::PSGI::Application' => [ 'authentication' ] }, > > authorization => { 'My::PSGI::Application' => [ 'authorization' ] }, > > > > postrun => { 'PSGI::Application' => [ 'postrun' ] }, > > teardown => { 'PSGI::Application' => [ 'teardown'] }, > > load_tmpl => { }, > > error => { }, > > ); > > > > Instead of me having to reimplement the run() method to provide for custom > > top level callbacks, would it be possible to craft run() so that it took > > %CLASS_CALLBACKS as ordered (e.g., if %CLASS_CALLBACKS was tied with > > Tie::Hash::Indexed) ? > > > > Right now, it seems like I'd have to reimplement the run(), when all I > > really wanted > > to do was insert top level callback classes wrt the order in which they are > > run. > > Brett, I think this existing functionality would provide what you want: > > PSGI::Application->new_hook('authorization'); > PSGI::Application->add_callback('authorization', \&callback);
Kind of, but what it doesn't allow me to do is affect the order in which the lifecycle hooks are executed. I think that I would also have to make a ->call_hook('authorization'), when what I really want to do is not only create the 'authorization' hook, but add it as a bona-fide lifecycle event like 'init', 'prerun', etc and choose at what point after 'init' is executed. > > That would register a hook named 'authorization', and register a > callback to fire the same as it would as if it were in the built-in hash. > > Or have I misunderstood the request? You're close. > > If need-be, we could make %CLASS_CALLBACKS, replaceable, but I want to > be first be clear that there's a need. That's really a subjective call, and not mine to make. I think that ultimately it'd be nice to be make the run() method general enough to where you can have a custom hook executed there in an order of your choosing, without having to call ->call_hook('foo') explicitly in your PAP instance. So, maybe something like this: PSGI::Application->new_hook('authorization','before','prerun'); PSGI::Application->add_callback('authorization', \&callback); Then run() would know due to some ordered notion of the default hooks that ->call_hook('authorization') would effectively get called 'before' the 'prerun' hook. I think of the hooks as stacks that contain registered callback methods. You get 'init', 'prerun', etc for free. And yes, you can create your own "stack" and registered callbacks to them. However, sometimes it would be really convenient if you could insert your own custom hook into the list of those that are implicitly called - it might particularly make it easier for plugins to better manage when and what they execute. Ultimately, I just want a way to create my own top level hook and not have to ->call_hook when I could just slide it into the lifecycle of events itself. Thanks for your consideration. Brett > > Mark > > ##### CGI::Application community mailing list ################ > ## ## > ## To unsubscribe, or change your message delivery options, ## > ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## > ## ## > ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## > ## Wiki: http://cgiapp.erlbaum.net/ ## > ## ## > ################################################################ > -- ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################