You are viewing a plain text version of this content. The canonical link for it is here.
Posted to zeta-dev@incubator.apache.org by Jerome Renard <je...@gmail.com> on 2010/08/11 07:58:42 UTC
[zeta-dev] Configuration component proposal with override mechanism
Hi there,
I wrote a configuration component providing an override system for
prod/staging and dev environnements.
If there are eZ Publish users reading this list, this is like the INI
override mechanism but implemented correctly
(it is not compatible at all with eZ Publish though).
After discussing about this component with Tobias, he asked me to propose
that component or maybe the override system
for integration into either a dedicated component or maybe into the already
existing Configuration component.
In order for you to understand better how the system works I attached a PDF
version of the documentation of
this component (configuration.pdf). If you prefer reading the source, feel
free to have a look here :
-
http://github.com/jeromer/p6/blob/master/doc/sphinx/source/configuration.txt
The system depends on the native Configuration and Cache components.
The source code is available here :
- http://github.com/jeromer/p6/tree/master/lib/p6/configuration/
The related tests are available here :
- http://github.com/jeromer/p6/tree/master/tests/lib/p6/configuration/
Any feedback welcome.
Have a nice day :)
--
Jérôme Renard
http://39web.fr | http://jrenard.info
Re: [zeta-dev] Configuration component proposal with override
mechanism
Posted by Maxime Thomas <ma...@gmail.com>.
:-D
2010/8/11 James Pic <ja...@gmail.com>
> Licensed under WTFPL. Enjoy ;)
> > Hi,
> >
> > Good job !
> >
> > @jerome.r : of course we do need that. However, why not extend the
> current
> > Configuration ? Honestly I thought that Configuration did the same that
> > what's in eZP. Disappointed.
> >
> > @jame.p : Is there a license on this piece of code ?
> >
> > I can also see another use : for example, when you install a product,
> > instead of replacing standard empty settings, you just have to override
> it
> /
> > make it inherit...
> >
> > Max
> >
> >
> >
> > 2010/8/11 James Pic <ja...@gmail.com>
> >
> >> On Wed, Aug 11, 2010 at 11:02 AM, Jerome Renard <
> jerome.renard@gmail.com>
> >> wrote:
> >> > James,
> >> >
> >> > On Wed, Aug 11, 2010 at 10:50 AM, James Pic <ja...@gmail.com>
> wrote:
> >> >
> >> >> On Wed, Aug 11, 2010 at 10:40 AM, Jerome Renard <
> >> jerome.renard@gmail.com>
> >> >> wrote:
> >> >> > Hi James,
> >> >> >
> >> >> > On Wed, Aug 11, 2010 at 10:33 AM, James Pic <ja...@gmail.com>
> >> wrote:
> >> >> >
> >> >> >> Congrats for writing yet another implementation of configuration
> >> >> override
> >> >> >> ;)
> >> >> >>
> >> >> >
> >> >> > Lol I was not aware you did that ;)
> >> >> >
> >> >>
> >> >> I know ;)
> >> >>
> >> >> Actually that happens quite frequently :P
> >> >>
> >> >> Another cool thing would be to allow multiline values, although that
> >> >> could cause some minor BC breaks :S
> >> >>
> >> >> >
> >> >> >>
> >> >> >> Another cool feature is configuration section inheritance, maybe
> you
> >> >> >> want to implement that as well. It's actually pretty simple, i'll
> >> post
> >> >> >> my implementation if you want.
> >> >> >>
> >> >> >
> >> >> > Configuration directive inheritance is already implement AFAIR :)
> >> >> > But reading your implement can be interesting anways, maybe there
> is
> >> >> > a lot of good stuff in there.
> >> >> >
> >> >>
> >> >> It's pretty trivial (sources attached), consider this example
> section:
> >> >>
> >> >>
> >> > I did not get anything attached.
> >> >
> >> >
> >> >> [sec]
> >> >> bar=X
> >> >> foo=Y
> >> >>
> >> >> Inheritance allows to write:
> >> >>
> >> >> [sec2..sec]
> >> >> foo=Z
> >> >>
> >> >> Instead of:
> >> >>
> >> >> [sec2]
> >> >> bar=X
> >> >> foo=Z
> >> >>
> >> >>
> >> > In the component I proposed it does not work that way actually.
> >> >
> >> > AFAIR everything inherits from the "prod" context, and you can
> override
> >> > configuration values for staging and dev if you want.
> >> > If you add configuration directive in a particular block it will be
> taken
> >> > into account as well.
> >> > Have a look at the test suite to see all use cases :)
> >>
> >> Yes, that we have as well, although our implementation is more "dumb"
> >> and self contained in one class.
> >>
> >> In my case i use the section level configuration to reuse the same
> >> controler/action with /slightly/ different configurations to produce
> >> more pages with less work, or even with forms configurations.
> >>
> >> There goes the sources: http://gist.github.com/518721
> >>
> >> --
> >> http://jamespic.com/contact
> >> Customer is king - Le client est roi - El cliente es rey.
> >>
>
Re: [zeta-dev] Configuration component proposal with override
mechanism
Posted by James Pic <ja...@gmail.com>.
Licensed under WTFPL. Enjoy ;)
> Hi,
>
> Good job !
>
> @jerome.r : of course we do need that. However, why not extend the current
> Configuration ? Honestly I thought that Configuration did the same that
> what's in eZP. Disappointed.
>
> @jame.p : Is there a license on this piece of code ?
>
> I can also see another use : for example, when you install a product,
> instead of replacing standard empty settings, you just have to override it
/
> make it inherit...
>
> Max
>
>
>
> 2010/8/11 James Pic <ja...@gmail.com>
>
>> On Wed, Aug 11, 2010 at 11:02 AM, Jerome Renard <je...@gmail.com>
>> wrote:
>> > James,
>> >
>> > On Wed, Aug 11, 2010 at 10:50 AM, James Pic <ja...@gmail.com> wrote:
>> >
>> >> On Wed, Aug 11, 2010 at 10:40 AM, Jerome Renard <
>> jerome.renard@gmail.com>
>> >> wrote:
>> >> > Hi James,
>> >> >
>> >> > On Wed, Aug 11, 2010 at 10:33 AM, James Pic <ja...@gmail.com>
>> wrote:
>> >> >
>> >> >> Congrats for writing yet another implementation of configuration
>> >> override
>> >> >> ;)
>> >> >>
>> >> >
>> >> > Lol I was not aware you did that ;)
>> >> >
>> >>
>> >> I know ;)
>> >>
>> >> Actually that happens quite frequently :P
>> >>
>> >> Another cool thing would be to allow multiline values, although that
>> >> could cause some minor BC breaks :S
>> >>
>> >> >
>> >> >>
>> >> >> Another cool feature is configuration section inheritance, maybe
you
>> >> >> want to implement that as well. It's actually pretty simple, i'll
>> post
>> >> >> my implementation if you want.
>> >> >>
>> >> >
>> >> > Configuration directive inheritance is already implement AFAIR :)
>> >> > But reading your implement can be interesting anways, maybe there is
>> >> > a lot of good stuff in there.
>> >> >
>> >>
>> >> It's pretty trivial (sources attached), consider this example section:
>> >>
>> >>
>> > I did not get anything attached.
>> >
>> >
>> >> [sec]
>> >> bar=X
>> >> foo=Y
>> >>
>> >> Inheritance allows to write:
>> >>
>> >> [sec2..sec]
>> >> foo=Z
>> >>
>> >> Instead of:
>> >>
>> >> [sec2]
>> >> bar=X
>> >> foo=Z
>> >>
>> >>
>> > In the component I proposed it does not work that way actually.
>> >
>> > AFAIR everything inherits from the "prod" context, and you can override
>> > configuration values for staging and dev if you want.
>> > If you add configuration directive in a particular block it will be
taken
>> > into account as well.
>> > Have a look at the test suite to see all use cases :)
>>
>> Yes, that we have as well, although our implementation is more "dumb"
>> and self contained in one class.
>>
>> In my case i use the section level configuration to reuse the same
>> controler/action with /slightly/ different configurations to produce
>> more pages with less work, or even with forms configurations.
>>
>> There goes the sources: http://gist.github.com/518721
>>
>> --
>> http://jamespic.com/contact
>> Customer is king - Le client est roi - El cliente es rey.
>>
Re: [zeta-dev] Configuration component proposal with override
mechanism
Posted by Maxime Thomas <ma...@gmail.com>.
Hi,
Good job !
@jerome.r : of course we do need that. However, why not extend the current
Configuration ? Honestly I thought that Configuration did the same that
what's in eZP. Disappointed.
@jame.p : Is there a license on this piece of code ?
I can also see another use : for example, when you install a product,
instead of replacing standard empty settings, you just have to override it /
make it inherit...
Max
2010/8/11 James Pic <ja...@gmail.com>
> On Wed, Aug 11, 2010 at 11:02 AM, Jerome Renard <je...@gmail.com>
> wrote:
> > James,
> >
> > On Wed, Aug 11, 2010 at 10:50 AM, James Pic <ja...@gmail.com> wrote:
> >
> >> On Wed, Aug 11, 2010 at 10:40 AM, Jerome Renard <
> jerome.renard@gmail.com>
> >> wrote:
> >> > Hi James,
> >> >
> >> > On Wed, Aug 11, 2010 at 10:33 AM, James Pic <ja...@gmail.com>
> wrote:
> >> >
> >> >> Congrats for writing yet another implementation of configuration
> >> override
> >> >> ;)
> >> >>
> >> >
> >> > Lol I was not aware you did that ;)
> >> >
> >>
> >> I know ;)
> >>
> >> Actually that happens quite frequently :P
> >>
> >> Another cool thing would be to allow multiline values, although that
> >> could cause some minor BC breaks :S
> >>
> >> >
> >> >>
> >> >> Another cool feature is configuration section inheritance, maybe you
> >> >> want to implement that as well. It's actually pretty simple, i'll
> post
> >> >> my implementation if you want.
> >> >>
> >> >
> >> > Configuration directive inheritance is already implement AFAIR :)
> >> > But reading your implement can be interesting anways, maybe there is
> >> > a lot of good stuff in there.
> >> >
> >>
> >> It's pretty trivial (sources attached), consider this example section:
> >>
> >>
> > I did not get anything attached.
> >
> >
> >> [sec]
> >> bar=X
> >> foo=Y
> >>
> >> Inheritance allows to write:
> >>
> >> [sec2..sec]
> >> foo=Z
> >>
> >> Instead of:
> >>
> >> [sec2]
> >> bar=X
> >> foo=Z
> >>
> >>
> > In the component I proposed it does not work that way actually.
> >
> > AFAIR everything inherits from the "prod" context, and you can override
> > configuration values for staging and dev if you want.
> > If you add configuration directive in a particular block it will be taken
> > into account as well.
> > Have a look at the test suite to see all use cases :)
>
> Yes, that we have as well, although our implementation is more "dumb"
> and self contained in one class.
>
> In my case i use the section level configuration to reuse the same
> controler/action with /slightly/ different configurations to produce
> more pages with less work, or even with forms configurations.
>
> There goes the sources: http://gist.github.com/518721
>
> --
> http://jamespic.com/contact
> Customer is king - Le client est roi - El cliente es rey.
>
Re: [zeta-dev] Configuration component proposal with override
mechanism
Posted by James Pic <ja...@gmail.com>.
On Wed, Aug 11, 2010 at 11:02 AM, Jerome Renard <je...@gmail.com> wrote:
> James,
>
> On Wed, Aug 11, 2010 at 10:50 AM, James Pic <ja...@gmail.com> wrote:
>
>> On Wed, Aug 11, 2010 at 10:40 AM, Jerome Renard <je...@gmail.com>
>> wrote:
>> > Hi James,
>> >
>> > On Wed, Aug 11, 2010 at 10:33 AM, James Pic <ja...@gmail.com> wrote:
>> >
>> >> Congrats for writing yet another implementation of configuration
>> override
>> >> ;)
>> >>
>> >
>> > Lol I was not aware you did that ;)
>> >
>>
>> I know ;)
>>
>> Actually that happens quite frequently :P
>>
>> Another cool thing would be to allow multiline values, although that
>> could cause some minor BC breaks :S
>>
>> >
>> >>
>> >> Another cool feature is configuration section inheritance, maybe you
>> >> want to implement that as well. It's actually pretty simple, i'll post
>> >> my implementation if you want.
>> >>
>> >
>> > Configuration directive inheritance is already implement AFAIR :)
>> > But reading your implement can be interesting anways, maybe there is
>> > a lot of good stuff in there.
>> >
>>
>> It's pretty trivial (sources attached), consider this example section:
>>
>>
> I did not get anything attached.
>
>
>> [sec]
>> bar=X
>> foo=Y
>>
>> Inheritance allows to write:
>>
>> [sec2..sec]
>> foo=Z
>>
>> Instead of:
>>
>> [sec2]
>> bar=X
>> foo=Z
>>
>>
> In the component I proposed it does not work that way actually.
>
> AFAIR everything inherits from the "prod" context, and you can override
> configuration values for staging and dev if you want.
> If you add configuration directive in a particular block it will be taken
> into account as well.
> Have a look at the test suite to see all use cases :)
Yes, that we have as well, although our implementation is more "dumb"
and self contained in one class.
In my case i use the section level configuration to reuse the same
controler/action with /slightly/ different configurations to produce
more pages with less work, or even with forms configurations.
There goes the sources: http://gist.github.com/518721
--
http://jamespic.com/contact
Customer is king - Le client est roi - El cliente es rey.
Re: [zeta-dev] Configuration component proposal with override
mechanism
Posted by Jerome Renard <je...@gmail.com>.
James,
On Wed, Aug 11, 2010 at 10:50 AM, James Pic <ja...@gmail.com> wrote:
> On Wed, Aug 11, 2010 at 10:40 AM, Jerome Renard <je...@gmail.com>
> wrote:
> > Hi James,
> >
> > On Wed, Aug 11, 2010 at 10:33 AM, James Pic <ja...@gmail.com> wrote:
> >
> >> Congrats for writing yet another implementation of configuration
> override
> >> ;)
> >>
> >
> > Lol I was not aware you did that ;)
> >
>
> I know ;)
>
> Actually that happens quite frequently :P
>
> Another cool thing would be to allow multiline values, although that
> could cause some minor BC breaks :S
>
> >
> >>
> >> Another cool feature is configuration section inheritance, maybe you
> >> want to implement that as well. It's actually pretty simple, i'll post
> >> my implementation if you want.
> >>
> >
> > Configuration directive inheritance is already implement AFAIR :)
> > But reading your implement can be interesting anways, maybe there is
> > a lot of good stuff in there.
> >
>
> It's pretty trivial (sources attached), consider this example section:
>
>
I did not get anything attached.
> [sec]
> bar=X
> foo=Y
>
> Inheritance allows to write:
>
> [sec2..sec]
> foo=Z
>
> Instead of:
>
> [sec2]
> bar=X
> foo=Z
>
>
In the component I proposed it does not work that way actually.
AFAIR everything inherits from the "prod" context, and you can override
configuration values for staging and dev if you want.
If you add configuration directive in a particular block it will be taken
into account as well.
Have a look at the test suite to see all use cases :)
Cheers,
--
Jérôme Renard
http://39web.fr | http://jrenard.info
Re: [zeta-dev] Configuration component proposal with override
mechanism
Posted by James Pic <ja...@gmail.com>.
On Wed, Aug 11, 2010 at 10:40 AM, Jerome Renard <je...@gmail.com> wrote:
> Hi James,
>
> On Wed, Aug 11, 2010 at 10:33 AM, James Pic <ja...@gmail.com> wrote:
>
>> Congrats for writing yet another implementation of configuration override
>> ;)
>>
>
> Lol I was not aware you did that ;)
>
I know ;)
Actually that happens quite frequently :P
Another cool thing would be to allow multiline values, although that
could cause some minor BC breaks :S
>
>>
>> Another cool feature is configuration section inheritance, maybe you
>> want to implement that as well. It's actually pretty simple, i'll post
>> my implementation if you want.
>>
>
> Configuration directive inheritance is already implement AFAIR :)
> But reading your implement can be interesting anways, maybe there is
> a lot of good stuff in there.
>
It's pretty trivial (sources attached), consider this example section:
[sec]
bar=X
foo=Y
Inheritance allows to write:
[sec2..sec]
foo=Z
Instead of:
[sec2]
bar=X
foo=Z
--
http://jamespic.com/contact
Customer is king - Le client est roi - El cliente es rey.
Re: [zeta-dev] Configuration component proposal with override
mechanism
Posted by Jerome Renard <je...@gmail.com>.
Hi James,
On Wed, Aug 11, 2010 at 10:33 AM, James Pic <ja...@gmail.com> wrote:
> Congrats for writing yet another implementation of configuration override
> ;)
>
Lol I was not aware you did that ;)
>
> Another cool feature is configuration section inheritance, maybe you
> want to implement that as well. It's actually pretty simple, i'll post
> my implementation if you want.
>
Configuration directive inheritance is already implement AFAIR :)
But reading your implement can be interesting anways, maybe there is
a lot of good stuff in there.
Cheers,
--
Jérôme Renard
http://39web.fr | http://jrenard.info
Re: [zeta-dev] Configuration component proposal with override
mechanism
Posted by James Pic <ja...@gmail.com>.
Congrats for writing yet another implementation of configuration override ;)
Another cool feature is configuration section inheritance, maybe you
want to implement that as well. It's actually pretty simple, i'll post
my implementation if you want.
Regards
James
--
http://jamespic.com/contact
Customer is king - Le client est roi - El cliente es rey.
Re: [zeta-dev] Configuration component proposal with override
mechanism
Posted by Jerome Renard <je...@gmail.com>.
Hi Tobias,
On Thu, Aug 12, 2010 at 9:04 AM, Tobias Schlitt <to...@schlitt.info> wrote:
> Jerome and James,
>
> having an override mechanism in our Configuration component is a long
> desired feature. Since both of you have custom implementations around,
> how about joining forces here? You 2 could see where similarities and
> differences are and combine your solutions. I'd suggest that you start
> with small requirements and design documents. AFAIR James already posted
> something in this direction on the old list?
>
>
Yes here :
- http://www.mail-archive.com/components@lists.ez.no/msg01790.html
--
Jérôme Renard
http://39web.fr | http://jrenard.info
Re: [zeta-dev] Configuration component proposal with override mechanism
Posted by Jerome Renard <je...@gmail.com>.
Hi Maxime,
On Fri, Aug 13, 2010 at 6:46 PM, Maxime Thomas <ma...@gmail.com> wrote:
> I've put it in the Jira.
>
Cool, thanks :)
--
Jérôme Renard
http://39web.fr | http://jrenard.info
Re: [zeta-dev] Configuration component proposal with override mechanism
Posted by Maxime Thomas <ma...@gmail.com>.
I've put it in the Jira.
Max
2010/8/12 Jerome Renard <je...@gmail.com>
> Hi Maxime,
>
> On Thu, Aug 12, 2010 at 10:33 PM, Maxime Thomas <ma...@gmail.com>
> wrote:
> > 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
> >
> >
>
> I think this is a complete different feature.
>
> Please file an enhancement request for that in the issue tracker:
> - https://issues.apache.org/jira/browse/ZETACOMP
>
> Thanks :)
>
> --
> Jérôme Renard
> http://39web.fr | http://jrenard.info
>
Re: [zeta-dev] Configuration component proposal with override mechanism
Posted by Jerome Renard <je...@gmail.com>.
Hi Maxime,
On Thu, Aug 12, 2010 at 10:33 PM, Maxime Thomas <ma...@gmail.com> wrote:
> 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
>
>
I think this is a complete different feature.
Please file an enhancement request for that in the issue tracker:
- https://issues.apache.org/jira/browse/ZETACOMP
Thanks :)
--
Jérôme Renard
http://39web.fr | http://jrenard.info
Re: [zeta-dev] Configuration component proposal with override mechanism
Posted by Maxime Thomas <ma...@gmail.com>.
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 <ja...@gmail.com>
> 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
>
Re: [zeta-dev] Configuration component proposal with override
mechanism
Posted by James Pic <ja...@gmail.com>.
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
Re: [zeta-dev] Configuration component proposal with override
mechanism
Posted by James Pic <ja...@gmail.com>.
On Thu, Aug 12, 2010 at 12:33 PM, Tobias Schlitt <to...@schlitt.info> wrote:
> On 08/12/2010 12:30 PM, James Pic wrote:
>> On Thu, Aug 12, 2010 at 10:22 AM, Tobias Schlitt <to...@schlitt.info> wrote:
>
>>> On 08/12/2010 09:38 AM, Jerome Renard wrote:
>
>>>> I propose the following process :
>>>> James and I (and actually anyone interested in the topic) should discuss our
>>>> views on
>>>> the -dev mailing-list so it is transparent to anyone. And then write a
>>>> proposal document
>>>> after a concensus has been found.
>>>>
>>>> What do you think ?
>
>>> that sounds pretty good. Looking forward to it! :)
>
>> Should we try to add section-level inheritance as i suggested earlier
>> (ie. [childSection..parentSection]) to the requirements doc or should
>> we work on the design doc directly?
>
> If this is a requirement for you, I'd suggest to add it to the
> requirements, yes. :)
Thanks for the answer ;)
In that case i'm heavily interrested in another enhancement: multiline
string configuration values support.
Maybe it would not break BC if implemented like php's heredoc syntax?
What do you think?
--
http://jamespic.com/contact
Customer is king - Le client est roi - El cliente es rey.
Re: [zeta-dev] Configuration component proposal with override mechanism
Posted by Tobias Schlitt <to...@schlitt.info>.
On 08/12/2010 12:30 PM, James Pic wrote:
> On Thu, Aug 12, 2010 at 10:22 AM, Tobias Schlitt <to...@schlitt.info> wrote:
>> On 08/12/2010 09:38 AM, Jerome Renard wrote:
>>> I propose the following process :
>>> James and I (and actually anyone interested in the topic) should discuss our
>>> views on
>>> the -dev mailing-list so it is transparent to anyone. And then write a
>>> proposal document
>>> after a concensus has been found.
>>>
>>> What do you think ?
>> that sounds pretty good. Looking forward to it! :)
> Should we try to add section-level inheritance as i suggested earlier
> (ie. [childSection..parentSection]) to the requirements doc or should
> we work on the design doc directly?
If this is a requirement for you, I'd suggest to add it to the
requirements, yes. :)
--
Tobias Schlitt http://schlitt.info GPG Key: 0xC462BC14
Want to hire me? Need quality assurance? http://qafoo.com
eZ Components are Zeta Components now! http://bit.ly/9S7zbn
Re: [zeta-dev] Configuration component proposal with override
mechanism
Posted by James Pic <ja...@gmail.com>.
On Thu, Aug 12, 2010 at 10:22 AM, Tobias Schlitt <to...@schlitt.info> wrote:
> Jerome, James,
>
> On 08/12/2010 09:38 AM, Jerome Renard wrote:
>
>> I propose the following process :
>> James and I (and actually anyone interested in the topic) should discuss our
>> views on
>> the -dev mailing-list so it is transparent to anyone. And then write a
>> proposal document
>> after a concensus has been found.
>>
>> What do you think ?
>
> that sounds pretty good. Looking forward to it! :)
Should we try to add section-level inheritance as i suggested earlier
(ie. [childSection..parentSection]) to the requirements doc or should
we work on the design doc directly?
--
http://jamespic.com/contact
Customer is king - Le client est roi - El cliente es rey.
Re: [zeta-dev] Configuration component proposal with override mechanism
Posted by Maxime Thomas <ma...@gmail.com>.
I'd be glad to review it.
Max
2010/8/12 Tobias Schlitt <to...@schlitt.info>
> Jerome, James,
>
> On 08/12/2010 09:38 AM, Jerome Renard wrote:
>
> > I propose the following process :
> > James and I (and actually anyone interested in the topic) should discuss
> our
> > views on
> > the -dev mailing-list so it is transparent to anyone. And then write a
> > proposal document
> > after a concensus has been found.
> >
> > What do you think ?
>
> that sounds pretty good. Looking forward to it! :)
>
> Cheers,
> Toby
> --
> Tobias Schlitt http://schlitt.info GPG Key: 0xC462BC14
> Want to hire me? Need quality assurance? http://qafoo.com
> eZ Components are Zeta Components now! http://bit.ly/9S7zbn
>
Re: [zeta-dev] Configuration component proposal with override mechanism
Posted by Tobias Schlitt <to...@schlitt.info>.
Jerome, James,
On 08/12/2010 09:38 AM, Jerome Renard wrote:
> I propose the following process :
> James and I (and actually anyone interested in the topic) should discuss our
> views on
> the -dev mailing-list so it is transparent to anyone. And then write a
> proposal document
> after a concensus has been found.
>
> What do you think ?
that sounds pretty good. Looking forward to it! :)
Cheers,
Toby
--
Tobias Schlitt http://schlitt.info GPG Key: 0xC462BC14
Want to hire me? Need quality assurance? http://qafoo.com
eZ Components are Zeta Components now! http://bit.ly/9S7zbn
Re: [zeta-dev] Configuration component proposal with override
mechanism
Posted by Jerome Renard <je...@gmail.com>.
Tobias,
On Thu, Aug 12, 2010 at 9:04 AM, Tobias Schlitt <to...@schlitt.info> wrote:
> Jerome and James,
>
> having an override mechanism in our Configuration component is a long
> desired feature. Since both of you have custom implementations around,
> how about joining forces here? You 2 could see where similarities and
> differences are and combine your solutions. I'd suggest that you start
> with small requirements and design documents. AFAIR James already posted
> something in this direction on the old list?
>
That sounds good to me. James and I can compare our approach of the concept
and
see if that is possible to merge our views at some point. And if yes, then
try to propose an
implementation and see if that can fit into the Configuration component.
I propose the following process :
James and I (and actually anyone interested in the topic) should discuss our
views on
the -dev mailing-list so it is transparent to anyone. And then write a
proposal document
after a concensus has been found.
What do you think ?
Cheers,
--
Jérôme Renard
http://39web.fr | http://jrenard.info
Re: [zeta-dev] Configuration component proposal with override mechanism
Posted by Tobias Schlitt <to...@schlitt.info>.
Jerome and James,
having an override mechanism in our Configuration component is a long
desired feature. Since both of you have custom implementations around,
how about joining forces here? You 2 could see where similarities and
differences are and combine your solutions. I'd suggest that you start
with small requirements and design documents. AFAIR James already posted
something in this direction on the old list?
I'd also suggest that you look into Template, which already has some
override mechanism [1] since version 1.2. I don't know how far it is
possible to design the Configuration override with similar APIs, but we
should at least try to.
Thanks for your efforts,
regards,
Toby
[1]
http://incubator.apache.org/zetacomponents/documentation/trunk/Template/tutorial.html#template-locations
--
Tobias Schlitt http://schlitt.info GPG Key: 0xC462BC14
Want to hire me? Need quality assurance? http://qafoo.com
eZ Components are Zeta Components now! http://bit.ly/9S7zbn