At 01:48 PM 1/10/2002 -0500, Perrin Harkins wrote:
You can actually use subroutines without fear! Also, reducing the amount of
magic (i.e. all of that package generation and eval stuff that Registry
does) can help clear up confusion. And you can use __END__ and __DATA__.
Good point.
I
For file organization, I'm thinking of making all page modules start
with a common namespace substring (e.g. Projectname::Page) to distinguish
them from the support (model) modules
I like to name the top level modules SiteName::Control::* and the model
modules SiteName::Model::*. Calling the
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
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
Background:
I'm working on a site that is a mix of php (which I'm gradually converting to
mod_perl) and mod_perl (running under Apache::Registry and using Template Toolkit
(TT2)) using an apache configuration like this:
Directory /
[...]
Files *.par
SetHandler perl-script
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
used,
etc.). I'd like to find a way to prevent having that code (below)
