Hello,
I have another new CGI::App plug-in I'd like some feedback on. This one
takes make management of config files and variables super easy. Check it
out:
###
SYNOPSIS
use CGI::Application::Plugin::ConfigAuto (qw/cfg/);
# In your instance script
my $app = WebApp->new(
PARAMS => {
# Read in the config files, in the order they appear in this array.
config_files => ['../../config/config.pl'],
}
);
sub my_run_mode {
my $self = shift;
# Access a config hash key directly
$self->cfg('field');
# Return config as hash
%CFG = $self->cfg;
}
DESCRIPTION
CGI::Application::Plugin::ConfigAuto adds easy access to config file
variables to your CGI::Application modules. Lazy loading is used to
prevent the config file from being parsed if no configuration variables
are accessed during the request. In other words, the config file is
not parsed until it is actually needed.
###################
Full docs:
http://mark.stosberg.com/perl/config-auto.html
Download:
http://mark.stosberg.com/perl/CGI-Application-Plugin-ConfigAuto-0.02.tar.gz
#####
I've been using a variation of this system for over a year, and it makes
things nice in a number of ways:
- It supports having a global config file with local overrides. This is
ideal for a large project that has sub-projects.
- The Perl config file format can make it really easy to manage configs
for multiple developers, plus beta and production versions. For
example, here's a real snippet from a config file on a recent
project:
# developers and the alpha site share a cache directory
if ($ENV{DEVMODE} =~ m/matt|mark|chris|alpha|evan|clientdesign/) {
$CFG{CACHE_DIR} = '/home/client/externals/alpha/cache';
}
elsif ($ENV{DEVMODE} eq 'beta') {
$CFG{CACHE_DIR} = '/home/client/externals/beta/cache';
}
elsif ($ENV{DEVMODE} eq 'production') {
$CFG{CACHE_DIR} = '/home/client/externals/production/cache';
}
You can see that an environmental variable is used to control which
configs are used. This is an idea I got from Jesse Erlbaum.
The big deal here is that there is /ONE/ config file in CVS. It's not
like each "dev mode" has it's own config file which is constantly
getting out of sync. I used to use seperate config files for each
"devmode" and it was a mess to keep up with.
The DEVMODE can be defined in an Apache configuration, your shell
environment, or even in a simple Devmode.pl which contains a single
line:
$ENV{DEVMODE} = 'mark';
I used the DEVMODE system to define a "modperl enabled" version of
the site for myself, and one that was. This seemed to speed up
development, as we could generally work without modperl, and
then at intervals try our test suite with modperl enabled.
This worked well in part because there were rarely modperl-specific
issues that came up. When they did, it was easy to test in both
environments to see if the bug was in fact specific to modperl or
not.
Ok. I'm digressing. I would welcome some feedback on the module, even
if you don't care about the rest of my development paradigm!
Mark
--
http://mark.stosberg.com/
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
