Here is my application.cfm file:
cfapplication name=appname
applicationtimeout=#CreateTimeSpan(2, 0, 0,
0)#
cfparam name=application.appnameroot default=/appname
cfparam name=application.includesDir default=/appname/includes
cfparam name=application.imagesDir default=/appname/images
Definately wrap a lock around those, and I would only run that block if 1 of the vars
inside isn't
defined (if 1 isn't then they all aren'tlike when CF Server is restarted).
As far as CFPARAM goes
You are correct in using it herewhy write 3 lines of code when you can write 1 ;-)
1. You should lock the entire group with a CFLOCK and a scope of application.
2. An IsDefined() with a set is actually slightly faster than a CFAPPLICATION. There's
even a UDF that does just this and its still faster even with the small UDF overhead.
Note that this is limited to the
. Are there any exceptions to the
rule?
Sharon
- Original Message -
From: Michael Dinowitz [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Tuesday, March 26, 2002 11:35 AM
Subject: Re: cfparam vs. cfif/isDefined/cfset
1. You should lock the entire group with a CFLOCK and a scope of
application
[EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Tuesday, March 26, 2002 4:33 PM
Subject: Re: cfparam vs. cfif/isDefined/cfset
Definately wrap a lock around those, and I would only run that block if 1
of the vars inside isn't
defined (if 1 isn't then they all aren'tlike when CF Server
Yes, they MUST be locked.
These look like variables that don't change - I'd do a CFIF test on one, and if it
doesn't exist then set them all. As long as you always set them all together, you can
use the existence of one to test for all.
This way the app vars are set only once, and don't bog
Subject: Re: cfparam vs. cfif/isDefined/cfset
I tend to set all the commonly used defaults as Request scope variables. No
locking, no cfparam, available anywhere.
cfscript
REQUEST.dsn = myDSN;
REQUEST.dbType = dbtype;
REQUEST.webRoot = C:/inetpub/wwwroot/;
etc...
/cfscript
PS
Subject: Re: cfparam vs. cfif/isDefined/cfset
Yes, they MUST be locked.
These look like variables that don't change - I'd do a CFIF test on one, and
if it doesn't exist then set them all. As long as you always set them all
together, you can use the existence of one to test for all.
This way
needed. And keep in mind that only YOU know the right answer for your
needs.
My two cents worth.
Shawn Grover
-Original Message-
From: Chris Norloff [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 26, 2002 1:11 PM
To: CF-Talk
Subject: Re: cfparam vs. cfif/isDefined/cfset
Yes, they MUST
the request scope and you don't
have to mess with locking.
Anthony Petruzzi
Webmaster
954-321-4703
http://www.sheriff.org
-Original Message-
From: Chris Norloff [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 26, 2002 1:11 PM
To: CF-Talk
Subject: Re: cfparam vs. cfif/isDefined/cfset
Yes
Subject: RE: cfparam vs. cfif/isDefined/cfset
So you don't have to set the variable again and again, with every request.
Chris Norloff
-- Original Message --
from: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
date: Tue, 26 Mar 2002 13:18:40 -0500
why
, 2002 1:11 PM
To: CF-Talk
Subject: Re: cfparam vs. cfif/isDefined/cfset
Yes, they MUST be locked.
These look like variables that don't change - I'd do a CFIF test on one, and
if it doesn't exist then set them all. As long as you always set them all
together, you can use the existence of one
Subject: RE: cfparam vs. cfif/isDefined/cfset
So you don't have to set the variable again and again, with every request.
Chris Norloff
-- Original Message --
from: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
date: Tue, 26 Mar 2002 13:18:40 -0500
why use
it?... grins
Shawn Grover
-Original Message-
From: Chris Norloff [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 26, 2002 11:58 AM
To: CF-Talk
Subject: RE: cfparam vs. cfif/isDefined/cfset
snip
For example: we maintain 5 server locations, some secure and some not. Some
of the site-specific
14 matches
Mail list logo
