ColdFusion: please help me discourage Adobe from releasing bad code

G'day:
As you may or may not know, CFML has a bunch of headless functions for encoding strings according to OWASP security recommendations, eg:

• encodeForHtml()
• encodeForHtmlAttribute()
• encodeForJavascript()
• encodeForCss()
• encodeForUrl()

These are - for all intents and purposes - wrappers for equivalent methods in OWASP's own Java library: org.owasp.esapi.reference.DefaultEncoder.

You should always use one of these functions when you are going to render untrusted content (user input, data from third-party APIs, databases, etc), eg don't do this:

Kia ora <cfoutput>#form.firstName# #form.firstName#</cfoutput>!

Do this:

Kia ora <cfoutput>#encodeForHtml("#form.firstName# #form.firstName#")#</cfoutput>!

Similarly if the value is going into JS, use encodeForJavaScript(), or a URL: encodeForUrl().

Also note these supercede older functions like htmlEditFormat() and urlEncodedFormat(), which do not do the job thoroughly, and should be actively removed from your codebase.

All good.

One thing that CFML has not had thusfar though are an OO approach to calling these functions, via a method rather than a headless function. It's really no great shakes that it doesn't, but it would be good if Adobe had done a thorough / complete job of implementing OO coverage of CFML's functionality. This is beginning to seem like their approach to CFScript coverage: it took about seven ColdFusion versions for them to complete the job, in the mean time CFML was marginalised as a language due to the play-school-looking code us CFMLers had to write our applications in.

There's a ticket in the bugbase to implement "member function" versions of these encoding functions: "Member functions for encoding". Cheers to Neil for raising that.

Unfortunately the Adobe ColdFusion Team have demonstrated their lack of OO nous in their implementation. Or lack of willingness to engage in language design. Or... really... preparedness to do good work.

The thought process seems to have been "well one passes a string to these functions, therefore they're clearly String member functions. We'll add them to the String class".

Well... no. A String class should have methods which describe the behaviour of a String object. Any String object so its methods should focus on ubiquious / generalised functionality relating to any string. Like finding & replacing sub-strings, comparing strings, etc. You know: the sort of general stuff that java.lang.String provides. Note how java.lang.String isn't a catch-all for every function which happens to take a string as an argument. That's not how OO works.

These encoding functions don't apply to most strings. They only apply to strings being used for a special purpose: a special sort of String, not the general String implementation. But these encoding functions are tricky ones. If there was a class "EncodableString" or something, then they'd be object methods of those. But what's the difference between a String and an EncodableString other than these functions? I don't think there's a decent case for that.

So what was OWASP's Java approach? Well one creates (or gets) an instance of an Encoder, and then passes the String to the encoder via the appropriate method. This makes sense in Java, and fits with the rest of the language. It looks a bit odd in CFML though:

<cfset myEncoder = new Encoder()>
Kia ora <cfoutput>#myEncoder.encodeForHtml("#form.firstName# #form.firstName#")#</cfoutput>!

Well it doesn't look odd, but it would be the first of a precedent of having built-in CFML classes which one creates instances of. Still: this sort of thing is where CFML should have gone with the release of CFMX 6.0: if they're in for a penny with OO, they should have been in for a pound.

So perhaps Adobe could have taken that approach.

However this still doesn't sit well with me. I rather more think that these methods are better suited to be static methods which one calls on the class. For CFML's needs there is no "object" needed here, as the Encoder doesn't have any stateful information. So I rather think the functions should be implemented as static methods:

Kia ora <cfoutput>#Encoder.encodeForHtml("#form.firstName# #form.firstName#")#</cfoutput>!

This follows on from the previous example: there's an Encoder class, and we just call the method on the class itself. I've suggested this in the ticket.

As is increasingly obvious, Adobe too often charges off and does work without public consultation, and then present some half-baked, half-working, design-absent solution. They have done this here too. There was never any community discussion, they simply did the work. And they plan to release it in ColdFusion 2016.

Adobe finally followed-up on the ticket (after a bit of should-be-unnecessary badgering), and seem to concede my suggested alternative makes sense. Cool. Except they also seem to be suggesting they're gonna release this current incorrect implementation in the mean time, and then - in a later ColdFusion release - look at fixing it. This is even more ill-conceived than their initial implementation! Once they release this stuff, it's out in the wild, and people will use it. Why would they release something that's been done wrong (you might think "wrong" is a heavy-handed description, but from a language design perspective, I don't see how it can be considered "right"?)? If they're short on time and/or resource, then they should simply park the work until they have time to do it properly. No-one's in a  rush for them to make CFML just that little bit more sh!t, are they? I can only surmise they're unprepared to concede "yeah that work didn't pass muster so should not be released", because that'd be an admission of error.

