Related to Ray's #3, if the number of configuration items is reasonably small, you can pass them into the CFC's init() method, if you use one, and then cache it in the CFC's instance variables. That's how I usually do DSNs:
<cfset application.dsn = "myDSN" /> <cfset application.myCFC = createObject(...) /> <cfset application.myCFC.init(application.dsn) /> --- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com > -----Original Message----- > From: Raymond Camden [mailto:[EMAIL PROTECTED] > Sent: Monday, August 25, 2003 10:59 AM > To: CF-Talk > Subject: RE: cfc vs php rule of thumb > > > There are a couple of different answers to this question. What follows > are just a few ideas, and may not always work best depending on your > situation. > > 1) One way to have a CFC read in 'config' information is to simply > define them as probably always did, application variables, and read them > from the CFC. Ie, have the cfc use Application.DSN for queries. This was > problematic before 6.1 though if the CFC itself was cached. Also, in > general, a CFC should not directly touch Application variables outside > the CFC. If you ever rename the Application variables, you would have to > update your CFCs to correct them. In general, I try to make my CFCs > never use anything 'on the outside'. > > 2) Hard code the values in the CFC, or <cfinclude> them. Your CFC can > very easily either do > > <cfset dsn = "foo"> > > or > > <cfinclude template="settings.cfm"> > > Another option, and one I use on my blog, is to use an ini file. > > 3) Why not make a CFC that represents your application, and stores the > values itself. Ie, an "Application" CFC. One style I've used in the past > is to have one CFC responsible for my application settings. So I could > ping it to get the app DSN, root path, etc. These values would be gotten > at startup and cached in the CFCs that used them. > > This is just a few ideas, but I hope it helps. > > ======================================================================== > === > 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: Mauricio Giraldo [mailto:[EMAIL PROTECTED] > > Sent: Monday, August 25, 2003 11:52 AM > > To: CF-Talk > > Subject: cfc vs php rule of thumb > > > > > > Hello > > > > When developing in PHP, it is common to have something like > > this in a class > > document: > > > > // start > > include 'my_config_file.php'; > > > > class MyClass { > > // properties and functions > > } > > // end > > > > Where my_config_file.php is a file that has constants and > > other shared variables. I am familiar with CFCs also but am > > not sure what would be the right way to go on this issue. It > > is good to have an external file with common variables, and > > sometimes people have them inside Application.cfm but you > > don't always want to have them there. > > > > Can anyone shed any light on this issue? > > > > Thanks > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
