I would suggest that if people take that approach that they be careful so they don't inadvertently permanently override them! :)
For example, go run this in your scribble pad: <cfset application.MyStruct = StructNew() /> <cfset application.MyStruct.Wow = "This is cool" /> <cfset request.MyStruct = application.MyStruct /> <cfset request.MyStruct.Wow = "Not so cool" /> <cfoutput>#application.MyStruct.Wow#</cfoutput> As you can see, we are actually modifying the one in the application scope by modifying the one in the request scope. ~Dave On 5/10/07, Eric Knipp <[EMAIL PROTECTED]> wrote:
At my last employer, we were working on a project that involved quite a few values in the application scope, which were then copied into the request scope on a per-request basis. The advantage here is the ease with which one or more of the "default" application values can be overridden. Just my 2 cents. Adrian, has this caused any performance or maintenance implications? Eric On 5/10/07, Joe Kelly < [EMAIL PROTECTED]> wrote: > > Someone from Universal Mind (Adobe Professional Services), a > consultant told my employer to put all the appication variable into > the request scope. But for the life of me, I can't remember why! I > believe this is left over from CF5 where we had to lock all our shared > scope variables. > > Also, this from CF7 live docs: > > Using the Request scope for static variables and constants > > This section describes how to partially break the rule described in > the section Referencing caller variables. Here, the function defines > variables in the Request scope. However, it is a specific solution to > a specific issue, where the following circumstances exist: > > * Your function initializes a large number of variables. > * The variables have either of the following characteristics: > o They must be static: they are used only in the function, > the function can change their values, and their values must persist > from one invocation of the function to the next. > o They are named constants; that is the variable value never > changes. > * Your application page (and any custom tags) calls the function > multiple times. > * You can assure that the variable names are used only by the > function. > > In these circumstances, you can improve efficiency and save processing > time by defining your function's variables in the Request scope, > rather than the Function scope. The function tests for the Request > scope variables and initializes them if they do not exist. In > subsequent calls, the variables exist and the function does not reset > them. > > > Either way, it makes the most sense to do it as Dave suggests, set a > stuct and check for it's existance. > > Thanks, > Joe Kelly > > > > On 5/10/07, Dave Shuck < [EMAIL PROTECTED]> wrote: > > I store large chunks of applications in the application scope of my > apps. In > > the case of most ColdFusion frameworks for instance, they are loaded > into > > memory (aka Application scope) on their first load. In our code on > > InstantSpot, we keep entire sites stored in memory. > > > > In a case like this, a simple 8 character string wouldn't make a dent! > :) > > > > ~Dave > > > > > > On 5/10/07, Kevin < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > Dave: > > > > > > > > > > > > I thought that it was better to store as few variables as possible > in the > > application scope. Is that not the case? > > > > > > > > > > > > > > > > > > -------------------------------------------------------- > > > > > > > > > > > > Kevin Fricke > > > > > > Lone Star Media > > > > > > [EMAIL PROTECTED] > > > > > > Office: (512) 371-1822 > > > > > > Mobile: (512) 626-0528 > > > > > > Fax: (512) 597-0909 > > > > > > Toll Free: (877) 791-7083 > > > > > > > > > > > > http://www.lonestarmedia.com > > > > > > > > > > > > > > > > > > > > > > > > > > > From: [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] > > On Behalf Of Dave Shuck > > > Sent: Thursday, May 10, 2007 2:21 PM > > > To: Dallas/Fort Worth ColdFusion User Group Mailing List > > > Subject: Re: [DFW CFUG] Application Variables > > > > > > > > > > > > > > > I wouldn't :) > > > > > > I often include things like this in configuration files rather than > inline > > in the code to keep it more portable, but there is nothing that would > keep > > you from doing this inline in your Application.cfm . > > > > > > I would actually take it a step further though. Just to keep from > setting > > and resetting on your application on every request I set my > application > > scoped variables in a block like this: > > > > > > <cfif NOT StructKeyExists(application,"DawnsDsn")> > > > <cflock > > name="#application.applicationname#_DawnsDsn" > > type="exclusive" timeout="30"> > > > <cfif NOT > > structKeyExists(application,"DawnsDsn")> > > > <cfset application.DawnsDsn = "SuperCoolDsn" /> > > > </cfif> > > > </cflock> > > > </cfif> > > > > > > The second conditional check is to ensure thread safety, which is > not a > > really important issue when it comes to something like setting a DSN, > but > > imo is still good practice. > > > > > > Hope that helps. > > > > > > ~Dave > > > > > > > > > > > > > > > On 5/10/07, Green, Ms. Dawn <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > In an application.cfc page, why would you use request variables to > set > > your datasource, rootname of your site & adminEmail instead of > Application > > variables? > > > > > > > > > > > > What are the pros and cons of doing it either way? > > > > > > > > > > > > Thanks for any help in clarifying this for me. > > > > > > > > > > > > Dawn Green > > > > > > > > > _______________________________________________ > > > Reply to DFWCFUG: > > > [email protected] > > > Subscribe/Unsubscribe: > > > http://lists1.safesecureweb.com/mailman/listinfo/list > > > List Archives: > > > http://www.mail-archive.com/list%40list.dfwcfug.org/ > > > http://www.mail-archive.com/list%40dfwcfug.org/ > > > DFWCFUG Sponsors: > > > www.instantspot.com/ > > > www.teksystems.com/ > > > > > > > > > > > > > > > -- > > > ~Dave Shuck > > > [EMAIL PROTECTED] > > > http://daveshuck.instantspot.com > > > _______________________________________________ > > > Reply to DFWCFUG: > > > [email protected] > > > Subscribe/Unsubscribe: > > > http://lists1.safesecureweb.com/mailman/listinfo/list > > > List Archives: > > > http://www.mail-archive.com/list%40list.dfwcfug.org/ > > > http://www.mail-archive.com/list%40dfwcfug.org/ > > > DFWCFUG Sponsors: > > > www.instantspot.com/ > > > www.teksystems.com/ > > > > > > > > > > > > > > -- > > ~Dave Shuck > > [EMAIL PROTECTED] > > http://daveshuck.instantspot.com > > _______________________________________________ > > Reply to DFWCFUG: > > [email protected] > > Subscribe/Unsubscribe: > > http://lists1.safesecureweb.com/mailman/listinfo/list > > List Archives: > > http://www.mail-archive.com/list%40list.dfwcfug.org/ > > http://www.mail-archive.com/list%40dfwcfug.org/ > > DFWCFUG Sponsors: > > www.instantspot.com/ > > www.teksystems.com/ > > > > > > _______________________________________________ > Reply to DFWCFUG: > [email protected] > Subscribe/Unsubscribe: > http://lists1.safesecureweb.com/mailman/listinfo/list > List Archives: > http://www.mail-archive.com/list%40list.dfwcfug.org/ > http://www.mail-archive.com/list%40dfwcfug.org/ > DFWCFUG Sponsors: > www.instantspot.com/ > www.teksystems.com/ > _______________________________________________ Reply to DFWCFUG: [email protected] Subscribe/Unsubscribe: http://lists1.safesecureweb.com/mailman/listinfo/list List Archives: http://www.mail-archive.com/list%40list.dfwcfug.org/ http://www.mail-archive.com/list%40dfwcfug.org/ DFWCFUG Sponsors: www.instantspot.com/ www.teksystems.com/
-- ~Dave Shuck [EMAIL PROTECTED] http://daveshuck.instantspot.com
_______________________________________________ Reply to DFWCFUG: [email protected] Subscribe/Unsubscribe: http://lists1.safesecureweb.com/mailman/listinfo/list List Archives: http://www.mail-archive.com/list%40list.dfwcfug.org/ http://www.mail-archive.com/list%40dfwcfug.org/ DFWCFUG Sponsors: www.instantspot.com/ www.teksystems.com/