What I'd like people to do is to give this issue some thought, form yer own opinion, and express it on the ticket. From my perspective I'd like to vote for not releasing this solution until it's done right. I'd rather have no implementation than a bad one. We need to discourage Adobe form actually releasing sub-par work.

So have a vote and a comment if you feel like it (hey, vote and comment even if you don't agree with me; I'm not trying to ballot-stuff here. Well: maybe a bit ;-).

Righto.

--
Adam

ColdFusion: request for transparency and inclusion from Adobe

G'day:
A few days back I indicated some ire that a (IMO) wayward ER had been implemented for ColdFusion 2016: "ColdFusion: a piece of functionality should do one thing, and do it well". Poor old David Epler who raised it seems to feel a bit put upon cos it was something he raised three years ago, and with no further consultation Adobe have now implemented a solution. Without indication it was going to happen, or any communication with David about it, who now think it's perhaps not as good an idea as he originally might have thought.

This also got me thinking about another new feature in ColdFusion 2016: this whole ordered / sorted structs carry on (see "ColdFusion 2016: ordered/sorted structs"). Where's the ER for this one? I can't find one. So where did the impetus to do this work come from? Did Adobe just decide to do it off their own bat? If so why? Why the heck did they decide to do that work? Instead of any of a number of other features the community have actually asked for. Obviously there are probably some back channels via which people can ask for ERs - although there shouldn't be - but even if this came from some PHB or one of his minions at one of Adobe's special enterprise clients... why does this mean this is what gets implemented? All Adobe ought to say to the PHB et al in this case is "raise the ticket, engender some interest from the community, and let's see what people think".

Conversely the ColdFusion Team might have come up with this themselves. They really shouldn't do that, as - as far as I can tell - they are completely ignorant of CFML usage (I judge this based on everything they do and say about CFML, basically), so their decisions are not informed ones. But by accident they might have a decent idea... in which case they should... raise the ticket, engender some interest from the community, and let's see what people think. They definitely are not qualified by themselves to make decisions as to the direct on CFML.

I'm on the ColdFusion Pre-release Programme, and am under NDA to not divulge or discuss anything that gets mentioned on said programme (some people claim the PR has some sort of Fight-Club-esque rules about even mentioning it, or participation therein, but this is not true. They just want to make themselves come across as being "special". They do... but not in the way they think). So I won't. However I can speak freely on topics that have not had any discussion at all. And two of these are:

1. Dave's issue about adding encoding functionality to <cfoutput>. This has been apparently implemented without any mention whatsoever on the pre-release.
2. This sorted / ordered struct stuff. All I can say about that is that it exists in ColdFusion 2016. And there has been no discussion about its suitability or necessity for ColdFusion 2016 at all. Make of that what you will.

