I think that in a lot of applications the extra overhead that you would incur using a config CFC might outweigh the benefit of abstracting the method by which the variables were generated.
On the other hand, I don't think there's anything technically wrong with doing that, and there are probably a good many arguments to say that it is a good idea from an architectural point of view. Again, I think it's really down to what you prefer to do, rather than there being an absolute right and wrong. Spike Stephen Milligan Team Macromedia - ColdFusion Co-author 'Reality Macromedia ColdFusion MX: Intranets and Content Management' http://spikefu.blogspot.com > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:cfcdev-owner@;cfczone.org] On Behalf Of Douglas Humphris > Sent: 31 October 2002 12:52 > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [CFCDev] [ cf-dev ] Config best practice > > > Thanks Spike, > > Do you think there would be a case for using a CFC for > storing global constants. Perhaps creating a controller CFC > which exposes the global vars and returning a struct which > can be set in request... > > Application.cfm > <cfscript> > objConfig = CreateObject("component","components.Config"); > request.strConfig = objConfig.getGlobals(); > </cfscript> > > where my Config.CFC gets the components either from the > include file or from the db depending on my preferences for > that application. Would this make sense? > > Douglas > > -----Original Message----- > From: Spike [mailto:spike@;spike.org.uk] > Sent: 31 October 2002 10:28 > To: [EMAIL PROTECTED] > Subject: RE: [ cf-dev ] Config best practice > > > I think there are perfectly good arguments for doing either of these. > > If you store the config information in the database it is > easier to create an interface to update and change them in a > live system. This can be a bad thing from a security point of > view, and a good thing from a flexibility/maintainability > point of view. > > If you set the config information in an included config file > using a <cfscript> block or a bunch of <cfset> tags, you will > have some overhead in setting the variables on each request, > but the overhead is so tiny as to be almost negligible. > > On a typical server, setting a couple of hundred variables > using cfset tags will take a few of milliseconds. If you're > effectively treating the variables as constants, I'd plump > with this option. > > Spike > > Stephen Milligan > Team Macromedia - ColdFusion > Co-author 'Reality Macromedia ColdFusion MX: Intranets and > Content Management' http://spikefu.blogspot.com > > > -----Original Message----- > > From: Douglas Humphris [mailto:Douglas.Humphris@;unitech.net] > > Sent: 31 October 2002 10:56 > > To: [EMAIL PROTECTED] > > Subject: [ cf-dev ] Config best practice > > > > > > I was having a chat with a colleague yesterday about whether > > we should be storing our configuration variables in a cfm > > file which is included in Application.cfm and stored in the > > db and cache the query call from Application.cfm. > > > > My gut feeling is to follow Sean Corfield's best practices > > recommendation: > > http://www.corfield.org/coldfusion/codingStandards.htm#Anchor34 > > > > ie use the included file with variables set in the request > > scope. However, the application we're working on currently > > uses something in the region of 100-200 application scoped > > variables. We're looking to transfer all those into either > > the request scope or a cached recordset so as to avoid > > locking. The cached recordset would probably provide better > > performance but is it good practice? > > > > The app currently supports CF4.5+ though we're hoping to move > > it out of the dark ages soon if we can put a strong enough > > case to our clients to move to CFMX. > > > > I was just wondering what people are doing with their global > > variables. What do you recommend? > > > > Cheers Doug > > > > > > -- > ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] For human help, e-mail: > [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). > > -- ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED]
