Re: Application-wide configuration

There's no need for subclassing.
There's no reason to accept a reference.

use strict;
use warnings;

package Config::Once;

use Config::Auto;

sub init {
        my ($class, $config_path) = @_;
        ...
}

sub cfg {
        my ($class, $param) = @_;
        my $config_varname = $class . '::Config';
        no strict 'refs';
        return $$config_varname->{$param} if (defined $param);
        return $$config_varname;
}

1;
[download]

From the main program to initialize:

Config::Auto->init($config_path);
[download]

From anywhere to get data:

Config::Auto->cfg('varname');
[download]

Comment on Re: Application-wide configuration Select or Download Code

Replies are listed 'Best First'.
Re^2: Application-wide configuration by akho (Hermit) on Jul 27, 2007 at 18:57 UTC
Subclassing is there so that the modules are slightly more reusable (I use this Config::Once in several applications; don't want to pollute it). If we don't need that, we can also drop `no strict 'refs'` and just do `use strict; use warnings; package Config::Once; use Config::Auto; our $Config; sub init { my ($class, $config_path) = @_; ... } sub cfg { my ($class, $param) = @_; return $Config->{$param} if (defined $param); return $Config; } 1;` [download] And the `ref` was reflectory. Most probably not needed. That's not to the point, though.	[reply] [d/l] [select]
Re^3: Application-wide configuration by ikegami (Patriarch) on Jul 27, 2007 at 19:04 UTC
The only think I can see subclassing be useful for is if you have to deal with more than one configuration file per application. I read the problem as needing to have a single config file shared by many modules. Reusability is not affected. Any other application that needs to have a single config file shared by many modules can reuse this module.	[reply]
Re^4: Application-wide configuration by akho (Hermit) on Jul 27, 2007 at 19:24 UTC
People have different approaches. But I meant a situation like this: I have two applications, each of them uses a database. Database name and other credentials are stated in separate configuration files. So, each of their configuration files contains a parameter named 'database'. If I later want to reuse ORM classes from both applications in a new application, I will not be able to do this if they use the same Config::Once class. (I will necessarily have several configuration files too, of course). That's what I meant by 'reusability'. This is probably ugly, but such thing happen. There may also be problems with separate web applications running under mod_perl (won't they share the same perl process and the same Config::Once, too?), though I may be mistaken. So I think simply using Config::Once everywhere is slightly easier, but may turn out to be a problem in some corner cases. Subclassing is a better practice. This is not very different from, say, common practice using Rose::DB.	[reply]