This is absolutely the wrong way of going about things. The ColdFusion Team might be fine Java developers (hey, they might be), but they seem woefully uninformed about CFML, and - as I have said already - don't use it, and don't really seem to have much of a handle on how we use it. They should not be making opaque decisions as to what goes into it. They have a CAB and a Pre-Realease Programme for this, and these decisions should be made there. And any work that is planned to be undertaken should be discussed out in the open, on the public bug tracker. An ER should be raised, public consultation should be allowed, and then the plan of how (or "if") the functionality will be undertaken should be proposed in public for further discussion. Not all opinions should necessarily be given equal weight (there's some bloody stupid opinions out there; some of them are my own), but they should be at least heard.

Here's an example of how it should be done, Here's the proposed schedule and feature-set for Java 9. There's no reason Adobe could not do that, at least at this high level. They could caveat the timeline with "all things being equal, and subject to change due to unforeseen circumstances", and they could caveat the feature list with "this is not a promise, but it's a guideline, and is also subject to change". We're all grown-ups and we understand things might prove tricky or not worth it, or something else might come along that's more important and needs to bump one of the "nice to have" features. And timeframes can change, etc. There's not even any commercial sensitivity to this, as ColdFusion isn't competing with anything. Well, other than "itself and its community" at times, I think.

PHP has similar timelines and have pretty organised RFC documentation these days for new features. I presume other language projects - well successful language projects - are similar.

Even LAS (those behind the Lucee CFML project, and the .lucee language) are heading in that direction, albeit in a more casual sort of way... but they're still finding their feet so it will probably round out as time passes.

I think the chief reason the ColdFusion Team don't take an inclusive communicative approach is that "inclusion" and "communication" are just devoid from their collective psyche, for whatever reason. They seem to treat their community with a degree of contempt that they seem to be "handing down manna from heaven" when they give us a ColdFusion release.

I think it's fine that Adobe marshal suggestions from their own team and from the "dark" part of their user base. But then they should open that up to the rest of the community so we can put our oar in. We have a great wealth of expertise in CFML usage to gauge how a feature might fit, and we've also got a great resource in the form of Sean Corfield who actually has designed languages in the past, so kinda knows how these things work (others in the CFML community might have experience here too, but I don't know about it). There's a few really old hands from the CAB and PR programme still around too, and they/we are kinda used to discussing how CFML should come together too.

Adobe have done a chunk of fine work in CFML, this is for sure. But they've also done some woeful shite, which I can't help but think never would have happened if they actually engaged their user base. As far as I can see there's no published plan for ColdFusion 2016, so I suspect there isn't really one. So it's not too late for them to kinda organise themselves a bit more, and include the rest of us in the language planning process. This would be bloody easy. For any public ER out there, simply tell us on Twitter or on Slack or on their own blog that they're looking at implementing it. And then encouraging people to have input. If there's not a public ER... create one, then do the same. Adobe have a vast pool of free planning resource. They should be using it.

Start using it.

--
Adam

ColdFusion 2016: arrays now passed by reference

G'day:
There's not much to say about this one. ColdFusion is finally playing catch-up, and standardising its approach to passing complex objects.

Traditionally, ColdFusion has passed "simple values" (strings, numerics, dates, etc) by value, and complex objects (structs, queries, XML) by reference (provided one understands "pass by reference" with these caveats: "Complex data-types in CF, and how they're not copied by reference"). The one exception was arrays. Arrays were passed by value. Why? I don't bloody know.

Right from the outset Railo decided that was bloody daft and has never done this, and this has been inherited by Lucee.

Now ColdFusion has caught up, even if I think the specific implementation is lacking.

There is a new setting for Application.cfc, this.passArrayByReference, which one can set to true (the default is false). If one sets that, then the behavour of passed arrays is changed.

Let's have a look at some code running on ColdFusion 11:

function arrayToUpperCase(array){
    for (var i=1; i <= array.len(); i++){
        array[i] = array[i].ucase();
    }
    return array;
}

rainbow    = ["Whero","Karaka","Kowhai","Kakariki","Kikorangi","Poropango","Papura"];

rainbowInUpperCase = arrayToUpperCase(rainbow);

writeDump(var=rainbow, label="rainbow", format="text");
writeDump(var=rainbowInUpperCase, label="rainbowInUpperCase", format="text");

This simple code has a function which takes an array, upper-cases each element and returns it. Afterwards, we dump both the original and returned arrays:

rainbow - array

1) Whero 
2) Karaka 
3) Kowhai 
4) Kakariki 
5) Kikorangi 
6) Poropango 
7) Papura 

rainbowInUpperCase - array

1) WHERO 
2) KARAKA 
3) KOWHAI 
4) KAKARIKI 
5) KIKORANGI 
6) POROPANGO 
7) PAPURA 

As you can see, when we modify the passed-in array, it does not impact the original array. Constrast this with the same operation with a struct:

function structToUpperCase(struct){
    for (var key in struct){
        struct[key] = struct[key].ucase();
    }
    return struct;
}

rainbow    = {red="Whero", orange="Karaka", yellow="Kowhai", green="Kakariki", blue="Kikorangi", indigo="Poropango", purple="Papura"};

rainbowInUpperCase = structToUpperCase(rainbow);

writeDump(var=rainbow, label="rainbow", format="text");
writeDump(var=rainbowInUpperCase, label="rainbowInUpperCase", format="text");

rainbow - struct

BLUE: KIKORANGI
GREEN: KAKARIKI
INDIGO: POROPANGO
ORANGE: KARAKA
PURPLE: PAPURA
RED: WHERO
YELLOW: KOWHAI

rainbowInUpperCase - struct

BLUE: KIKORANGI
GREEN: KAKARIKI
INDIGO: POROPANGO
ORANGE: KARAKA
PURPLE: PAPURA
RED: WHERO
YELLOW: KOWHAI

As you can see, because structs are passed by references, the argument in the function references the same struct as in the calling code, so changes to the argument are reflected in the original.

ColdFusion 2016: the long-awaited CLI

G'day:
Another thing Adobe showed at CFCamp - and I have had clearance to write about - is that ColdFusion finally has a CLI. About bloody time. It's about... well... 15yrs overdue. Well to be fair to Allaire, ColdFusion 5 could run files from the command-line, but this functionality was omitted from ColdFusion between then and now.

