At 09:09 PM 1/9/2002 -0500, Perrin Harkins wrote: >Normal Perl rules apply. Modules are good for sharing code. You could >stuff the shared parts into a sub in a module that every script would >call. Or you could use an OO approach, with a base class that holds all >of the boiler-plate stuff.
The question I'm having a hard time answering without going down both paths is: What are the basic advantages, disadvantages, and limitations of: (a) stuffing all this setup/framework code into a module (either a new module or subclassing Apache::RegistryNG as you mention below), versus, (b) stuffing it into a handler that all requests for a large subset of the pages on this site have to go? Both approaches achieve the same result of funnelling all requests through a common set of code, which is mainly what I'm trying to achieve, but other than being different implementations, I'm not real clear on how they differ. It would seem like the "put framework in a module" approach might be more flexible (esp. subclassing Apache::RegistryNG) because different scripts could take-it-or-leave-it or even modify it through further subclassing. On the other hand, then "common framwork in a handler" approach might be faster because it could do just what is needed by all pages but nothing more, and as long as there is not too much code wasted by differences in the needs of different scripts, it could be that less code is being loaded and executed. Am I missing other things here? >> One idea I had was to write a handler that acts as a sort of minimal >> application framework that contains the code below and determines what >perl >> module should be "require"d and executed based on $apache->path_info >and >> $apache->uri. > >That's a good way to go too. Moving from Apache::Registry to handlers >can be empowering. Other than the speedup from reduced overhead, what are the primary advantages to using handlers rather than Apache::Registry for content handlers? The primary disadvantage seems to be that I have to restart httpd an awful lot, but maybe Apache::Reload can help here. Can it be used to reload modules that implement handlers? >> This sounds like a substantial effort > >Only if your code currently depends on the CGI emulation features of >Apache::Registry. If it's clean code, you should be able to convert it >without much trouble. You could also try subclassing Apache::RegistryNG >and adding your setup code to the beginning of each request there. I will look into subclassing Apache::RegistryNG. This could be useful for other things as well. Maybe this is easier than what I'm picturing. I was thinking that writing the handler would be most of the effort, but it may be that it is mostly just designing an appropriate interface between the handler and the page code, re-partitioning the common code out of the "pages" and into the handler, and writing a simple dispatcher. Probably the biggest piece is the careful interface design so that future framework enhancements don't require changing old "page code". >> I'd appreciate any input on how other people are structuring similar >type >> applications in mod_perl, where the output is generated by Template >Toolkit >> based on data obtained via SQL queries using parameters received >mostly in >> the URL. > >I use handlers, with a model-view-controller design. The approach is >documented in my Perl.com article about the eToys design. I keep all >the common setup stuff in a base class that the other controllers >inherit from. This is a very helpful article. I have read it several times and still keep coming back to it. I would also like to learn more about the "model-view-controller" approach in general. >- Perrin Matthew Pressly
