Getting an web application deployed can be very challenging. The word that comes to mind is "messy". You can do some things to tidy it up like using INNO, or use the deployment options provided by CF or J2EE, but the truth is that someone is going to have to "fiddle" with the configuration options until they are right. The most common settings to change are data source names and file paths. We have worked with many applications where we were required to open the Application.cfm file and directly change the values of application variables. This is not a good idea and it limits your deployment options. You may want to compile your pages and not have them open to prying eyes. Or you may be nervous about folks mucking about in the Application.cfm or Application.cfc (as well you should be). There are a couple of alternatives.
NOTE: I amended this post on 12/15 due to an error pointed out by Ray and Sean Corfield (see the comments).
This is easy and straight-forward. You simply include a "config.xml" file of "settings.xml" for you a "clickHereandeditthis.xml" file in the same directory as your Application.cfc or Application.cfm that contains the settings you want.
While I like this approach and I do not object to it, it has the disadvantage of being slightly (only slightly) less user friendly than an INI file. I like INI files because admin and operations folks are often tasked with installing your application. They are used to dealing with INI files. From a Human perspective an INI file is a little bit more readable than an XML file, and if you have only 1 level of variables to work with it certainly makes sense.
An INI file has sections that contain parameters. A section is defined by the square brackets, and a parameter is a name value pair - just like you've come to expect.
This sample has 2 sections, datasource and paths. You would get at these parameters from the file using the underappreciated function "getProfileString( )". This function takes a file name (with a full path), a section value and a parameter value, so the following...One of the biggest gotchas has nothing to do with INI files. How do I change application variables (like dsn or path) without renaming the application or restarting the server. In the "Application.cfm" file we would simply include something in the logic check like "cfif Isdefined('url.refresh')". So naturally you might think the same approach would work here - only you would simply need to run "onApplicationStart()" - easy right? Actually, you might make the mistake I did and include the refresh code at the top of the Application.cfc file - as if it was going to "run" with each request. That's not the case is it. The Application.cfc file is not run with each request - at least not in the way that Application.cfm was run with each request (as a part of the request procedure). Instead, Application.cfc is instantiated at the start of the application and certain events within the application.cfc component are fired at certain times. To get my "refresh" code to work I needed to place it inside the "onRequestStart()" function where the check would be made with each request. Something Like....
Another "gotcha" is formatting. An INI file doesn't require quotes or semi-colons etc. It's just a straight string value - what you see is what you get.
One of the most creative uses of INI is this very blog software, written by Ray Camden. Ray does something nifty that allows multiple blogs. There is an "blogname" variable in the Application.cfm file that you must set (I know, I know it goes against the advice above - but hang with me). His "blog.cfc" component opens the "blog.ini" file and looks for a "section" titled the same as the blogname. So, if I name my blog "cfmuse" I would look for a section like this inside of blog.ini.