> There are many *.par pages (estimate: 70-100 when conversion is complete), > and they all contain the following code with minor variations that could be > made consistent (like what constants are imported, what modules are "use"d, > etc.). I'd like to find a way to prevent having that code (below) show up > over and over again so I can eliminate a potential maintenance headache, but > I'm not sure of what's a good way to bundle it up for reuse.
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. > 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. > 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'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. - Perrin
