Storing variables in the application scope allows you to temporarily change
application-wide settings, which can be useful at times, for instance, if
you had an application which required scheduled maintenance to take several
minutes ( or hours or however long ), it's possible you might want to log
all users out or at least just preven them from making updates which might
interfere with the maintenance, in which case, you would want to use
something like this
<cfparam
name="application.maintenanceperiod"
type="boolean" default="false" />
in your application.cfm template -- then in the template for your scheduled
task to perform maintenance, you would use
<cfset application.maintenanceperiod = true />
... do maintenance here ...
<cfset application.maintenanceperiod = false />
On CF 5 you would want to lock references to your
application.maintenanceperiod variable, however, the viability of this as a
means of isolating the maintenance routine is still good in either CF 5 or
CF MX.
On the other hand, I would tend to avoid placing variables like datasource
names, server addresses ( mail server for instance ) and url's in the
application scope because these variables change rarely and usually not for
short periods of time, so imo placing them in the application scope is an
unnecessary use of persistent memory and it's best to just declare them in
the application.cfm or the like and then update that template when changes
are necessary.
I'm not saying this is "best case" or anything -- just my opinions about it.
s. isaac dealey 954-776-0046
new epoch http://www.turnkey.to
lead architect, tapestry cms http://products.turnkey.to
certified advanced coldfusion 5 developer
http://www.macromedia.com/v1/handlers/index.cfm?ID=21816
> I would agree. At a conceptual level. If a variable is
> being used a
> lot, however, it may make not make sense to store it in a
> local (or
> request) variable to avoid the need for locks.
> Of course, that was in CF5. I don't know of best
> practices for CFMX yet.
> At 01:08 PM 11/25/2002 -0600, you wrote:
>>So, it seems to me that in a purist sense, common values
>>across all Users
>>belong in application variables.
>>
>>-----Original Message-----
>>From: Jeffry Houser [mailto:[EMAIL PROTECTED]]
>>Sent: Monday, November 25, 2002 1:06 PM
>>To: CF-Talk
>>Subject: Re: Application variables
>>
>>
>> Request variables and Application variables are two
>> completely different
>>things, so i don't know if they deserve direct comparison.
>>It depends what
>>you want to use them for.
>>
>> Request variables exist during a single page execution.
>> They are not persistent across page requests.
>> You do not need to lock them.
>> If 100 users hit the same page at once, then 100
>> instances of each
>>request variable will exist simultaneously.
>> Request variables are available to all templates in the
>> request,
>>including custom tags. Because of this, I like to say
>>that they are global
>>to the request. Many people use them to avoid passing
>>parameters into
>>custom tags. I feel that is the only use for them over
>>local variables
>>(I.E. the variables scope ).
>>
>> Application variables are locked into an application
>> via the
>>cfapplication tag.
>> They are persistent across page requests.
>> You really should lock them.
>> If 100 users hit the same page at once, then only 1
>> copy of each
>>application variable will exist.
>> They are available to all templates in the request,
>> including custom
>>tags.
>>
>> Does that give you enough to go on?
>>
>>
>>At 10:40 AM 11/25/2002 -0800, you wrote:
>> >From: "Andy Ousterhout" <[EMAIL PROTECTED]>
>> >To: "CF-Talk" <[EMAIL PROTECTED]>
>> >Sent: Monday, November 25, 2002 10:31 AM
>> >Subject: RE: Application variables
>> >
>> >
>> > > What's are the Pro's and Con's of using Request
>> > > Variables over
>> >Application
>> > > Var?
>> > >
>>
>>
>>
>>--
>>Jeffry Houser | mailto:[EMAIL PROTECTED]
>>DotComIt, Putting you on the web
>>AIM: Reboog711 | Phone: 1-203-379-0773
>>--
>>My CFMX Book:
>><http://www.amazon.com/exec/obidos/ASIN/0072225564/instant
>>coldfu-20>
>>My Books: http://www.instantcoldfusion.com
>>My Band: http://www.farcryfly.com
>>
>>
>>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~~~~~~~~~|
> Archives:
> http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
> Subscription: http://www.houseoffusion.com/cf_lists/index.
> cfm?method=subscribe&forumid=4
> FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
> This list and all House of Fusion resources hosted by
> CFHosting.com. The place for dependable ColdFusion
> Hosting.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