Having a command-line is dead useful, because it means one doesn't need to have a web server running to run CFML code. Indeed one doesn't even have to have a ColdFusion server running to run CFML code! This is handy for scripting, or - for me - testing quick code snippets.

Here it is in action:

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

D:\src\cfml\scopes\server>CF server_dump.cfm
struct

coldfusion:
        [struct]
        InstallKit: Native Windows
        appserver: JRun4
        expiration: {ts '2015-11-15 08:18:28'}
        productlevel: Evaluation
        productname: ColdFusion Server
        productversion: 11,0,01,296113
        rootdir: C:\apps\adobe\ColdFusion\2016\express\cfusion
        supportedlocales: [snip]
        updatelevel: 01
os:
        [struct]
        additionalinformation: [empty string]
        arch: amd64
        buildnumber: [empty string]
        name: Windows 7
        version: 6.1

D:\src\cfml\scopes\server>

Note one good thing here right off the bat: <cfdump> detects it's being run via the CLI and doesn't piss about with all it's mark-up, it just does a text-only dump.

Note also one other interesting thing: JRun. Huh? I thought we were done with that? Anyway, let's not worry about that too much. Although I will raise it with Adobe.

Command line arguments

The ColdFusion CLI has two types of command line arguments. Firstly there are the familiar space-separated ones:

D:\src\CF2016\cli\args>cf ordered.cfm tahi rua toru wha
All arguments - array

1) tahi
2) rua
3) toru
4) wha


First argument: tahi
D:\src\CF2016\cli\args>

And also named ones:

D:\src\CF2016\cli\args>cf named.cfm one=tahi two=rua three=toru four=wha
All arguments - struct

four: wha
one: tahi
three: toru
two: rua

'two' argument: rua
D:\src\CF2016\cli\args>

The code for each of these examples demonstrates the new CLI functionality regaridng input and output:

<cfscript>
// ordered.cfm
writeDump(var=CLI.getArgs(), label="All arguments");
CLI.writeLn("");
CLI.writeLn("First argument: " & CLI.getArg(1));
</cfscript>

<cfscript>
// named.cfm
writeDump(var=CLI.getNamedArgs(), label="All arguments");
CLI.writeLn("");
CLI.writeLn("'two' argument: " & CLI.getNamedArg("two"));
</cfscript>

So ColdFusion has a new CLI object exposed when running on the CLI. Note that this is not a scope, it is an object. It has methods (as demonstrated above):

• getArgs() - returns all space-separated arguments
• getArg(n) - returns the nth argument
• getNamedArgs() - returns all the name/value pairs (separated by =)
• getNamedArg(name) - returns the value of the named argument
• writeLn() - writes a string to standard out, followed by a new line
• write() - as above, but without the new line

There's a few other methods I've not looked at yet, as demonstrated in this dump:

D:\src\CF2016\cli\cliObjectTests>cf dumpCli.cfm
object of coldfusion.runtime.CLIBridge

Class Name: coldfusion.runtime.CLIBridge
Methods:
        addArg(java.lang.String) returns void
        clone() returns java.lang.Object
        getArg(int) returns java.lang.Object
        getArgs() returns coldfusion.runtime.Array
        getNamedArg(java.lang.String) returns java.lang.Object
        getNamedArgs() returns coldfusion.runtime.Struct
        putNamedArg(java.lang.String, java.lang.Object) returns void
        read() returns java.lang.Object
        write(java.lang.Object) returns void
        writeError(java.lang.String) returns void
        writeln(java.lang.Object) returns void
D:\src\CF2016\cli\cliObjectTests>

ColdFusion 2016: ordered/sorted structs

G'day:
One interesting new feature of ColdFusion 2016 is the ability to affect key ordering in structs, in two different ways. (This, btw, is something that has been exposed in the public domain, and I have made sure I am not breaking any NDA in writing this up).

Traditional structs do not have a sense of ordering in their keys. This is by design: a struct is an unordered collection. When iterating over a struct by key, obviously the keys will be iterated in a specific order, but there is no guarantee what that ordering will be as the specification does not... well... specify one, so it's down to the implementation. ColdFusion might expose the keys in alphabetical order; Lucee might do it in order of creation; some other CFML implementation might do it some other way. If one wants to control the order of how keys are accessed, one needs to extract the keys and sort them, then iterate over that. EG:

categoryTallies = {
    "gold" = 2,
    "premium" = 5309,
    "1st" = 37,
    "second" = 68113,
    "general" = 491
}; 

categoryTallies.each(function(category,tally){
    writeOutput("Category: #category#; tally: #tally#<br>");
});

writeOutput("<hr>");

