Andy Jarrett: A comment on using CFParam inside a CFFunction

Loading Twitter

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?

Comments (4) | Print | Send | 2487 Views

If you like what you see on the website and/or this post has helped you out in some way please consider donating to help keep me in beer vodka. The donations are made through Paypal, which accepts almost any credit card or eCheck.

(Comment Moderation is enabled. Your comment will not appear until approved.)

[Add Comment] [Subscribe to Comments]

Posted By Justin Carter @ 1/27/10 7:36 PM

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.

Posted By Andy Jarrett @ 1/28/10 1:47 AM

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 :)

Posted By Justin Carter @ 1/30/10 8:16 PM

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.

Posted By Dawesi @ 4/12/10 2:16 AM

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

[Add Comment]