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/
