Re: Application settings, configuration, and preferences.

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@CBORD.com> wrote: > From: Ken Guest > >> On Wed, Oct 27, 2010 at 5:27 PM, <mmestnik@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 >