Sounds good. That is similar to what I was thinking. Thanks Alan. On Mar 31, 5:19 pm, Alan Holden <[email protected]> wrote: > My MO has always been to create a little cffunction that loads up all the ini > vars (things like datasource name, file paths, admin emails, external > servers, etc) - and put them into the application scope. > I hit the little function onApplicationStart - and I might have some other > event or trigger to fire off that little function as needed. Because it's > often the app's administrator who can change the contents of the ini file - > he or she just knows to trigger the reload if he/she changes it (often by > placing a secret word in a url query string, like "domain.com/?iniReload=1" - > that's picked up with a code snippet you can put in the onRequestStart > function. > I will often place these ini files in the cfml engine's root, using the > Application.name as part of the file spec and the platform's 'server' scope > to find it. This feature is generally provided as a mechanism to store > variables - that areexclusive to that machine- outside the public web path > and also your source code control (like SVN); so that your application code > base remains pure (does not become riddled with the bunch of"if I'm a dev > machine then I'll do this"files or conditions). > You could also get all fancy pants, and actually "sense" when the file has > changed automatically, but now you're starting to stretch the whole purpose > of what "ini" even stands for. If they change all the time, then they're not > really "initialize" values at all, are they? ;-] If they change like ... > per-user, then put 'em in a database, session scope or encrypted cookie, load > 'em up when the user authenticates. > Al > On 3/31/2012 11:26 AM, Aaron J. White wrote:Hey Guys, I recently choose .ini > files to store user defined application variables in. I will be grabbing the > variables I need throughout my application with the getprofilestring and > getprofilessection functions. ***Should I be caching the values I store in > the ini files somehow? In my head I assume getprofilestring could be an > expensive operation since it needs to read the value from the file stored on > the hard drive. ***If I wanted to cache the values in the application scope > is there a good way to detect if the .ini file has been modified and only > then reload the cache? This may not be something I have to worry about, but I > just want to make sure I am using best practices. I also don't expect my user > defined application variables to change very often after the initial > configuration. Below is an example of how I will be using the settings > defined in the ini in my application's logic. Please let me know what you > think. <cffunction name="index" output="false"> <cfset var l = { publicPage: > getprofilestring(application.basepath & "/config/ settings.ini.cfm", > "mainpage", "publicPage"), forwardUrl:getprofilestring(application.basepath & > "/config/ settings.ini.cfm", "mainpage", "forwardUrl") } /> <cfif > structKeyExists(rc, "curl") AND len(rc.curl)> <!--- push to url---> <cfset > application.theFactory.getService("url").pushLongUrl(rc.curl) /> <cfelseif > NOT l.publicPage> <!--- forward to userdefined url---> <cfif isValid('url', > l.forwardUrl)> <cfset location(l.forwardUrl, 'no') /> </cfif> <cfabort /> > <cfelse> <!--- get main page ---> <cfset rc.title = "Main Page" /> </cfif> > </cffunction>
-- online documentation: http://openbd.org/manual/ google+ hints/tips: https://plus.google.com/115990347459711259462 http://groups.google.com/group/openbd?hl=en
