You can write in-line code to load the XML file application params into application scope.. if you like doing it so..
The reason..to have a CFC/function/sub-routine do this..is because your code is much cleaner..than in-line...A change in the application/xml configurations.. might be just one change in the config.cfc than.. having to go through.. your entire in-line code. Joe Eugene -------Original Message------- From: Adam Wayne Lehman <[EMAIL PROTECTED]> Sent: 05/29/03 03:47 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] CFCs in memory > > I hear that, but I don't think it helps in this situation. I mean how reusable is config.cfc really going to be? Especially if all it's doing it loading a sole XML file. Maybe Justin will chime in and elaborate for us..... 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 Hal Helms Sent: Thursday, May 29, 2003 11:31 AM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] CFCs in memory One reason for defining information declaratively in an XML file or ini file is so that the code itself can be more easily reused. Hal Helms "Java for CF Programmers" class in Washington, DC June 23-27 www.halhelms.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Wayne Lehman Sent: Thursday, May 29, 2003 11:14 AM To: [EMAIL PROTECTED] 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). ---------------------------------------------------------- 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).
