I agree, if you are using the application scope, they must be locked.
However, I fail to see a need to scope the variables (meaning local scope).
If Application.cfm gets run on every page (except includes, cfmodules/custom
tags), then these variables are ALWAYS available to you.
As for the CFIF to determine if they exist, that's the purpose of CFPARAM
with a default attribute. If the parameter exists, it is used as is,
otherwise it is created with the default value. I've heard some talk over
time as to performance issues and such regarding CFPARAM and IsDefined(),
but have never seen a definitive answer saying one is most definetly
faster - and my own testing says they are both fast enough (for my purposes
at least).
Some people will recommend putting all your variables in the Request scope
(thereby allowing custom tags to have access to them). I look at this as
declaring all your variables as global - which is frowned on in other
programming languages (C/C++, VB, Fortran, etc.) because it means more
care/management is required to make sure they are not being inadvertently
changed in some obscure function. It is better programming practice to use
the smallest scope (local scope) where possible, and pass parameters to
functions (or custom tags in this case). Those who would dispute this
either know something I don't, or don't have much experience outside web
development (no offense intended...).
As for my own practices regarding variables similar to what you've shown, I
declare a LOCAL scoped structure called App.
Then make each variable a member of the structure. For example:
<cfscript>
App = StructNew();
//Datasources
StructInsert(App, "DSN", "MyDSN");
//Locations
StructInsert(App, "BaseURL", "http://localhost/myapp";);
StructInsert(App, "BaseDirectory", "/myapp");
structInsert(App, "IncludesDir", "#App.BaseDirectory#/includes";
......
</cfscript>
With a little more thought, it's possible to declare the structure in the
application or session scope, and only create it once. Just be sure to lock
where 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 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 down your pages,
since Application.cfm is called with every request.
Chris Norloff
---------- Original Message ----------------------------------
from: "Earl, George" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
date: Tue, 26 Mar 2002 11:21:07 -0500
>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">
><cfparam name="application.menusDir" default="/appname/menus">
><cfparam name="application.templatesDir" default="/appname/templates">
><cfparam name="application.smapDir" default="/appname/smap">
>
>Should I be locking these cfparam tags? Should I wrap them all in one lock
>or should I lock each one individually?
>
>What is the difference between using cfparam tags as I have above and using
>cfif with isDefined and cfset to accomplish the same thing? Is one method a
>better practice than the other?
>
>Thanks!
>
>George
>[EMAIL PROTECTED]
>
______________________________________________________________________
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