sorted = categoryTallies.sort(function(category1, category2){
    return sgn(category1 - category2); 
}).each(function(category,tally){
    writeOutput("Category: #category#; tally: #categoryTallies[category]#<br>");
});

Looking at the first part of this output in ColdFusion gives this:

Category: gold; tally: 2
Category: 1st; tally: 37
Category: premium; tally: 5309
Category: second; tally: 68113
Category: general; tally: 491


And pleasingly Lucee returns a different order, demonstrating my point:

Category: second; tally: 68113
Category: premium; tally: 5309
Category: general; tally: 491
Category: gold; tally: 2
Category: 1st; tally: 37


So ColdFusion's struct implementation returns the keys in the order they were added; Lucee... dunno. I dunno what order that it. But that's fine, I don't need to know because it's not relevant.

Looking further into the code, I get myself an array of keys sorted by tally, and then use those as the basis for an iteration outputing the same info, but now sorted:

Category: gold; tally: 2
Category: 1st; tally: 37
Category: general; tally: 491
Category: premium; tally: 5309
Category: second; tally: 68113


BTW, I was initially confused as to why that code only worked on ColdFusion, and not Lucee. I had not realised that structSort() (and therefore Struct.sort()) doesn't work the way its array equivalent does, and doesn't take a callback for the comparator. That's a bit rubbish that the implementation wasn't uniform across all the collection iteration methods. However it seems that in ColdFusion 2016, it's now been implemented. I guess this is part of this new struct implementation.

ColdFusion 2016: it goes to show you should raise feature requests

G'day:
I'm still under NDA with the ColdFusion 2016 Prerelease Programme, so I need to be circumspect about what I say about CF2016, but once someone from Adobe has talked about something in public, I reckon I am allowed to at least refer back to that, and draw on public information to write some stuff.

Adobe showcased some ColdFusion 2016 features at CFCamp yesterday. It sounds like it was a good presentation, and was more dev-centric than has been the case in the past. Nice one, Rakshith.

A while back I raised this ticket on the bugbase: "?.: safe navigation operator". I gleaned this idea from trawling around other languages to see what they have on offer which might complement CFML. I wrote the results of this in my article "Thinking about operators in CFML".

Well I'm quite pleased that the safe-navigation operator has made its way into ColdFusion 2016.

Yay! <- that's me being pleased. It doesn't happen often, so remember what it looks like for future ref.

So what's this "safe navigation" thing?

It's an operator which takes two operands, and follows the following rules:

1. if the first operand is null, it returns null;
2. if the first operand is not null, it applies the second operand to it using the . operator.

Wah?

OK, say we have this:

// safeNavigationExample.cfm
function getMaoriNumberById(id){
    var numbers = ["tahi", "rua", "toru", "wha"];
    if (id <= numbers.len()){
        return numbers[id];
    }
}

fiveInMaoriInUpperCase = getMaoriNumberById(5).ucase();

We would get this:

Value must be initialized before use.

Its possible that a method called on a Java object created by CreateObject returned null.

The error occurred in safeNavigationExample.cfm: line 10

8 : } 9 : 10 : fiveInMaoriInUpperCase = getMaoriNumberById(5).ucase(); 11 : </cfscript>

To counter this, we'd need to write this lot:

fiveInMaori = getMaoriNumberById(5);
if (!isNull(fiveInMaori)){
fiveInMaoriInUpperCase = fiveInMaori.ucase();
}else{
    fiveInMaoriInUpperCase = javaCast("null", "");
}

That's quite a mouthful. And this is only with one chained operation. What if it was this:

result = new SomeObject().method1().method2().method3().method4();

And at any point in that, the result of one of the methods might be null? We'd need this:

someObject = SomeObject();
resultOfMethod1 = someObject.method1();
if (!isNull(resultOfMethod1)){
    resultOfMethod2 = resultOfMethod1.method2();
    if (!isNull(resultOfMethod2)){
        resultOfMethod3 = resultOfMethod2.method3();
        if (!isNull(resultOfMethod3)){
            result = resultOfMethod3.method4();
        }
    }
}
if (!structKeyExists(variables, "result")){
    result = javaCast("null", "");
}

Yikes.

So this is where the safe navigation operator comes in:

result = new SomeObject().method1()?.method2()?.method3()?.method4();

Much better.

ColdFusion: language-centric stuff flagged for fixing (for ColdFusion 2016?)

G'day:
Adobe have claimed that ColdFusion 2016 will be a developer-centric exercise, which makes a pleasing change from the PHB-oriented CF11 (well: that can be the only basis for <cfclient> to ever have been considered... some muppet from Adobe polling PBHs for what they want in ColdFusion).

