I sometimes wonder if engineers have a secret obsession with configuration options. I've been working on a few projects in the last few weeks that have made me wonder if the developers consider configuration options an excuse to be lazy, and let someone else sort out their mess.
Other than developing software, I also install my software, and other peoples, onto clients computers. At one point a few years ago, I was asked to provide instructions to install the software so they had a backup plan if I was un-available. Simple I thought, I write great software that's easy to install and set up. So off I went and wrote a realitively simple installation document.
Amazingly enough, the unfortunate guy the other end had great difficulty getting the application up and going. Some of the more classic problems where
- The application needed write access to various folders on the machine, and those folder locations where configurable.
- The application needed to use a number of system commands, and the path to the command needed setting up.
- The application was going to be installed in a different path to the development box, with a different hostname etc.
I've also seen applications have configuration options for
- name of the help url.
- width of output (in a wrapped pre formated text area)
- specific folder locations for specific purposes.
One of the primary failings to all of these options, was the fact that almost all of them are either not required, or should have been defaulted by the application.
- Write access, can normally be dealt with by writing to the ini_get('session.save_path') by default, if the user wants to change the path, they can actually set the option or change the php.ini or .htaccess and modify the save_path
You can also create your own application specific subdirectory under that temporary directory. PEAR's System::mkdir(array('-p',$mytmpdir)); works very well there.
- System::which() provides a cross platform version of the unix which command. - this can be used to default paths for applications (hence no requirement for these type of options)
- for paths and urls, PHP provides plenty of information about where your application is, and how to access it, forcing a user to configure them is almost always unnessecary.
- Templates are really the place to modify url's or fixed paths or widths, Flexy's ability to be told about template folders to use, enables you to override (eg. copy and modify) specific templates that you need to change for your site.
- Some options are just plain pointless, for the 2 in 2 million users who want them, there is usually a better way that adding an option (class inheritance comes to mind - extend my class and add it to your wrapper...)
- And sometimes you just have to put your foot down, the help files are always going to be in [root]/help.. there's no choice in it, and dont waste our time making it configurable..
Solving this issue has involved the refactoring of my FlexyFramework many times, the history of how and where do configuration went something like this:
- a ConfigData folder in the application root, stored one config file for each domain the app was installed on.
- These contained a huge number of options, for all the packages that the applicaiton used.
- As time has evolved, I've removed the requirement for alot of the core options, and used defaults that work 99% of the time.
- About a year ago, It struck me the autoloading of these Files was actually the cause of some setup bugs and time wasting, so I moved almost all the remaining options to the index.php line that starts the Framework, and pulled in a single option from a machine wide ini file. (basically moving any optional stuff into the bootstrap file.)
- So at the end of the day, we have one global .ini file for each server, which basically lists all the database dsn's for the various applications. (for simpler servers, the index.php file explicitly loads an ini file from somewhere, which generally only contains the database dsn.)
So finally I can say in the documentation
- download, unzip
- create the database using the .sql file (or similar)
- Then depending on the complexity of the project
- alter the index.php, add the database dsn.
- alter the xxx ini file, and change the database dsn.
And hey presto it works...!, well sometimes..
