example ini file (www.cfcdeveloper.com.ini)

Another good use for an ini file could be to duplicate an application or site across multiple domains and owners depending on the URL domain name, basically hosted on the same server. That way you can sell use of an application or site and maintain central control over the big picture. An update or new enhancement would populate all domains at once instead of having to duplicate the changes numerous times.

One way to do this is to name your ini file (this could be applied to CSS also) the same as the domain in which it is meant for. So I would name an ini file for my site www.cfcdeveloper.com.ini. Then if joebob.com wanted to use my site also, I could sell him the use of it and simply make another ini file named www.joebob.com.ini. Then when a visitor hits joebob's site, it will use his ini file instead of mine.

Something like this:
<cfset var iniFile="#getDirectoryFromPath(GetCurrentTemplatePath())#/#cgi.server_name#.ini">

So now the magic begins. We need to put these variables into a site wide scope to use everywhere. You can decide if you want to use application or request scope or something else. I like to use the request scope myself for smaller applications, application scope for specific other purposes and very large applications.

And here is the most simplified manner which I can show you how to do it (using the ini file above for example):

Hopefully that is all self explainatory above. Of course there are more efficient means to accomplish this also including using the getProfileSection function to fetch the sections and parse those out automatically. Look in the documentation to find the way you prefer.

You can also use the setProfileString function to set values to ini variables if empty or other conditions. Or maybe set a default ini and use Application.cfc to set ini variables depending on the URL and such. There are many ways to use this power.

One other thing I want to show you about using ini files for sharing an application with many domains on one server. You can also make one ini file and give the sections names for the domain calling it. That domain would set variables depending on the section instead of the file name. Let me try to show you.

example (site.ini):

Then you set the ini section before calling the ini to set variables to a site wide scope:
<cfset request.iniSection = "cfcdeveloper">

Something like this:

There are pros and cons to any style. Using sections for sites or domains, you have to add a new variable to all the sections one by one. But at least its in the same file. Using a file per domain, you have to open each one and add a new variable when one is added to the application. Pick whichever means suits you best.