Obviously Adobe are never directly forthcoming as to what's going to go into the next version of ColdFusion, but one can make some inferences from status changes in the bug tracker. There are currently 241 open enhancement requests specifically flagged as "language", and also flagged as "to fix". Obviously there's no promise that 100% of these will go into ColdFusion 2016, but generally stuff they can't be arsed dealing with gets closed with some variation of "nuh-uh" as the closure reason. So perhaps we can think of this list as the target for 2016. Even if they only did half of it, it'll be pretty excellent:

ColdFusion: Adobe chip away at their own crappy generic CFScript syntax

G'day:
Here's some good news from the Adobe ColdFusion Team: it seems their not opposed to reversing some of their bad language design choices: they're thinking of deprecating cfloop() in favour of extending for().

Background: Adobe had been promising full CFScript functionality parity with tag-based functionality since ColdFusion 9 was in development. CFScript got enhancements in 9, and again in 10, but did not get the 1005 parity until 11. Unfortunately Adobe did a half-arsed job of this and simply implemented the rest of the missing functionality via basically calling tags in script. FFS.

So where we might have had to do this in the past:

<cfloop query="someRecordset" group="someColumn">
    <!--- outer loop stuff --->
    <cfloop>
        <!--- inner loop --->
    </cfloop>
</cfloop>

Adobe decided this would be a suitable CFScript implementation of equivalent functionality:

cfloop(query="someRecordset", group="someColumn"){
    // outer loop stuff
    cfloop(){
        // inner loop stuff
    }
}

Egad. This shows a chronic lack of language design skills, and seemingly a complete unawareness of how any other language might go about things. Why the hell are they still prefixing everything with CF??? How does syntax like that fit in with the aesthetic and precedent of all the existing CFScript implementation? It's just an exercise in laziness and dull-headedness.

Anyway, I've gone on about this enough in the past.

Right, so now we have this ticket (which I only now notice I actually raised!): "Error messaging with cfloop() is rather messed up", which has footnotes:

We will not take this up and might deprecate cfloop() in cfscript altogether in future.

[...]

There is an enhancement to support grouped query looping in for() syntax in cfscript. - #3754577. We will not deprecate cfloop before taking that enahancement.

3754577 observes that cfloop() doesn't actually have functional parity with its tag counterpart.

But the important thing here is this bit: "We [...] might deprecate cfloop() in cfscript altogether in future". I'm mad for deprecating cruft from the language, but the more important thing is that it seems if Adobe are actually given better alternatives for their generic tags-in-script functionality, they seem open to deprecating the generic stuff, in place of implementing a better, in-keeping-with-design-philosophy alternatives. This means we can tidy up CFScript a bit, if we put our minds to it.

ColdFusion 2016 is being developed as we speak, and I can speculate that we're possibly in the window for getting stuff done with the language (remember Rakshith promised ColdFusion 2016 would be a dev-centric, language-centric release), so now's the time to get the ideas in front of Adobe.

I've already floated a coupla ideas for improving the current CFScript implementation of some tags:

• "How about this for savecontent?" (3643125);
• "ColdFusion 11: calling a stored procedure from script. And can we please stop wearing out our "c" and "f" keys?" (3733001)

Those are just a coupla random ideas. What I want to know - and I want to get this info from you lot - is what other areas have Adobe let us all down in falling back to this generic "tag in script" syntax instead of doing a thoughtful implementation.

How would you implement <cfldap>? <cftransaction>? What about <cfmail>? Share your ideas (and get them into the bug tracker).

Righto.

--
Adam

ColdFusion: Adobe updates their roadmap for ColdFusion. Forgets to give the language directions

G'day:
Rakshith has today released the latest iteration of the ColdFusion road map: "New Product Roadmap for ColdFusion".

Here's a scrape of the PDF (linked to in that article):

So that's a bit bleak. I'm not sure I needed something to manage web services. But then again I can't think what that might entail, so I'll keep an open mind. It does sound like something aimed at IT managers rather than something which'll end up being well-realised for ColdFusion administrators.

I know PDF stuff is important to a lot of people, but not me. Don't care. This could be quite good for people who do care though, I s'pose.

I don't see how "CLI" comes under language enhancements. But still: this'll be something worth having a look at, I reckon. I'm looking forward to that.

Ordered / sorted structs? Yeah... I guess. I know people seem to want to control the ordering of keys in a struct, but I have always thought that this is a misuse of a struct. Also this seems a bit stuck in a procedural coding mindset. If we want to be able to iterate over a some sort of keyed data structure, wouldn't providing something like IEnumerable so that an object's keys can be iterated over. Still: it's a bit of an edge case to want to do that too. But what an approach like this would give the CFML developer is more control over what they can do with the functionality, rather than being limited to Adobe's implementation.

