I had originally suggested adding authentication and authorization stages in the life cycle of the application, and after looking at things it seems that your very close to having a general system that could make it easy to not only add hooks to callbacks, but to add and manage callbacks themselves.
So, I guess what I am suggesting is not to add authentication and authorization, but to make it easy for me as a programmer to add them as a top level CLASS_CALLBACK myself. You start with the rather arbitrary (but rational): my %CLASS_CALLBACKS = ( # hook name package sub init => { 'PSGI::Application' => [ 'init' ] }, prerun => { 'PSGI::Application' => [ 'prerun' ] }, postrun => { 'PSGI::Application' => [ 'postrun' ] }, teardown => { 'PSGI::Application' => [ 'teardown'] }, load_tmpl => { }, error => { }, ); 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. Thank you, Brett On Tue, Nov 06, 2012 at 01:36:07PM -0500, Mark Stosberg wrote: > On 11/06/2012 12:27 PM, Kurt Lidl wrote: > > On 11/6/2012 12:24 PM, Mark Stosberg wrote: > > > >>>> * Hash keys for new() must now be upper-case now. > >>> > >>> Ridiculous. Lower case hash keys are the norm throughout Perl. > >>> > >>> Upper case is SHOUTING. > >> > >> I agree that lower case hash keys are the norm and upper case hash keys > >> are shouting. The choice here weas a nod to compatibility with > >> CGI::Application, which internally was case-insensitive, but by > >> convention, everyone has been using the upper-case keys. > >> > >> I'm open to reconsidering this point as well, as I would prefer > >> lower case going forward myself. Perhaps the upper-case support can be > >> pushed into a ::Compat transitional module. > > > > I'd vote for lower-casing them, if you're looking for feedback. > > I am looking for feedback. Thanks for the opinion. > > 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/ ## ## ## ################################################################