> defining application paths and datasources... so why even use XML? Why > not just hardcode all this into the CFC? Why why why?
Once your application is written and deployed ... you dont have to touch any code... and can configure the application for any given situation or environment via XML Configs files.. > defining application paths and datasources... so why even use XML? Why > not just hardcode all this into the CFC? Why why why? My understanding is.. the config.cfc is only called when "Application.appParams" struct that defines application variables doenst exist. ie <cfapplication Name="#Application.appParams.Name#....> I am not sure.. why everybody here is talking about putting the "config.cfc" in application scope.. dont see any need for this.... Joe Eugene ----- Original Message ----- From: "Adam Wayne Lehman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 29, 2003 11:13 AM Subject: RE: [CFCDev] CFCs in memory > I think we are assuming that it is not just static variables. Otherwise > why put so much attention on overhead of making multiple calls to this > CFC? He <i>is</i> reading an XML file, but if all these variables are > static... I wonder why? I hardly think a non-technical user would be > defining application paths and datasources... so why even use XML? Why > not just hardcode all this into the CFC? Why why why? > > Adam Wayne Lehman > Web Systems Developer > Johns Hopkins Bloomberg School of Public Health > Distance Education Division > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Raymond Camden > Sent: Thursday, May 29, 2003 9:42 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] CFCs in memory > > I'm curious why you advocated the use of cflock here? I didn't read his > original message, only the part your quoted, but it sounds like all he > is doing is reading in config data, static type data. How is it a race > condition if N threads all set the same values, ie > > <cfset foo = 5> > > I'm not saying the lock is wrong or bad - but I don't see how this is a > race condition, unless he has code that does something like > > <cfset startuptime = now()> > > Or did I miss that from his original email? > > ======================================================================== > === > Raymond Camden, ColdFusion Jedi Master for Mindseye, Inc > (www.mindseye.com) > Member of Team Macromedia (http://www.macromedia.com/go/teammacromedia) > > Email : [EMAIL PROTECTED] > Blog : www.camdenfamily.com/morpheus/blog > Yahoo IM : morpheus > > "My ally is the Force, and a powerful ally it is." - Yoda > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Sean A Corfield > > Sent: Wednesday, May 28, 2003 6:49 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [CFCDev] CFCs in memory > > > > > > On Wednesday, May 28, 2003, at 13:17 US/Pacific, Justin Balog wrote: > > > I know this information is in the list archive, but I can't > > get to the > > > site > > > right now. What I have done recently is set up a > > config.cfc that has > > > several methods that get DSN values, application paths, etc. The > > > config.cfc > > > reads an XML file to set these values. I really want to > > avoid having > > > to > > > read that file for every request, what is a good way to > > cache that cfc > > > so > > > that I don't have to make that read every time. Any input would be > > > much > > > appreciated. > > > > Stick it in application scope. Use code like this in Application.cfm: > > > > <cfif not structKeyExists(application,"configObject")> > > <cflock name="myAppNameConfiguration" type="exclusive"> > > <cfif not > > structKeyExists(application,"configObject")> > > <cfset application.configObject = > > > > createObject("component","config")/> > > <!--- any other initialization > > you need ---> > > </cfif> > > </cflock> > > </cfif> > > > > Why the if/lock/if, you might ask? Race conditions. You want > > to ensure > > only one request actually initializes it. > > > > Why put the unguarded if around the lock? The vast majority > > of requests > > will happen after the object has been initialized so you > > don't want the > > overhead of the lock on all requests. > > > > Why put the if inside the lock as well? In case another > > request hit the > > outer if at the same time as this request and went ahead and > > locked and > > created the object. This way you're guaranteed not to > > initialize twice. > > > > Sean A Corfield -- http://www.corfield.org/blog/ > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
