Submitted by richard on January 3, 2010 - 1:30am

Solar_Config is a great configuration system but at times you find yourself wanting more, by itself Solar_Config has a few weaknesses.

1. All the config is file based, changes to the config require a push.

2. If you store client config in Solar_Config files this makes #1 even worse

3. On a large site only small portions of the config may be used at once, why load it all into memory.

You have a couple options, each have highs and lows related to how they work

To understand how and were you can inject new config you have to understand how its loaded.

In your Solar.config.php

$config['Solar']['Config']['load_callback'] = 'your custom callback';

All this callback needs to do is return an array of data formatted the same as it would be within the Solar.config.php

So at this point all your Config glory is loaded into memory and ready for your classes to you... But what do you do if you want to load on a per class basis to save memory?

// When you extend Solar_Base the config gets injected during the __construct
// Which provides a _postConfig() hook. Extend Solar_Base and provide a _postConfig
class App_Base extends Solar_Base {

  public function _postConfig() {
    $class = get_class($this);
    $array = MyClass->getConfig($class);
    $config = array_merge($this->_config, $array);
    Solar_Config::setBuild($class, $config);
  }
}

This method provides the ability to inject config during class loading, reducing memory footprint in big installs.