An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

Improving CFSCRIPT

December 29, 2009 · 4 Comments

One of the new features in Adobe's ColdFusion 9 release that has excited a lot of developers is the broad range of enhancements to CFML's "other" language: CFSCRIPT. In the past, I've been very disparaging about CFSCRIPT and I've gone so far as to say in several public - and private - forums that I felt CFSCRIPT should be deprecated and no further effort spent on it. It was always a bit half-baked with weird restrictions and lots of important features missing. It was annoying to use, because you often had to switch back to CFML's tags to get things done. With increased use of CFCs, the restrictions in CFSCRIPT made it even more painful to use because you could not specify function arguments easily in CFSCRIPT - no types, no defaults - and you couldn't express a function's access or return type.When ColdFusion 8 appeared, with so many small improvements in CFSCRIPT, making it a bit more like JavaScript, those restrictions on function declarations were even more frustrating because other parts of CFSCRIPT had finally become almost pleasant to use. I was working with CF8 a lot and found myself using CFSCRIPT more and more because of the more JavaScript-like operators. Consequently, I found myself writing this sort of code a lot:
<cffunction name="doSomething" returntype="string" access="public" output="false">
<cfargument name="seed" type="string" default="" />
<cfscript>
... lots of script code ...
</cfscript>
</cffunction>
Ugh! If you're a ColdBox user, you'll be familiar with this because it's Luis's style for writing event handlers. I don't know about you but the more I worked with CFSCRIPT, the more this style of function declaration started to annoy me! So, I started to simply use CFSCRIPT for public functions (and sometimes private ones) and just accepting a return type of "any" (the default) and arguments with "any" type (again, the default). Sometimes I even went as far as using arrayLen(arguments) to figure out whether optional arguments were passed in. Sad, but true. Enter Railo which allowed argument types and defaults in CFSCRIPT (I don't know quite when Railo added support for that but it was quite a long time ago). I still couldn't specify function return types and access but I could at least specify optional arguments properly:
function doSomething( string seed = "" ) {
... lots of script code ...
}
Fast forward to 2009 and the CFML Advisory Committee were hard at work trying to produce a specification of CFML and CFSCRIPT. Our intent was to create a specification that was just ahead of current practice to set the stage for vendors to implement over the next year or so. Adobe brought a number of CFSCRIPT enhancements to the table as a proposal - based on what they were considering for CF9 - and we adopted many of them, sometimes with a few changes. After a lot of discussion, the committee agreed on exactly what would be considered "CFSCRIPT 2009" but it didn't always match Adobe's implementation for CF9 and they were too far along in their cycle to change CF9 to match the committee's specification. We're still discussing exactly what to do about that. As an example of CFML2009 that doesn't match CF9, here's the CFSCRIPT version of the <cflock>:
lock( scope = "session", type = "exclusive", timeout = "10" ) {
... code under lock ...
}
Here's Adobe's implementation:
lock scope="session" type="exclusive" timeout="10" {
... code under lock ...
}
Back to our function declarations, CFML2009 specifies that you can provide the function access and the return type so, going back to our example, we can say:
public string function doSomething( string seed = "" ) {
... lots of script code ...
}
And indeed, CF9 lets you write this. Railo, which has allowed the argument form for a long time, also supports this function declaration as of version 3.1.2.006, currently available via the development update provider (http://dev.getrailo.org if you need to enter it manually, depending on which release of Railo you're running). I you're working with ColdBox (as I currently am), you no longer have to write those nasty mixed CFML tag / CFSCRIPT event handlers! Yay! CFML2009 includes many enhancements to CFSCRIPT. CF9 implements most - but not all - of them, as well as adding some that the committee felt were not "core language". Railo has started implemented the CFML2009 enhancements that we believe will make the most difference to developers and plan to implement all of CFML2009 over time (although it's not clear what to do yet about CFML2009 enhancements that are implemented differently in CF9).

Tags: adobe · cfml-advisory · coldfusion · railo

4 responses so far ↓

  • 1 Daren // Dec 30, 2009 at 3:29 PM

    Sean,
    This is important news, as it indicates and outlines to some extent where the advisory committee and it's roles/work deviates from a standards body (of whatever actual guise). As a relatively recent cfml (as opposed to cf - a recent and important distinction I think) convert, I was under the impression that there were cfml standards being cooked -- in retrospect, 'advisory' committee kinda points to it being more likely cfml guidelines, and I'm sure some deeper reading would have revealed all, but never the less...

  • 2 Andrea // Dec 30, 2009 at 11:55 PM

    Sean,

    a question about lock. What do you think should Railo do now ? Implementing the lock in script as spec or following adobe cf9 style??
    Will Adobe patch this as well?
  • 3 Ben Nadel // Dec 31, 2009 at 5:53 AM

    I can't articular why, but for some reason, I just like tags better still. I know this must be completely emotional since I love writing in Javascript, which as you know, is script-based, not tag-based.

    I have to do some deep thinking about why I have this reservation. Maybe it's just time to break out of it.
  • 4 Sean Corfield // Dec 31, 2009 at 3:49 PM

    @Daren, standards bodies work this way: they produce a specification, not all vendors implement it exactly as-is, over time vendors and the specification converge. It's about consensus and democracy since the vendors are (usually) part of the standards body. I spent eight years on the ANSI C++ Standards Committee and, frankly, the CFML Advisory Committee isn't much different (except that it's much, much smaller - and we don't have to pay to participate!).

    @Andrea, I don't know. The committee are still discussing how to handle this sort of discrepancy.

Leave a Comment

Leave this field empty