I like half your idea and hate the other half :o) I like the idea of using a persistent object to overcome deficiencies in plug-ins. That's easy with a singleton object in MyApp::Base class data blessed into C::A. I like the idea of separating your application logic from the structures in CA and using CA as an event handler to drive your application's code.
Trouble is, CA isn't wonderful as an event handler, and it doesn't do much other than marshal a CGI-compatible per-request object and manage callbacks. So it seems like a lot of clunkiness to manage all that to-and-fro just to workaround some plug-ins that should be considered broken (or at least 'deficient'). Do you have a list of the plug-ins that are causing you problems? I bet we could fix them one by one pretty quickly. There's another reason your framework wouldn't win me over -- it only handles the situation where a singleton is sufficient. With class data there's already a natural hierarchy (in fact there are two, but I'll avoid going off on a tangent) so it's natural to override those branches of the application data tree where appropriate. An example is cacheing prepared templates -- most of your application might use a common template, but one set of modules (eg the 'admin' part of the app) wants to override that template with another template -- that almost comes for free with class data. cheers-n-beers, Nic ##### 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/ ## ## ## ################################################################