You don't have to set Application variable in the Application.cfm - you
can set them anyplace.
You DON'T want to set to set them every request however - that defeats
the purpose of the Application scope. ;^)
The most common way to do this is to set a "marker" variable of some
kind (I use "Application.AppSet ") in this way:
<cfif NOT IsDefined("Application.AppSet")>
<cfset Application.Foo = 1>
<cfset Application.Faa = 2>
<cfset Application.AppSet = True>
</cfif>
This way your variables will only be set once - the first time the
application is run (after a server/service reboot or application
timeout).
Additionally many people add in a trigger to allow them to reset them
"on command" as well (this makes it easier to change the variables in
development). Changing the first line to something like this:
<cfif NOT IsDefined("Application.AppSet") OR IsDefined("URL.ResetApp")>
In this case if you pass "anyfile.cfm?ResetApp=Y" it will rebuild your
application variables. You may want to make a certain value required
for ResetApp (basically a reset password) or only allow administrators
to do it (if your site supports roles-based security) but that's the
general idea.
Jim Davis
> -----Original Message-----
> From: Ryan Mitchell [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 07, 2003 10:38 AM
> To: CF-Talk
> Subject: Re: Request vs application
>
> Cool, that�s what I was thinking, its nice to double check.
> I'm mx, so I guess I'll have to change them all to application scope
:)
>
> I've not stored constants there before, do I still have to set them in
the
> application.cfm file? That will mean they get overwritten every
request?
>
>
> On 7/9/03 14:33, "Gyrus" <[EMAIL PROTECTED]> wrote:
>
> > At 13:24 07/09/2003 +0100, you wrote:
> >> I've just developed a site where I have a lot of request variables
> defined
> >> in application.cfm, which are constant values...
> >>
> >> Would there be benefit in defining these as application variables?
> >
> > If you're using CFMX, probably best to store constants in the
> Application
> > scope. Unless there are "race condition" risks (i.e. risk of two
> processes
> > updating a value at once), which is very unlikely with constants,
you
> don't
> > need to lock the scope when you access the vars. Then you've got
them
> all
> > stored once for the whole application, whereas putting them in the
> Request
> > scope stores them in memory once for every current request.
> >
> > Pre-MX, my rules-of-thumb are:
> >
> > - Store frequently accessed constants and variables in the Request
scope
> > for ease of access
> > - Store anything only accessed once or twice during any request in
the
> > Application scope, and remember to lock when reading
> > - The larger and less frequently accessed the data, the better
candidate
> it
> > is for storing in Application, and vice versa for Request
> >
> > HTH,
> >
> > Gyrus
> > [EMAIL PROTECTED]
> > play: http://norlonto.net/
> > work: http://tengai.co.uk/
> > PGP key available
> >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
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
