> 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
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 star
> 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
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.
> 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 (bel
