The configuration is active, the code caring about the configuration is stupid (well, the part that asks about configuration, anyway). Here is how it's done:

I have a namespace, MyApp::Config. MyApp::Config::Env provides environment probing data (MyApp::Config::Env->under_test will look at $0 to see if it matches /t/.+\.t$/, or $ENV{HARNESS_ACTIVE}), for the other modules.

Then, each module on it's own uses the Env module to provide configuration.

For example, the MyApp::Config::DBI will, under test, select PostgreSQL or MySQL, depending on which is on right now. This is done by instantiating little objects that score themselves, and having a singleton class whose constructor will simply select the best scoring one of these.

Under production, the One True Database is chosen, and otherwise an error is generated.

This functionlity is important, IMHO, to make the app work well, but it doesn't belong in the Real Code. Given global variables, the flexibility is limited, though.

I do it by using class methods - Config::DBI->dbh delegates to the object that was chosen, asking it to make a new database handle.

This goes further though, I also have configurating objects. For example, I have a class which runs a command line program. It cares about the interaction with the program, but not the program itself. This program has some variations, depending on the input data, the environment, and so forth. The configurator objects uses MyApp::Config::Env to see what the command should be, and then when MyApp::Config::ThatProgram->configure($obj) is called, the $obj, which is responsible for posessing the app, is modified to suite the environment.

Separating configuration from logic has made my app pretty maintainable so far, with a lot of space to grow.

Basically, what I suggest is to stop passing around data, and make a central point to get configuration data from. If there are complexities with who gets what, then that central point should be smart to resolve these differences, and real code shouldn't care.

You don't lose any flexibility, but what you gain is simplicity of the important code. This comes at a cost - the configuration code might be leaning towards magic, or become complex, but usually this code is quite linear to write, and the clarity of the real logic is, IMHO, well worth it.

Ciao!

Wow - serendipity. I'm in a similar situation, just starting to get my mind around this same problem - having the module/app "know" which backend is up.

Any chance I could take a peek at your solution? The idea of "little objects that score themselves" intrigues me...

Here's a sketch using a package variable:

  package MyFramework::DBIClass;

  sub setup { 
    $MyFramework::ActiveDBIClass->connect_database
  }
  
  ...
  
  package MyWebApp;

  $MyFramework::ActiveDBIClass = 'MyWebApp::DBIClass';
[download]

Oooh, that's really cool.

/me puts on his miner's helmet and prepares to dig...

use NYSCUL::ConfAssist qw(getDbConn loadConfig);

loadConfig("myconf.xml");

foo();

sub foo {
    my($db)=getDbConn("mydb");
    .
    .
    .

}
[download]

I've since stopped passing information around, and now call out to a specific module for the config information

This isn't working out too well though.

I still don't understand how to set things up (or even its its possible) to have the following

MyFramework
MyApp1::Config
MyApp2::Config
[download]

And have MyFramework::Namespace call out the correct MyApp1::Config or MyApp2::Config

Here are the key elements:
• The code in MyFramework must always refer to a variable (or other registry mechanism) to find the name or reference to use.
• At startup time (if each process only loads one application) or at the start of each request (if a persistent interpreter serves multiple applications), load the appropriate MyApp modules and store their names or references in the variables/registry.

It sounds like you've got the first but not the second.

This will likely sound silly -- but could this be approximated by specifying the configuration info in UNIVERSAL, and having apps look to it in there?