A comment on using CFParam inside a CFFunction

This is a response/comment to Steve Goods post named: Using CFParam Inside a CFFunction. Its turned into a blog post because, well I suppose I am looking for a wider feedback on my thoughts.

When it comes to using <cfparam> in a <cffunction> I would never of even contemplated it up to a few weeks ago, mainly because of the framework I was using gave me other ways of checking of variables existence.But I've moved over to Framework One (FW/1) which uses the tag in its controllers for some of the demos and I've now adopted this in to my recent code.

This then got me thinking that I cannot find a solid case reason as to write

view plain print about
1if ( NOT StructKeyExists(myVar, "somekey") )
2{
3myVar.someKey = "0";
4}
5else if ( NOT isNumeric( myVar.somekey ) )
6{
7throw();
8}

when cfparam does that all in one go with basic type checking aswell.

view plain print about
1<cfparam name="myVar.somekey" default="0" type="integer" />

You could wrap the if() logic in a function to be used but then aren't you just adding an extra layer to your code to do something CF already handles?

Posted: 27-Jan-2010

View: 3550

Permalink: here

Comments

The only "problem" with using cfparam and the type attribute is that if the type check fails then you need to catch and handle the error. Ben Nadel has suggested in the past that perhaps there should be an addition attribute (or some kind of setting, somehow) to allow the cfparam default to override the invalid value when the type doesn't match. This would be particularly useful in handling url and form variables which can be notoriously "dirty" (i.e. always require setting / validating / cleaning) as they are each to change on the client or for search engines to ignore. It's also nice to be able to avoid the performance hit of try/catch when possible.

#1 Justin Carter
27/Jan/10 7:36 PM

Personally I wouldn't use it for type checking anyway. That kind of checking I like to roll myself. The point of the blog was more to see wheres the bad side in using it in controllers to make sure your views have the vars they need :)

#2 Andy Jarrett
28/Jan/10 1:47 AM

I guess that's my point, the only "bad side" is that you need to be catching any exceptions thrown - but in your case you are manually using throw() in the code you are comparing it to, so you've already got it covered :) I don't think it matters at all where you use cfparam, as long as it's doing the job you need.

#3 Justin Carter
30/Jan/10 8:16 PM

I guess you could always write a cfparam function that handles the exception yourself until adobe thinks it worthy of Ben's idea...

#4 Dawesi
12/Apr/10 2:16 AM