Why I Like, and Use, CFScript

Many, many moons ago, I began a journey to learn web development. Actually it was a re-acquaintance, as I had gotten side tracked for a few years in a poor business partnership, having to catch up on how much things had changed. During that time, HTML had moved for v2 to 4, CSS was the crazy new thing replacing font and center tags, Dynamic HTML was making JavaScript hot again, and the browser wars were making life impossible.

Back then I was on the LA Tech Edu JavaScript mailing list (sadly retired, years ago). This guy named Peter Paul Koch was a major contributor to the list, and just ramping up this little site called QuirksMode. Scripting, though somewhat nightmarish with the browser wars, was actually a lot of fun. My first shopping cart was completely JS based.

I have always pushed for full parity between cfscript and tags, because scripting is more natural to me, in terms of writing programmatic logic. Sure, cfoutput and cfloop make a lot of sense in the middle of html display code, but CFC's don't (typically) contain display code, being data access and model objects.

I have issues with the implementation of CFScript. I find that there are a lot of functions of similar actions with completely different naming conventions, and argument requirements, and more. I think these things need to be addressed. That said, if I have to call the function anyway, I prefer script to tags when it's outside of display. It's a more natural approach, to me. 99 times out of 100 I end up with less lines of code, and find the logic more defined, clear cut, and easier to understand.

It's not for everyone. There are many that just plain hate cfscript, and that's their prerogative. But I will continue to use cfscript, and my examples will show that, because I personally find it a better way to write code. If it's not your preference, that's fine, you're welcome to translate my examples to tags if you need to, but for me this is how I do it. (For the record, many of the newer functions are not identical, under the hood [base Java code], as their tag counterparts, and some scripted functions have been proven to have better performance than their tag counterparts. There are benchmarks for this out there, somewhere, if you feel strongly enough to go look for them. I just take it on my experience with using it.)

Build A Better ColdFusion App: When The Var Doesn't Exist

Author's Note: Due to some of the feedback below, I'm going to remove a bit of example regarding paraming objects (see the feedback). Some have actually benchmarked where this creates overhead, rather than improvement of performance, so I'm going to stick with simple variables as this is researched further.

So, let's kick off this round of "Build a Better CF App" with a simple bit of code that you might see quite often in an app:

view plain print about
1<cfif NOT StructKeyExists(FORM, "isactive")>
2    <cfset FORM.isactive = false>
3</cfif>

Simple, right? Probably dozens of these hanging around in your code. Now, let's look at a simpler form, that also gives us the added benefit of type checking.

view plain print about
1<cfscript>
2    param name="FORM.isactive" type="boolean" default=false;
3
</cfscript>

What? Huh? Yeah, this makes sense. See, a checkbox type formfield doesn't actually get passed on form submission if it isn't checked, so chances are you're running this same code, in one way or the other, to default that value for you. Utilizing the param here (cfparam in tag form, but who's using tags outside of display stuff anymore? [hint, hint]) is really the better way of handling this.

  1. You get a default value for the variable
  2. The default is overridden, if the variable actually occurs
  3. If the variable does exist, the param ensures that it is of the proper type
  4. But wait, let's throw in another similar bit of code for good measure. How many times have you seen something like this?:

    view plain print about
    1<cffunction name="getUser" output="false" returntype="User">
    2    <cfargument name="firstName" type="string" required="true">
    3    <cfargument name="lastName" type="string" required="true">
    4
    5    <cfif NOT StructKeyExists(ARGUMENTS, "userID")>
    6        <cfset ARGUMENTS.userID = 0>
    7    </cfif>
    8
    9    <!--- More code --->
    10    <cfreturn LOCAL.User>
    11</cffunction>

    Just doesn't feel right, does it? Especially when ColdFusion already gives us a way to handle this scenario:

    view plain print about
    1public com.mysite.User function getUser (required string firstName, required string lastName, numeric userID=0) {
    2    // More code
    3    return LOCAL.User;
    4}

    You can apply a default value to any argument of a function, utilizing your arguments just as you would a param.

    Now, there may be some valid reason for not paraming a variable, and using conditionals in some way similar to those above. They're few and far between, but there are exceptions to most every rule, so you'll need to evaluate that when the time comes.