Hi,
I also would like to have this has a new feature in this update :
Description
=========
The configuration package could be able to store and retreive assoc arrays.
Example
=========
Consider an application with a block setting call MySettings and a a
settings called Data.
It will be useful to get a key to directly access one of the Data settings
without looping on it.
[MySettings]
Data["key1"]="foo"
Data["key2"]="bar"
Data["key3"]="bla"
...
Use
===
A use of it could be :
$data = $cfg->getSetting("MySettings", "Data");
echo $data["key1"];
Should print : foo
Max
2010/8/12 James Pic <[email protected]>
> eZ Component: Configuration overloading, Requirements
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> :Author: James Pic
> :Revision: $Revision$
> :Date: $Date$
>
> Introduction
> ============
>
> Description
> -----------
>
> The configuration package provides the tools to store configuration
> settings
> for your application. Configuration options are stored on disk using INI
> files or other configuration formats. The configuration package comes with
> support for manipulation and storage of INI files and caching.
>
> Enhancement #10979 is about making the configuration package able to use
> several configuration directories with a merge mechanism.
>
> Current implementation
> ----------------------
>
> The configuration package does not provide any mechanism to get a final
> setting
> value from several configuration directories or sections.
>
> Requirements
> ============
>
> Any number of configuration objects should be merge-able in an arbitrary
> order.
> There would be 2 merge mechanisms:
> - by file,
> - by section.
>
> The result would be a normal configuration object, usable with the current
> manager and backends.
>
> Example file level merge
> ------------------------
>
> Consider an app called myapp which I maintain. It holds *default*
> configuration
> directory in myapp/config. With the following routes.ini file::
>
> [myapp.register]
> controller=myAppController
> railsRoute=register
> action=register
> template=register.ezt
>
> Consider a project called yourproject which you maintain. It holds the
> *final*
> configuration directory in yourproject/config. With the following
> routes.ini
> file::
>
> [myapp.register]
> controller=yourProjectController
>
> The merged configuration would look like::
>
> [myapp.register]
> controller=yourProjectController
> railsRoute=register
> action=register
> template=register.ezt
>
> Note the different "controller" setting value. The *final* configuration
> value
> took over ("overloaded") the *default* configuration value.
>
> Example section level merge
> ---------------------------
>
> Consider an app called myapp with a configurable, reusable action
> "doSomething", with the following default configuration::
>
> [myapp.doSomething]
> controller=myAppController
> action=something
> someParams[]=foo
> someParams[]=bar
> someSetting=test
>
> Consider a project caller yourproject which you maintain. It holds the
> *final*
> configuration directory in yourproject/config. With the following
> configuration::
>
> [yourproject.doSomethingCool..myapp.doSomething]
> rails=/cool
> someSetting=cool
>
> The merged configuration would look like::
>
> [myapp.doSomething]
> controller=myAppController
> action=something
> someParams[]=foo
> someParams[]=bar
> someSetting=test
>
> [yourproject.doSomethingCool]
> controller=myAppController
> action=something
> someParams[]=foo
> someParams[]=bar
> railsRoute=/cool
> someSetting=cool
>
> Note that section myapp.doSomething was normally copied and that section
> yourproject.doSomethingCool was created based on its settings. After the
> copy,
> the original settings where overwritten with the contents of the
> pseudo-section
> yourproject.doSomethingCool..myapp.doSomething.
>
> Design goals
> ============
>
> The configuration merger should return a normal configuration object.
>
> ..
> Local Variables:
> mode: rst
> fill-column: 79
> End:
> vim: et syn=rst tw=79
>
