On Wed, Oct 27, 2010 at 11:39 AM, J Ravi Menon <jravimenon@xxxxxxxxx> wrote: > I am partial to the filesystem but I can see scenarios where the db > approach might be useful (single point of control) with good caching > strategy using apc or other mechanisms. > > One approach I have followed is that if the config. field and values > are simple key-value pairs, you could store them in a dedicated conf > file and have it included in the main apache conf file (Include > directive). This way, all the configs are accessible via $_SERVER. The > separate conf file can be checked in svn, pushed separately as part of > release process etc... The same approach also works in standalone php > cli scripts via a shell wrapper - e.g.: > > #!/bin/bash > . > # list fields directly here or load them separately - e.g: > # . /path/to/some_file.conf > export FIELD1="foo" > export FIELD2 ="bar" > > # Note: values can have some structure too > export FIELD3="abc,cde,fgh" > . > . > /usr/bin/php some_script.php > > You could also use the php ini style confs: > > http://php.net/manual/en/function.parse-ini-file.php > > In the $_SERVER approach above, the parsing is done at start-up, so > there is no setup cost at every request. For the ini or xml parsing > approach, you may need to cache the result if this parsing cost needs > to be avoided on every request. > > Ravi > > > > On Wed, Oct 27, 2010 at 10:17 AM, Michael Shadle <mike503@xxxxxxxxx> wrote: >> I find json to be the most ideal data exchange format but using it for configuration files one may edit by hand is horrible. XML, ini or yaml would be better. I still prefer XML. Albeit verbose it is the easiest to read and easy to validate against. >> >> On Oct 27, 2010, at 10:12 AM, "Bob McConnell" <rvm@xxxxxxxxx> wrote: >> >>> From: Ken Guest >>> >>>> On Wed, Oct 27, 2010 at 5:27 PM, <mmestnik@xxxxxxxxxx> wrote: >>>>> Recently we had a discussion about weather our code should be >>> configured >>>>> using files or a DB back-end. As this topic effects nearly every >>>>> development team I was wondering if there shouldn't be a common >>> library >>>>> that deals with all of these issues. >>>>> >>>>> We came to the conclusion that either should work, but our project >>> must >>>>> work on systems that would not have an SQLDB installed. There fore >>> it >>>>> must be configured using files as supporting both would be a waste of >>>>> our development time. >>>>> >>>>> Looking around for a solution I came across an extension to getopt >>> that >>>>> read command line parameters from a file, essentially emulating "exec >>>>> $(cat);". As this did allow configuration from either the command >>> line >>>>> or a file it's a good start. However we are specificually looking >>> for >>>>> something that would accept configuration from a file or a DB, >>> command >>>>> line options are not important. Though a great solution would take >>>>> configuration from anywhere. >>>>> >>>>> A full featured solution would also support containing user >>> preferences >>>>> and administrative settings. Allowing any of these to come from >>> almost >>>>> anywhere. Here is how an example deployment might work. As this >>> would >>>>> be a programming tool the user would be an administrator installing >>> and >>>>> configuring the software. >>>>> >>>>> Some configuration information contained in php should be extensible >>> so >>>>> that all the configuration could be done there. In this case >>> settings >>>>> and user preferences would be read-only, configuration information is >>>>> always read-only. This would usually specify a config file to be >>>>> located in the same folder or a subfolder. >>>>> >>>>> This configuration file would have a default format that is >>> configurable >>>>> in the php. Would be one of PHP, XML, bind, apache, and several >>> other >>>>> config file formats. This file would contain information on where >>>>> settings and preferences could be written to, either another >>>>> configuration file some where in /var or connection information for a >>> DB. >>>>> >>>>> From an application developers stand point this should all be as >>>>> difficult as getopt to setup, design decisions like what format the >>>>> config file is in should be left up to the admin installing the >>>>> software. The developer need only be concerned with defining the >>> values >>>>> stored, there type, and other properties. >>>>> >>>>> Does anything like this exist? This seams like an essential piece of >>>>> code that is re-invented for every project. >>>>> >>>> >>>> PEAR's Config package sounds like a good match for what you are >>> looking for. >>>> It parses and outputs various formats and edits existing config files >>>> >>>> http://pear.php.net/package/Config >>>> >>>> There's a brief intro to what it can do at >>>> http://pear.php.net/manual/en/package.configuration.config.intro.php >>>> >>>> I have to admit I am somewhat biased as I'm currently on the PEAR >>> Group >>>> (read 'committee') - but I'd be surprised if there's not a Zend or >>>> ezComponents/zetaComponents equivalent. I also have to admit there are >>> some >>>> outstanding issues that need to be addressed for PEAR's Config package >>> - the >>>> good news is someone has volunteered to resolve these today. >>> >>> There are nearly as many ways to do this as there are languages to >>> implement them in. I have been using YAML files for a while now, not >>> only for configuration and parameter storage, but also input for data >>> driven testing, for both unit and functional tests. Other teams here are >>> using JSON strings, which will actually become a proper subset of YAML >>> when the parsers catch up with the latest specification. >>> >>> More info at <http://yaml.org/>. >>> >>> Bob McConnell >>> >>> -- >>> PHP General Mailing List (http://www.php.net/) >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > Whoops I forgot the rule on bottom--posting! So used to top-posting elsewhere, it is 2nd nature now. I am re-adding my earlier response below and missed to mention one more item: > I am partial to the filesystem but I can see scenarios where the db > approach might be useful (single point of control) with good caching > strategy using apc or other mechanisms. > > One approach I have followed is that if the config. field and values > are simple key-value pairs, you could store them in a dedicated conf > file and have it included in the main apache conf file (Include > directive). This way, all the configs are accessible via $_SERVER. The > separate conf file can be checked in svn, pushed separately as part of > release process etc... The same approach also works in standalone php > cli scripts via a shell wrapper - e.g.: > > #!/bin/bash > . > # list fields directly here or load them separately - e.g: > # . /path/to/some_file.conf > export FIELD1="foo" > export FIELD2 ="bar" > > # Note: values can have some structure too > export FIELD3="abc,cde,fgh" > . > . > /usr/bin/php some_script.php > > You could also use the php ini style confs: > > http://php.net/manual/en/function.parse-ini-file.php > > In the $_SERVER approach above, the parsing is done at start-up, so > there is no setup cost at every request. For the ini or xml parsing > approach, you may need to cache the result if this parsing cost needs > to be avoided on every request. > > Ravi Forgot to mention that in the apache case above, you would use the 'SetEnv' directive to define the key-value pairs in some conf file - e.g. SetEnv FIELD1 "foo" SetEnv FIELD2 "bar" SetEnv FIELD3 "abc,cde,fgh" . . . Ravi -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