Storing sessions externally? Cool. But not a language feature. This is an admin feature.

So it's pretty bloody light on areas which I am interested in: the CFML language. Still: it's early days in the pre-release cycle, so maybe more stuff will come in. Also this doc seems like a marketing doc not a technical doc, so perhaps distinct language features are not "marquee" enough for this sort of doc?

It'd be great if for once Rakshith could produce something aimed at ColdFusion's developer community.

I don't care about CF Builder or ColdFusion on Cloud, so someone else can editorialise about those.

I'm actually pretty disappointed in this. I'm certain (-ish) that Rakshith claimed ColdFusion 2016 was gonna be developer-centric, rather than PHB-centric, and it seems they've backed away from that. Pity. There are so many excellent language features CFML could add to make it  a more appealing prospect for the rest of the IT industry (obviously it'd also need a marketing push in that direction too). Oh well. I guess it's not surprising really.

There's also mention of ColdFusion 13, but it's pretty nebulous:

Bleah. Don't care at all about that lot. Good to see Language improvements being a "focus". Even if otherwise completely glossed over.

As for the release/support cycle:

Not that Adobe have a habit of sticking to plan, but this suggests that given ColdFusion 10 goes into "extended support" (the yellow bit) in mid 2017 (EOL in mid 2019), then we won't be expecting to see ColdFusion 2016 until mid 2017?! That doesn't seem right. I would more expect it to show up early Q2 next year. I'd guess ColdFusion 2016+1 would be out early 2018. Hopefully I will not care by then ;-)

It's public knowledge I'm on the ColdFusion 2016 pre-release programme, but I can't bloody say anything about it yet. The next milestone I'm looking forward to is being able to write up some of the stuff I've been looking at.

Anyway... I've got work to get back to. And a sandwich to eat.

--
Adam

ColdFusion: complete the implementation of associative array notation

G'day:
This'll be a quick one (not least of all because I only have about 20min to write it).

CFML has the ability to reference struct (and by extension object) keys either statically via dot notation, or dynamically via associative array notation, eg:

someObj = {
    someKey = someValue
}; 

value = someObj.someKey;

whichKey = "someKey";
value = someObj[whichKey];

This is cool, but it doesn't work when referencing functions, eg this does not work:

someObj = {
    someFunction = function(){
        // do some stuff
    }
}; 

result = someObj.someFunction(); // all good

whichFunction = "someFunction";
result = someObj[whichFunction](); // nuh-uh

This errors with:

Invalid CFML construct found on line 2 at column 13.

ColdFusion was looking at the following text:{

If associative array notation had been thoroughly implemented, this ought to work. However I suspect this latter situation did not occur to Adobe when doing the implementation.

Are we getting closer to having a CLI & REPL on ColdFusion?

G'day:
I have to admit this is pretty much a click-baiting exercise, whilst also trying to drum up some community interest and support in a bugbase ticket.

A while back I raised 4013832, which says:

CLI/REPL - probably via CommandBox

I'm sure this has been raised before, but I cannot find the ticket.

ColdFusion needs a CLI/REPL for it to be taken seriously in these times. It's just a fundamental.

CommandBox is really good in this regard, so perhaps bundling it with ColdFusion under licence might be a solution.

This is by no means an original idea, and plenty of people have lamented the absence of this fundamental platform feature in ColdFusion for years. Indeed I've mentioned it a number of times previously on this very blog:

• More ColdFusion 5... CFML.EXE
• CLI
• CFML is dying. Let's drop it off at Dignitas
• Ortus does what Adobe / Railo ought to have done...
• ColdFusion 2016
• What I'd like to see in ColdFusion 2016 (redux, as is happens)

And I'd even raised a previous bE/R for it back in 2013: 3646258. The indication then was that it was going to be picked up for ColdFusion 11, btw.

I'm nothing if not predictably repetitive.

CFML suggestion: make queries implement an array interface

G'day:
This was not what I was gonna write about today, but it popped into my head as I was walking up upstairs to the office, so in a carpe diem moment, I'll do this one instead.

Queries are one of the most fundamental data structures in CFML; in fact perhaps the most fundamental data structure for CFML's original USP which was to pull data from a DB and get it into a web page. But if one thinks about it... it's one of the least functional. Beyond looping over 'em, there are a total of eight functions relating to them (from Query Functions). Four of those are all about building queries (queryNew(), queryAddColumn(), queryAddRow(), querySetCell()); two of them are for converting to another data type (valueList() and quotedValueList()); one to check of something is a query in the first place (isQuery()); and then there's one function for actually doing something with said query object: queryConvertForGrid(). And one basically should not be using that as it's only useful for using with <cfgrid>, and one should not be using that. Basically if one wants to manipulate a query object, on needs to fall back to QoQ, which is a bit of a rubbish way of going about things.

ColdFusion 2016: Before I get all NDA-ed up

G'day:
This was a pleasing email to get:

Invitation to join the ColdFusion Raijin/Blizzard Prerelease Program!

Hello,
Because of your knowledge and interest in ColdFusion & ColdFusion Builder, you have been selected to participate in the Prerelease program of the next versions of ColdFusion codenamed 'Raijin' and ColdFusion Builder codenamed ‘Blizzard’. This program provides early access to the upcoming release.

Useless ColdFusion community members

This:
"I liked all of them, so I decided not to comment."

No.

If you're any sort of CFML developer, you will go and raise feature requests, point out bugs, and generally get in with the swing of furthering your language.

CFML: apathy at work in the ColdFusion community

G'day:
The other day I knocked together an article "What I'd like to see in ColdFusion 2016 (redux, as is happens)", which lists a bunch of stuff I'd like to see in ColdFusion 2016. It was a bit of a speculative list, and just a way of getting people thinking about what they'd like to see in CFML, and perhaps go and actually participate in the future possibilities of their language.

I've cross-referenced each of the ideas I mention to a ticket (a new one, or an existing one if I could find one). Hoping people might go and have a vote or put their oar in or encourage more people to come up with their own ideas.

What I got instead of was 120 comments mostly revolving around how daft Acker Apple happens to be. I'm all for having this pointed out - especially as he seemed to revel in it - but there's more to ColdFusion 2016's possibilities than that, is there not?

What I'd like to see in ColdFusion 2016 (redux, as is happens)

G'day:
After the news of ColdFuson 2016's pre release getting underway soon presented itself ("ColdFusion 2016 is coming..."), I decided I'd work out what I'd like to see in CF2016, and knock together an article here.

In researching this this morning, I realise I've already done this! Here's the original: "ColdFusion 2016". Not to be deterred or put off by repeating myself, I'm gonna go ahead and do a new article as well, and have a look at what I thought before and whether it's changed.

ColdFusion 2016 is coming...

G'day:
Just repeating news I heard from elsewhere. The ColdFusion 2016 pre-release is going to be opened up shortly. This is interesting stuff! There's a blog article soliciting participation: "Pre-release for the next version of ColdFusion". Currently whilst they mention a link, it's not actually there. I have pointed this out, so am sure it'll be fixed shortly.

Update:

Here's a direct link, as posted on Twitter by Rakshith: https://www.surveymonkey.com/r/LPS7YYP

We will soon have the pre-release for next version of #ColdFusion. Take this survey to be a part of it https://t.co/JUSFEzt3SB

— Rakshith Naresh (@rakshithn) June 17, 2015

Do sign-up. Adobe can use all the community voices they can muster to help them with the direction of CFML.

I'll be putting my name down, but I didn't last long in the pre-release last time due to disillusionment with their focus, which was all about <cfclient> in the earlier stages. This was a mistake on my part as they did then go on to do some interesting stuff later on.

I do hope Adobe don't have another <cfclient>-esque "feature" up their sleeves this time. Time will tell.

I also hope they are more open and less "NDA hush hush" about it this time. The industry has moved on from that sort of approach. They'd be much better served by getting the thing out in the open and getting as many bums on seats looking at it as possible.

Anyway... get over there and put yer name down.

Righto.

--
Adam

That's it: no more ColdFusion_12 or CFClient

G'day:
You might or might not have twigged that I was running the @CFClient and @coldfusion_12 Twitter accounts. They were parody / pisstake / satirical account gently prodding the general business approach of the Adobe ColdFusion Team.

Well, anyway, someone filed an official complaint about them, so Twitter has closed them both down.

ColdFusion 2016: instead of <cfbell> and <cfwhistle>...

G'day:
I was asked to comment on Microsoft's announcement that the entire .Net Framework is going open source (".NET Core is Open Source"), and what we - the CFML community - should think about that in the context of ColdFusion.

ColdFusion 2016 in 2016? ColdFusion 2016+1 in 2018?

G'day:
Brad posted an interesting (if very blurry) image from CFSummit earlier:

Tridib's plan for the future of ColdFusion http://t.co/gJhvKFaOw9 http://t.co/UCrKxfRlrn #CFSummit2014
— Brad Wood (@bdw429s) October 16, 2014