So here's the deal. I have a Config object. It is passed a path to an XML file, and upon init, it processes all the XML and creates variables needed so that in the end you can make calls to it like 'Config.getSetting( 'nameOfSetting' )'. Well, one of the things the XML file defines are ColdFusion THIS-scope settings like 'sessionManagement', 'applicationTimeout', etc.
In the application.cfc, I was thinking about having the following code:
<cfif isDefined( 'application.Config' )>
<cfset application.Config.processPseudoConstructor() />
<cfelse>
<cfset tmpConfig = new path.to.Config( 'path/to/config.xml' ) />
<cfset tmpConfig.processPseudoConstructor() />
</cfif>
What the processPseudoConstructo() function does is execute an interative loop over all the (now-existing) internal-to-Config 'this-scoped' values, so it will be setting ColdFusion this-scoped variables needed on the first call to the application. This should hopefully make CF happy that those values exist before any Built-in functions like onApplicationStart() or onRequestStart() are called.
But, of course, since this is the FIRST run through (where application.Config doesn't yet exist) it runs the <cfelse>, which creates a 'tmpConfig' object, placed into the variables scope. Afterwards, it runs the same processPseudoConstructor() method to ensure that, even on the first run, CF has all its this-scope variables. Of course, in the onApplicationStart, the first line will be:
<cfset application.Config = duplicate( tmpConfig ) />
Hopefully, this will create a duplicate of the tmpConfig object (rather than a pointer to something that would die at the end of the request, since it's in the variables scope) and give persistence to the Config object.
Lastly, on each subsequent call to the application, where onApplicationStart() won't be running (because the application is initialized), the code above in the pseudo-constructor will evaluate <cfif isDefined( 'application.Config' )> and that should return true, so that in each request to the application, the processPseudoConstructor() is run, and CF has it's this-scoped variables processed, all ultimately pulled from a single configuration XML file.
Does this sound like a fool-proof OO methodology for getting a first/subsequent request Config object up and running, or can you see any potential holes in my plan?
AdChoices