tracker issue : CF-3733001

See this: http://cfmlblog.adamcameron.me/2014/03/coldfusion-11-calling-stored-procedure.html

Extract:

{quote}
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. 
{quote}

-- 
Adam

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

Attachments:

Comments: