tracker issue : CF-3733001

select a category, or use search below
(searches all categories and all time range)

Bin the generic CFScript approach and start again

| View in Tracker

Status/Resolution/Reason: Closed/Won't Fix/

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 03/30/2014

Components: Language

Versions: 11.0

Failure Type: Usability Issue

Found In Build/Fixed In Build: PublicBeta /

Priority/Frequency: Major / All users will encounter

Locale/System: English / Platforms All

Vote Count: 13

See this:


Here's the new generic CFScript approach to a stored proc call:

cfstoredproc(procedure="uspGetColours", datasource="scratch_mssql",result="script.result", fetchclientinfo=true, returncode=true) {
    cfprocparam(value=URL.low, cfsqltype="CF_SQL_INTEGER");
    cfprocparam(value=URL.high, cfsqltype="CF_SQL_INTEGER");
    cfprocparam(type="out", variable="script.inclusiveCount", cfsqltype="CF_SQL_INTEGER");
    cfprocparam(type="out", variable="script.exclusiveCount", cfsqltype="CF_SQL_INTEGER");

    cfprocresult(resultset=1, name="script.inclusive");
    cfprocresult(resultset=2, name="script.exclusive");

That is just repugnant. What awful bloody code. All Adobe have done is to go "right... the CFScript version of a tag is just the tag without the angle brackets. And if it's a nestable tag set (like with proc params and proc results), we'll put some curly braces around it. Oh, and make it kinda like a function, with parentheses and commas instead of space-delimited attributes".

What's worse (yes, it gets worse), is that this is contrary to the way Railo already set out to do the same thing. Their approach also lopped off the "cf" bit too. And doesn't have the parentheses or commas (I think).

But here's the thing. Simply chopping the angle brackets (and/or the "cf" tag prefix) does not result in a well-thought-out implementation of script functionality. The two approaches to coding syntax are quite different. So simply doing what amounts to be a global search and replace isn't an adequate solution.

It's just a lazy cop out.

And, FFS Adobe: do we need to start everything with "CF"? It makes sense in tags, but it makes no sense whatsoever in the context of script code.

What Adobe should have done is to sit down with a given tag and go "right... what functionality does this tag fulfil? Right, now that we know that, let's forget about tag syntax, and come up with a way to implement that functionality in script". It's not an exercise in syntax translation, it's an exercise in functionality provision.

So what does a stored proc call do? It takes some inputs:
the procedure name
some parameters
some options (datasource, etc)
And what does it do?
returns recordset(s)
returns metadata
returns values in some of the parameters
Takes inputs and returns results? Sounds like a function to me.

options = {
    datasource        = "scratch_mssql",
    fetchclientinfo    = true,
    returncode        = true
params = [
    {value=URL.low, type="INTEGER"},
    {value=URL.high, type="INTEGER"},
    {type="out", variable="inclusiveCount", type="INTEGER"},
    {type="out", variable="exclusiveCount", type="INTEGER"}

result = executeProcedure("uspGetColours", params, options);

Where result would yield this:

[see the blog article for the dump]

That is a hell of a lot clearer than what Adobe have offered, and gets rid of an awful lot of boilerplate code that makes sense in tags, but is unnecessary in script code. It just gets to the point and does the work.

Adobe ought to shit-can all this generic CFScript stuff they've done, and revisit each piece of functionality that is currently implemented as tag-only, and then implement the functionality in a way sensible to be implemented in script. Which will generally be a function. They mustn't tackle this as a syntax issue, they need to tackle it as a functionality issue.

And, seriously, the current approach in CF11 beta needs to be binned and started again. Bad luck. You should have focused on doing the job properly, not quickly. 


----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3733001

External Customer Info:
External Company:  
External Customer Name: Adam Cameron.
External Customer Email:  
External Test Config: My Hardware and Environment details:



Clean and simple should be the mantra...+1
Vote by External U.
12932 | March 30, 2014 12:16:18 PM GMT
+1. The current approach to make tags in script is a poor decision. We don't need tags in script; we need functionality in script - in a well-thought-out-and-consistent syntax. Tag syntax converted to script is just another backwards compatibility blunder we'll be dealing with for years to come.
Vote by External U.
12933 | March 31, 2014 01:00:21 PM GMT
Agree that tags cannot be blindly converted to script functions this way. Script equivalents should be more carefully designed.
Vote by External U.
12934 | April 05, 2014 03:20:48 PM GMT
Adobe, please reconsider the decision to close this as "Never Fix", or at lease provide some comments to explain this decision. When community members offer constructive criticism of how new functionality can be improved to everyone's benefit, it should be considered and given at least a respectful response. Granted, some of Adam's phraseology above is a bit "colorful", but the spirit behind the bug report is a sincere desire for ColdFusion to be the best it can be. Yes, many in the community have been asking for full script support of all ColdFusion tags for a long time. It is great that Adobe have responded by getting all the tags into script; however, the way it was implemented seems a bit slapdash and might in fact be viewed as a detriment to the ColdFusion language.
Comment by External U.
12926 | April 05, 2014 03:30:01 PM GMT
Yeah, thanks Carl: Sometimes I get a bit wound up by things I see in CFML, and I put my case fwd in less than charitable terms. Thanks for wording it more neutrally. The problem here is that once this stuff makes it out of beta: we're stuck with it. And it really isn't the way the problem should be addressed (fwiw, I have had the same discussion with Railo on the same topic). The chief issue is that the object of the exercise here was never "make all the tags possible in CFScript", it was make sure all the *functionality* that the tags offer is also available in script. This doesn't mean making an approximation of the syntax: this was never necessary. Anyway, I hope your cooler head (and maybe even my cooler head today) might help Adobe have another look at this. At the very least it'd be good to open a discussion about it, rather than simply going "nuh-uh". Cheers. -- Adam
Comment by External U.
12927 | April 05, 2014 03:44:07 PM GMT
Adobe, hello? -- Adam
Comment by External U.
12928 | July 19, 2014 04:59:22 AM GMT
this. this. a thousand times this. please reconsider your decision to refuse to "do it right."
Vote by External U.
12935 | August 29, 2014 07:48:02 AM GMT
Please add some thought to the process of converting tag based features into functions. And be consistent.
Vote by External U.
12936 | August 29, 2014 08:52:54 AM GMT
To be honest, I believed the generic CFScript approach was the result of laziness. Please re-consider to do it the right way. Thank you.
Vote by External U.
12937 | August 29, 2014 09:15:55 AM GMT
Neverfix? So Adobe dont care about making a language that does not look half-assed? Come on guys you can do better than this.
Vote by External U.
12938 | August 29, 2014 09:43:11 AM GMT
so much for measure twice, cut once... come on: do it correctly. Take some pride in your product.
Vote by External U.
12939 | August 31, 2014 10:30:01 AM GMT
I agree with Adam's viewpoint on this subject. Please reconsider addressing this issue.
Vote by External U.
12940 | September 10, 2014 03:18:53 PM GMT
"Repugnant" is the perfect word for how bad this is. And it's particularly galling that Adobe would close this with a "NeverFix" and not even have enough respect for the developers to explain WHY.
Comment by External U.
12929 | July 07, 2015 03:11:11 PM GMT
++++++++++++++++++++++1 This is a HORRIBLE script version for something many of us have to use all the time.
Vote by External U.
12941 | July 07, 2015 03:11:49 PM GMT
Adobe, can you pls communicate with your clients like professionals, here?
Comment by External U.
12930 | July 07, 2015 03:14:40 PM GMT
For $8500 one would expect the product to support a professional, well thought out scripting syntax. This is a joke. Drop all the cf... function names in cfscript (which is totally pointless) and re-think the syntax. Please develop cfscript v2.0 with beautiful, logical, and flexible functions and syntax. Lastly Adobe, please explain why you never want to fix these problems. It sounds like you don't understand the issues.
Vote by External U.
12942 | July 08, 2015 03:52:00 AM GMT
Not all tags are created equal, so it's a bit silly to think that hacking off some brackets is even mildly acceptable. What's this nonsense having "cf" still attached? Have you seen what you did to cfsilent with this approach? Have you? Monsterous. Hideous! Part of writing in a language is being able to write clear, readable code. This: cfsilent() { //code } is a contradiction on you as language developers. What are those parentheses doing there? That syntax isn't fooling anyone. It's not a function. It reads wrong. Reconsider the neverfix and take a look at how you can craft your scripting language better. Even if it's one tag at a time.
Vote by External U.
12943 | August 15, 2015 09:43:56 AM GMT
Adam and others, first of all, I apologize for the lack of communication from our side on this bug. I agree with you the whole script approach needs to rethought of where every single functionality rather than a tag should be available on the script side of things. For instance, the way QueryExecute funciton was introduced in CF11 for executing database queries from within script. I will also be honest with you that though this on our minds and the current approach is more a quick (not always neat) way of getting use tag functionality within script, this revamp will not happen in Raijin's timeframe. This will be considered for a future release post Raijin.
Comment by Rakshith N.
12931 | December 10, 2015 03:04:42 AM GMT