Re: [zeta-dev] Configuration component override mechanism : requirement doc
Hi James, On Sat, Aug 14, 2010 at 3:36 AM, James Pic wrote: > On Fri, Aug 13, 2010 at 7:04 PM, Jerome Renard > wrote: >> James, >> >> Hopefully my brain works better than earlier today. >> >> The more I think about the override thingy the more I tend to think >> the following : >> - The merge/inheritance (pick the word you like :D) could easily be >> integrated in the native Configuration component. >> I also already have the algorithm for that as well as tests, so I >> believe that could be quite fast to integrate >> this feature in Configuration. >> >> - The system around such as the directory structure, compilation and >> caching stuff could be integrated into a >> dedicated component that could be a tiein between Configuration and Cache. >> >> That way, everything is clean and separate, if you want to use only >> the merge algorithm for a few configuration >> files, then fair enough just use Configuration only. If you want more >> than that, then use the tiein. >> >> What do you think ? > > Sounds excellent! That way people who like systems can use it, and > people who don't like systems can still benefit from the upgrade... Yep. > > ... Anyway, that sounds more like design document discussions than > "requirement" document issues ;) nia nia nia :-þ -- Jérôme Renard http://39web.fr | http://jrenard.info
Re: [zeta-dev] Configuration component override mechanism : requirement doc
On Fri, Aug 13, 2010 at 7:04 PM, Jerome Renard wrote: > James, > > Hopefully my brain works better than earlier today. > > The more I think about the override thingy the more I tend to think > the following : > - The merge/inheritance (pick the word you like :D) could easily be > integrated in the native Configuration component. > I also already have the algorithm for that as well as tests, so I > believe that could be quite fast to integrate > this feature in Configuration. > > - The system around such as the directory structure, compilation and > caching stuff could be integrated into a > dedicated component that could be a tiein between Configuration and Cache. > > That way, everything is clean and separate, if you want to use only > the merge algorithm for a few configuration > files, then fair enough just use Configuration only. If you want more > than that, then use the tiein. > > What do you think ? Sounds excellent! That way people who like systems can use it, and people who don't like systems can still benefit from the upgrade... ... Anyway, that sounds more like design document discussions than "requirement" document issues ;) Cheers James -- http://jamespic.com/contact Customer is king - Le client est roi - El cliente es rey.
Re: [zeta-dev] Configuration component override mechanism : requirement doc
James, Hopefully my brain works better than earlier today. The more I think about the override thingy the more I tend to think the following : - The merge/inheritance (pick the word you like :D) could easily be integrated in the native Configuration component. I also already have the algorithm for that as well as tests, so I believe that could be quite fast to integrate this feature in Configuration. - The system around such as the directory structure, compilation and caching stuff could be integrated into a dedicated component that could be a tiein between Configuration and Cache. That way, everything is clean and separate, if you want to use only the merge algorithm for a few configuration files, then fair enough just use Configuration only. If you want more than that, then use the tiein. What do you think ? :) -- Jérôme Renard http://39web.fr | http://jrenard.info
Re: [zeta-dev] Configuration component proposal with override mechanism
Hi Maxime, On Fri, Aug 13, 2010 at 6:46 PM, Maxime Thomas 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
I've put it in the Jira.
Max
2010/8/12 Jerome Renard
> Hi Maxime,
>
> On Thu, Aug 12, 2010 at 10:33 PM, Maxime Thomas
> 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 override mechanism : requirement doc
Hi James, On Fri, Aug 13, 2010 at 1:31 PM, James Pic wrote: > On Thu, Aug 12, 2010 at 8:51 PM, Jerome Renard > wrote: >> James, >> >> On Thu, Aug 12, 2010 at 3:15 PM, James Pic wrote: >>> On Thu, Aug 12, 2010 at 2:19 PM, Jerome Renard >>> wrote: Context aware configuration files - Creating a website requires to go through 3 different execution contexts: 1. dev 2. staging 3. production Each context has its own specificities. For example the database used for each of these 3 contexts is different. So this must be defined for each context and used according to the one the web application is actually running in. Those 3 contexts should be handled by the Configuration component, during the configuration directive merge process. Directory structure --- In order to provide a clean directory structure the Configuration component should be able to read and understand a directory structure compared to this one: :: /[..]/conf/ |-- common | |-- dev | |-- prod | `-- staging `-- apps |-- app1 | |-- dev | |-- prod | `-- staging `-- app2 |-- dev |-- prod `-- staging >>> >>> What if that's *not* what the user wants? Will he still be able to use >>> the merger with simple ezcConfiguration objects? In that case i see no >>> objections ;) >> >> Hmm I did not thought about that problematic, but I think that if we do our >> job >> correctly we should be able to use the merge mechanism on two files. What do >> you think ? >> > > I though maybe we could just allow the user to merge configuration > objects into another configuration object, which can then be used by > your special manager, or normal managers, or normal writers and/or > readers. > > Would that be simple and efficient enought? I think so, it should no be possible to merge more than two configuration objects. You will get an octopuss otherwise. So merging two configuration objects into a new one sound acceptable to me, and give enough flexibility to do more work after the merge process. -- Jérôme Renard http://39web.fr | http://jrenard.info
Re: [zeta-dev] FYI: Wiki online
It reminds me to update the project status page :-) On Fri, Aug 13, 2010 at 1:57 PM, Tobias Schlitt wrote: > Just for the records, > > > On 08/13/2010 01:55 PM, Tobias Schlitt wrote: > >> https://cwiki.apache.org/ZETACOMP/ > > is actually an export of the generated wiki sites. For editing, > > https://cwiki.apache.org/confluence/display/ZETACOMP/ > > is used. > > 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 > -- http://www.grobmeier.de
Re: [zeta-dev] FYI: Wiki online
Just for the records, On 08/13/2010 01:55 PM, Tobias Schlitt wrote: > https://cwiki.apache.org/ZETACOMP/ is actually an export of the generated wiki sites. For editing, https://cwiki.apache.org/confluence/display/ZETACOMP/ is used. Cheers, Toby -- Tobias Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 Want to hire me? Need quality assurance?http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
[zeta-dev] FYI: Wiki online
Hi all, our project wiki is online under https://cwiki.apache.org/ZETACOMP/ Regards, Toby -- Tobias Schlitthttp://schlitt.infoGPG 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 override mechanism : requirement doc
On Thu, Aug 12, 2010 at 8:51 PM, Jerome Renard wrote: > James, > > On Thu, Aug 12, 2010 at 3:15 PM, James Pic wrote: >> On Thu, Aug 12, 2010 at 2:19 PM, Jerome Renard >> wrote: >>> >>> Context aware configuration files >>> - >>> >>> Creating a website requires to go through 3 different execution contexts: >>> >>> 1. dev >>> 2. staging >>> 3. production >>> >>> Each context has its own specificities. For example the database used for >>> each >>> of these 3 contexts is different. So this must be defined for each context >>> and >>> used according to the one the web application is actually running in. >>> >>> Those 3 contexts should be handled by the Configuration component, during >>> the >>> configuration directive merge process. >>> >>> Directory structure >>> --- >>> >>> In order to provide a clean directory structure the Configuration component >>> should be able to read and understand a directory structure compared to this >>> one: :: >>> >>> /[..]/conf/ >>> |-- common >>> | |-- dev >>> | |-- prod >>> | `-- staging >>> `-- apps >>> |-- app1 >>> | |-- dev >>> | |-- prod >>> | `-- staging >>> `-- app2 >>> |-- dev >>> |-- prod >>> `-- staging >>> >> >> What if that's *not* what the user wants? Will he still be able to use >> the merger with simple ezcConfiguration objects? In that case i see no >> objections ;) > > Hmm I did not thought about that problematic, but I think that if we do our > job > correctly we should be able to use the merge mechanism on two files. What do > you think ? > I though maybe we could just allow the user to merge configuration objects into another configuration object, which can then be used by your special manager, or normal managers, or normal writers and/or readers. Would that be simple and efficient enought? -- http://jamespic.com/contact Customer is king - Le client est roi - El cliente es rey.
