A Better CFParam Tag With A Catch Attribute (Proof Of Concept)

I think you need this http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

Why not just:

<cfif not isDefined(paramName) and not isValid(paramName,validationType)>
<cfset paramName = defaultValue />
</cfif>

Oops, isValid() has its args the other way round (type first, then value).

And it should be 'or' not 'and'.

Sheesh, I must need more coffee!

...because throwing an exception is a very expensive operation that can be avoided by using a conditional?

Ben,

I personally hardly ever use <cfparam>... not so much, because it is lacking a feature, but, because I got used to IsDefined().

Plus, isDefined() executes much faster than <cfparam>. I did some tests a couple of years ago and on my machines IsDefined() would be about 100 times faster than <cfparam>.

On the other hand, the user would only notice the difference if there were literally 1000s of <cfparams> (The user won't notice 100 ms difference in page loading.) So I guess it all comes down to personal coding preference. ;-)

Chris

Chris, as far as I'm aware structKeyExists() executes faster than isDefined().

This is because isDefined() searches each scope in turn, but with structKeyExists() you specify the scope (i.e. the structure) to search.

e.g. <cfif not structKeyExists(url,"foo")>...</cfif>

@Fred,

of course, searching scopes takes time, but, nothing stops you from specifying a scope with isDefined(), too. ;-)

<cfif NOT IsDefined("url.foo")>

Actually, with the exception of the variables scope I personally scope all variables. (I'm just too lazy for scoping local variables. ;-P)

Chris

Chris, I could be wrong but I think that isDefined("url.foo") will first search the variables scope for "variables.url.foo"

http://corfield.org/blog/index.cfm/do/blog.entry/entry/isDefined_vs_structKeyExists

Fred,

I wasn't aware that IsDefined() behaved like that, thanks for pointing that out!

I got curious and just for the fun of it wrote a small test to compare the two functions. I found that when searching the variables scope, IsDefined() is usually faster, when searching other scopes, StructKeyExists() is faster most of the time.

But, as I said before, the difference is so small that I'd always prefer readability over a couple of ms. It was like 0.2 secs difference max for 10000 function calls... now how realistic a scenario is that? ;-))

And although <cfparam> is mucgh slower, even that difference will not be noticed by any user in real world examples.

But I have to admit... sometimes it IS fun to play around like this. ;-P

Chris

Another more significant benefit of isDefined + isValid over try/catch:
(Can't remember if this is the cfparam/default or cfargument/default), but I'm sure I read somewhere that the default value is evaluated even when its not actually used. So if you had:
<cfparam name="bob" value="#readNext('Bob')#"/>
then the function executes even if bob is actually defined, and I think Sean's suggestion would allow this to be bypassed, which is what I think would often be required?

But... would there be any benefit in doing both Sean & Ben's stuff together?
ie: first the lightweight conditional, and then the try-catch as a backup.

This is assuming that
1) the try-catch is only heavy/expensive if an exception is generated.
2) there might be something that could throw an error with the isDefined/isValid stuff.
I can't think of any reason for it, but it can be nice to have a safety net, right?

Ben,

I don't know if one could say "using it wrong".

Come to think of it, I use <cfparam> on form pages only, when I want to prefill a form control:
<cfparam name="form.foo" default=""/>
<form>
<input type="text" name="foo" value="#form.foo#"/>
</form>

My apps are usually CFC based, Fusebox + CFCs that is, not so much OO. So I pass the complete attributes struct to a method and inside that method I check with isDefined()

circuit.xml.cfm:
<invoke object="fooBar" methodcall="saveObject(argumentcollection=attributes)" returnvariable="error"/>

fooBar.cfc
<cffunction name="saveObject"...>
<cfset var whatever=""/>
<cfif NOT IsDefined("arguments.foo")>
... do something
</cfif>

Actually I think that StructKeyExists() would be better here, not because of performance, but, because I pass a struct into the method and want to know if a specific key exists... so StructKeyExists() seems not only more granular but also more consistent.

Chris

I'm with you, Ben. I find it much more readable to "group" my parameters at the top of the page. Sort of takes the place of explicitly declaring stuff, I suppose.

When I know something is (or might be) coming in, I like to state that at the top of my processing. Partly for error trapping/initialization and partly for my own awareness. Keeps me from forgetting stuff and protects me from myself. Having isDefined() calls scattered throughout the code isn't very clean to me.

I tend not to use the type functionality, though, since I have to catch errors anyway, I'd rather just catch the error when I try to do something with it. For the most part, I don't think parameter type validation errors should be fatal unless they create a runtime error that is, in fact, fatal. For most of my work, I prefer to let errors just alter my course rather than halt processing entirely.

@Ben,

Screw what everyone else is saying, I think it's brilliant :)

<Ben>I think you might have meant the "default" attribute:</Ben>

Ah crap! I always do that. :(

I think it would be nifty, too. But I never put try/catch around cfparams so it wouldn't be as time-saving for me. It would allow allow you to replace something like this:

<cfif not (isDefined("name") and reFindNoCase("^pattern$", name))>
<cfset name = default />
</cfif>

With this:

<cfparam name="name" type="regex" pattern="pattern" default="default" catch="default" />

"Yeah, it seems like hardly anyone "validation" features of the CFParam tag."

Personally I've never used the validation features of the cfparam tag or the isValid function (other than type validation like for query, array, or integer) because the documentation doesn't show the actual rules behind of the more vague validation types. For example, cfparam/isValid can supposedly validate an email address. What the hell!? Why would I trust the rules for a valid email address that I can't see?

I'm sure the ColdFusion engineers realize that people have come up with literally thousands of regexes to validate email addresses, with varying degrees of accuracy. If I'm going to use a regex to validate an email address (or other things they have on the list like "telephone"), I want to see the rules behind it to ensure it actually meets my needs/expectations.

In order to really validate an email address according to the official spec, you'd have to use a regex like the one shown at http://www.regular-expressions.info/email.html under the heading "The Official Standard: RFC 822", which is over 6300 characters long, and it matches so much crazy stuff that it's completely impractical in the real world anyway.

Just curious. *Why* would you want to default a value if it fails validation? Going to the extreme here, but if I was filling out a "Donate to Ben" form and I put "Foo" in the amount box that you happened to be using a CFPARAM for that required it to be numeric, I would hope you would show me an error vs. putting a CATCH amount of 500 in for me. The point is what was the users intent. If I don't pass anything and you use a default value, that's one thing, but if the user actually supplies a value and you cannot interpret what their input means, then you should ask for new input.

Ben, I'm TOTALLY with you on this.

Using cfparam is both elegant (to look at) and also nasty (to handle errors).

Using multiple isValid and isDefined cfif staements is not my idea of fun. An additional attribute would be a welcome addition.