koseven/system/guide/ko7/config.md

Configuration

By default Koseven is setup to load configuration values from config files in the cascading filesystem. However, it is very easy to adapt it to load config values in other locations/formats.

Sources

The system is designed around the concept of Config Sources, which loosely means a method of storing configuration values.

To read config from a source you need a Config Reader. Similarly, to write config to a source you need a Config Writer.

Implementing them is as simple as extending the [KO7_Config_Reader] / [KO7_Config_Writer] interfaces:

class KO7_Config_Database_Reader implements KO7_Config_Reader
class KO7_Config_Database_Writer extends KO7_Config_Database_Reader implements KO7_Config_Writer

You'll notice in the above example that the Database Writer extends the Database Reader. This is the convention with config sources, the reasoning being that if you can write to a source chances are you can also read from it as well. However, this convention is not enforced and is left to the developer's discretion.

Groups

In order to aid organisation config values are split up into logical "groups". For example, database related settings go in a database group, and session related settings go in a session group.

How these groups are stored/organised is up to the config source. For example, the file source puts different config groups into different files (database.php, session.php) whereas the database source uses a column to distinguish between groups.

To load a config group simply call KO7::$config->load() with the name of the group you wish to load:

$config = KO7::$config->load('my_group');

load() will return an instance of [Config_Group] which encapsulates the config values and ensures that any modifications made will be passed back to the config writers.

To get a config value from a [Config_Group] object simply call [Config_Group::get]:

$config = KO7::$config->load('my_group');
$value  = $config->get('var');

To modify a value call [Config_Group::set]:

$config = KO7::$config->load('my_group');
$config->set('var', 'new_value');

Alternative methods for getting / setting config

In addition to the methods described above you can also access config values using dots to outline a path from the config group to the value you want:

// Config file: database.php
return array(
    'default' => array(
        'connection' => array(
            'hostname' => 'localhost'
        )
    )
);

// Code which needs hostname:
$hostname = KO7::$config->load('database.default.connection.hostname');

Which is equivalent to:

$config = KO7::$config->load('database')->get('default');

$hostname = $config['connection']['hostname'];

Obviously this method is a lot more compact than the original. However, please bear in mind that using dot.notation is a lot slower than calling get() and traversing the array yourself. Dot notation can be useful if you only need one specific variable, but otherwise it's best to use get().

As [Config_Group] extends Array_Object you can also use array syntax to get/set config vars:

$config = KO7::$config->load('database');

// Getting the var
$hostname = $config['default']['connection']['hostname'];

// Setting the var
$config['default']['connection']['hostname'] = '127.0.0.1';

Again, this syntax is more costly than calling get() / set().

Config Merging

One of the useful features of the config system is config group merging. This works in a similar way to the cascading filesystem, with configuration from lower sources lower down the source stack being merged with sources further up the stack.

If two sources contain the same config variables then the one from the source further up the stack will override the one from the "lower" source. However, if the source from higher up the stack does not contain a particular config variable but a source lower down the stack does then the value from the lower source will be used.

The position of sources in the stack is determined by how they are loaded in your bootstrap. By default when you load a source it is pushed to the top of a stack:

// Stack: <empty>
KO7::$config->attach(new Config_File);
// Stack: Config_File
KO7::$config->attach(new Config_Database);
// Stack: Config_Database, Config_File

In the example above, any config values found in the database will override those found in the filesystem. For example, using the setup outlined above:

// Configuration in the filesystem:
    email:
        sender:
            email: my.awesome.address@example.com
            name:  Unknown
        method: smtp

// Configuration in the database:
    email:
        sender:
            email: my.supercool.address@gmail.com
            name:  Kohana Bot

// Configuration returned by KO7::$config->load('email')
    email:
        sender:
            email: my.supercool.address@gmail.com
            name:  Kohana Bot
        method: smtp

[!!] Note: The above syntax is simply pseudo code to illustrate the concept of config merging.

On some occasions you may want to append a config source to the bottom of the stack, to do this pass FALSE as the second parameter to attach():

// Stack: <empty>
KO7::$config->attach(new Config_File);
// Stack: Config_File
KO7::$config->attach(new Config_Database, FALSE);
// Stack: Config_File, Config_Database

In this example, any values found in the filesystem will override those found in the db. For example:

// Configuration in the filesystem:
    email:
        sender:
            email: my.awesome.address@example.com
            name:  Unknown
        method: smtp

// Configuration in the database:
    email:
        sender:
            email: my.supercool.address@gmail.com
            name:  Kohana Bot

// Configuration returned by KO7::$config->load('email')
    email:
        sender:
            email: my.awesome.address@example.com
            name:  Unknown
        method: smtp

Using different config sources based on the environment

In some situations you'll need to use different config values depending on which state KO7::$environment is in. Unit testing is a prime example of such a situation. Most setups have two databases; one for normal development and a separate one for unit testing (to isolate the tests from your development).

In this case you still need access to the config settings stored in the config directory as it contains generic settings that are needed whatever environment your application is in (e.g. encryption settings), so replacing the default Config_File source isn't really an option.

To get around this you can attach a separate config file reader which loads its config from a subdir of config called "testing":

KO7::$config->attach(new Config_File);

KO7::$config->attach(new Config_Database);

if (KO7::$environment === KO7::TESTING)
{
    KO7::$config->attach(new Config_File('config/testing'));
}

During normal development the config source stack looks like Config_Database, Config_File('config'). However, when KO7::$environment === KO7::TESTING the stack looks like Config_File('config/testing'), Config_Database, Config_File('config')