Using CFParam Inside a CFFunction
I've been seeing more and more code using the cfparam tag inside cffunction methods. Take the following code sample as an example.
<cfargument name="myEvent" type="Struct" />
<cfset var local = {} />
<cfparam name="myEvent.myList" default="" />
<cfloop list="#myEvent.myList#" index="local.listItem">
... do something here ...
</cfloop>
<cfreturn true />
</cffunction>
Is this a best practice? To me it just feels wrong. If it was my code I would be using StructKeyExists(myEvent,"myList") and if that failed throw some kind of exception. Maybe I'm missing something.
What do you all think?
Comments
- andrew
when you cfparam, doesn't it actually put that variable into the variable scope?
- January 19, 2010, 11:32 PM
- Henry Ho
If you're using CF9, the cfparam eqv might be:
if (isNull(name))
y = default;
but.. in your code example, wouldn't it be better if execute the loop only if StructKeyExists(myEvent,"myList") ? much more efficient.
- January 20, 2010, 12:29 AM
- Steve Good
@Andrew No, in my example the param would place a default value for myList in myEvent in the arguments scope.
@Henry Just below my example I said the same thing. I feel it would be a better option to use structKeyExists() and use some form of error catching when the struct key does not exist. I really just wanted to know from others why they might or might not be using cfparam within a cffunction. It seems like a bad shortcut.
- January 20, 2010, 12:55 AM
- Ben Nadel
The only place I have really used CFParam inside of a CFFunction was as an experiment when dealing with function that have a dynamic number of arguments. Essentially, I was using CFParam in lieu of CFargument since I was not sure which arguments would correspond to which argument indexes.
But, I have never really done it outside of that.
- January 24, 2010, 1:33 AM
- andy Jarrett
My comment turned in to post at http://www.andyjarrett.com/blog/index.cfm/2010/1/27/A-comment-on-using-CFParam-inside-a-CFFunction
In short I've started using it since moving to FW/1
- January 27, 2010, 3:17 AM