Well, I personally keep them rolled up into a configObject as typically when i need constants its used in both my cfc's and my normal cfm.
That being said, i don't want to roll that information per request as the configObject pretty much has the global crap inside it..and yes i'm going to bring out that OO bible and preech thine singleton to thee. As I use xml to define some settings at times - what can i say, i have a chubby for a mach-ii sytle approach in development - its rapid so back off man. Depends on the app in the end, my option can be long winded for a really small app that has like zero need for a complex solution like the above. hmm as for seans why not use request in the end... good question. In that do you get any real gains by using CFIF StructKeyExists(application,"keyToSettings") THEN initialize vars... vs just rolling them inside request vars? if they are simple? I've noticed that a lot and now that he brings it out to air, i wonder ...*in a deep pondering voice* hmmmmmmmmmmmmm.... On 4/20/05, Sean Corfield <[EMAIL PROTECTED]> wrote: > On 4/19/05, Ryan Sabir <[EMAIL PROTECTED]> wrote: > > <CFSET request.dsn = "blah"> > ... > > What's the best practice in this case? > > I'd go with request scope. Why put this in application scope? What > benefit do you get from using application scope for simple variables > here? > -- > Sean A Corfield -- http://corfield.org/ > Team Fusebox -- http://fusebox.org/ > Got Gmail? -- I have 50, yes 50, invites to give away! > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > --- > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > To unsubscribe send a blank email to [EMAIL PROTECTED] > Aussie Macromedia Developers: http://lists.daemon.com.au/ > -- Regards, Scott Barnes http://www.mossyblog.com http://www.flexcoder.com (Coming Soon) --- You are currently subscribed to cfaussie as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
