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 <mike...@gmail.com> 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" <r...@cbord.com> wrote: > >> From: Ken Guest >> >>> On Wed, Oct 27, 2010 at 5:27 PM, <mmest...@nagios.com> 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 > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
