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
