I just found Charlie Arehart's new blog. In the comments of his second post Charlie and Ray start discussing the joys and pain of having two config files vs one config file.

One person I worked with turned me onto something he called Inversion of Control, which is a design pattern. I have found it is a rather elegant solution to the config file issue. This is how he set it up:

First create a CFC for your domain name (Jeffryhouser.cfc):

view plain print about
1<cfcomponent output="false">
2 <cfscript>
3 this.dsn = "MyDsn"
4 this.otherconfig="OtherConfig"
5
</cfscript>
6</cfcomponent>

This CFC is our master config file, and contains all the config information for our live server. It is named after the live server .

Now we need to set up a config file for the development machine; aka localhost.cfc:

view plain print about
1<cfcomponent output="false" extends="jeffryhouser ">
2 <cfscript>
3 this.otherconfig="MyLocalCustomConfig"
4
</cfscript>
5</cfcomponent>

This config file extends all the values from the first, and therefore inherits the all the this.x instance variables. We just overwrite our custom config options for the localhost. Most commonly, it is directory paths that change.

In this application we were loading the config values into the request scope. on the OnRequestStart event we added this code:

view plain print about
1<cfset var ioc = REReplace(cgi.HTTP_HOST,"[[:punct:]].*$","")>
2 <cfset structAppend(request,createObject("component","ioc.#ioc#"))>

The first line gets the domain name. The second line instanstiates the component and copies all the instance variables into the request scope. I thought it was a pretty sweet approach and it has worked out pretty well. If Ray was so inclined to change it, I see no reason why Blog.cfc couldn't use a similar approach.