I create a CFC with the same name as my application. From the other CFC, in my constructor, I can do:
<cfinvoke components="cflib" method="getSettings" returnVariable="settings"> Then my queries use settings.dsn. My Application.cfm makes the same call so it can just global vars as well. I use this instead of a app_globals file now. ======================================================================== === 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 > [EMAIL PROTECTED] > Sent: Friday, September 26, 2003 8:45 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Top Ten Tips for Developing ColdFusion > Components > > > with this in mind, what's a 'best' practise for getting > global config data into a CFC? For example, a datasource > name. Does one include an app_globals styled file into the cfc? > > Doug > > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >Behalf Of Andre Mohamed > >Sent: Friday, September 26, 2003 10:17 AM > >To: [EMAIL PROTECTED] > >Subject: RE: [CFCDev] Top Ten Tips for Developing ColdFusion > Components > > > > > >Dave, > > > >I noticed the conspicuous lack of locking code for that example too. > >However, locking WITHIN the cfc, as you point out, is not > necessary as > >the CFC should not be manipulating any session variables > itself due to > >the fact that the whole CFC is "persisted" in the session > scope. This > >seems to be some source of continued confusion. > > > >Indeed, the CFC should GENERALLY not need to know whether it is > >persisted or not. > > > >Furthermore, as I'm sure has been discussed a million times, > it seems > >very unlikely a CFC would need to know about any persistent scope > >unless it was primarily concerned with managing those scopes in some > >way or another. > > > >Regards, > > > >Andr� > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >Behalf > >> Of Dave Carabetta > >> Sent: 26 September 2003 14:59 > >> To: [EMAIL PROTECTED] > >> Subject: Re: [CFCDev] Top Ten Tips for Developing ColdFusion > >Components > >> > >> >For all you non blog readers, O'Reilly's Web DevCenter > has posted an > >> >article I wrote called "Top Ten Tips for Developing ColdFusion > >> Components". > >> >It's a distillation of material from my book, and some of > the great > >> >discussions that have taken place on this list. Let me know any > >feedback > >> >you all might have. > >> > > >> > >>http://www.oreillynet.com/pub/a/javascript/2003/09/24/coldfusi > >on_tips.h > >tm > >> l > >> > > >> > >> Rob, > >> > >> Nice work on the document. That's a nice, concise document > that I'm > >> definitely bookmarking. > >> > >> However, I had one (minor) issue regarding the shared > variable scopes > >> point (#5). With all the confusion out there regarding > locking in MX, > >> I was hoping > >> to have seen a note in there regarding the need to lock > >within the CFC > >> itself, especially as it pertains to the session scope. I > >think that a > >lot > >> of readers will be relative beginners to CFCs, and not mentioning > >locking, > >> even as a side note, in my opinion, could send the wrong > >message. Your > >> particular example, a shopping cart, is probably the most obvious > >example > >> of > >> where locking is important. > >> > >> Other than that, again, I appreciate the work on the > >article, as there > >are > >> some great pointers in there. > >> > >> Regards, > >> Dave. > >> > >> _________________________________________________________________ > >> Instant message in style with MSN Messenger 6.0. Download it > >now FREE! > >> http://msnmessenger-download.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). > >> > >> An archive of the CFCDev list is available at www.mail- > >> archive.com/[EMAIL PROTECTED] > > > >---------------------------------------------------------- > >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). > > > >An archive of the CFCDev list is available at > >www.mail-archive.com/[EMAIL PROTECTED] > > > ---------------------------------------------------------- > 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). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- 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). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
