Where are the ColdFusion 10 & 11 updates, Adobe?

G'day:
Here's a quick thought that's been bugging me for a month or two now. What's happened with the ColdFusion updater?

Checking Wikipedia, the update history for ColdFusion 10 is as follows:

2012-May-15: Adobe ColdFusion 10 (build 10,0,0,282462)
2012-August-31: Adobe ColdFusion 10 Update 1 (build 10,0,0,282462)
2012-September-11: Adobe ColdFusion 10 Update 2 (build 10,0,0,283111)
2012-October-16: Adobe ColdFusion 10 Update 3 (build 10,0,3,283145)
2012-November-02: Adobe ColdFusion 10 Update 4 (build 10,0,4,283281)
2012-November-19: Adobe ColdFusion 10 Update 5 (build 10,0,5,283319)
2012-December-11: Adobe ColdFusion 10 Update 6 (build 10,0,6,283435)
2013-January-15: Adobe ColdFusion 10 Update 7 (build 10,0,7,283649)
2013-February-27: Adobe ColdFusion 10 Update 8 (build 10,0,8,284032)
2013-Apr-10: Adobe ColdFusion 10 Update 9 (build 10,0,9,284568)
2013-May-14: Adobe ColdFusion 10 Update 10 (build 10,0,10,284825)
2013-July-09: Adobe ColdFusion 10 Update 11 (build 10,0,11,285437)
2013-November-12: Adobe ColdFusion 10 Update 12 (build 10,0,12,286680)
2014-January-10: Adobe ColdFusion 10 Update 13 (build 10,0,13,287689)

So there's a steady stream of updates and hotfixes there, up until Jan this year. Then nothing for over six months now. And it's not as if there's no bugs to fix in ColdFusion 10. I posted some analysis of "significant" ColdFusion 10 bugs a while back: "What should Adobe be retro-fitting into ColdFusion 10? Here's a potential list", and there's a reasonable case that Adobe should be dripping out fixes from that list (or similar) pretty much constantly. But nothing.

Some will leap to Adobe's defence saying "but they were busy working on ColdFusion 11", sorry but we oughtn't give a shit. Life goes on, and we've already paid for ColdFusion 10, so they should be making good on the bill of goods they're already sold us before prioritising the next thing they expect us to buy.

I also think by now there ought to have been a few hotfixes for ColdFusion 11... it's not short in the bug / half-finished department either.

So what's going on, Adobe?

--
Adam

Both ColdFusion and Railo make an incomplete job of validating email addresses

G'day:
A question came up on StackOverflow just now "new to coldfusion. is there any function that defines Email is typed correctly" (how hard, btw, is it to give a coherent title to one's question? [furrow]).

My initial reaction was along the lines of "RTFM, and if you had, you'd see isValid() validates email addresses". However I also know that isValid() is very poorly implemented (see a google of "site:blog.adamcameron.me isvalid" by way of my findings/rantings on the matter).

So I decided to check how reliable it actually is.

The rules for what constitutes a valid email address a quite simply, and a laid out very clearly in various RFCs. Or if one can't be bothered doing that (although the engineers & Adobe and Railo should be bothered), then they're fairly comprehensively defined even on Wikipedia: "Email_address (Syntax)". I found that page by googling for it.

Anyway, I won't bore you by replicating the rules here, but I wrote some TestBox tests to test all the rules, and how isValid() supports them. The answer to this on both ColdFusion (11) and Railo (4.2) is "only to a moderate level". This is kinda what I expect of the Adobe ColdFusion Team (this is the level of quality they seem to aim for, generally, it seems), but am pretty let down by the Railo guys here.

I won't reproduce all the code here as it's long and boring, but it's on GitHub: "TestIsValidEmail.cfc".

Anyhow, the bottom lines are as follows:

ColdFusion:

Railo:

Railo did slightly better, but ran substantially slower (running on same machine, same spec JVM).

I hasten to add that 50 of those tests were testing the validity of individual invalid characters, so that blows the failures out a bit (given they pretty much all failed). But both also failed on some fairly bog-standard stuff.

It's seriously as if it didn't occur to the engineers involved to actually implement the functionality as per the published specification; instead they simply made some shit up, based on what their own personal knowledge of what email addresses kinda look like. This is a bit slack, I'm afraid, chaps. And would just be so easy to do properly / thoroughly.

NB: there are rules around comments in email addresses that I only gave superficial coverage of, but I covered all the other rules at least superficially in these tests.

---

One new TestBox thing which I learned / noticed / twigged-to today... one can write test cases within loops. One cannot do that with MXUnit! eg:

describe("Tests for invalid ASCII characters", function(){
    for (var char in [" ", "(", ")", ",", ":", ";", "<", ">", "@", "[", "]"]){
        var testAddress = "example#char#example@example.com";
        it("rejects [#char#]: [#testAddress#]", function(){
            expect(
                isValid("email", testAddress)
            ).toBeFalse();
        });
        testAddress = '"example#char#example"@example.com';
        it("accepts [#char#] when quoted: [#testAddress#]", function(){ 
            expect(
                isValid("email", testAddress)
            ).toBeTrue();
        });
    }
});

Here I loop through a bunch of characters, and Here for each character perform two tests. This is possible because testBox uses function expressions for its tests, whereas MXUnit uses declared functions (which cannot be put in loops). This is not a slight on MXUnit at all, because it predates CFML's support for function expressions; it's more just that I'm so used to having to write individual test functions it did not occur to me that I could do this in TestBox until today. I guess there's nothing stopping one from writing one's test functions as function expressions in MXUnit either, that said. But this is the encouraged approach with TestBox.

Nice one, TestBox.

Anyway, this is not helping me prep for my presentation tomorrow. Give me a ballocking if you hear from me again today, OK?

--
Adam

What should Adobe be retro-fitting into ColdFusion 10? Here's a potential list

G'day:
Adobe fixed a helluva lot of bugs during development of ColdFusion 11 (as per "Adobe ColdFusion Splendor (codename) & Adobe ColdFusion Thunder (codename)" (PDF)).

However there's been no patch for ColdFusion 10 for a while, and an awful lot of those bugs were raised against ColdFusion 10. So by rights they should be fixed in ColdFusion 10 too.

But fair's far... not every bug is important. So I've distilled that list down to just the ColdFusion 10 bugs, and the ones that were listed as "High".

Here they are:

CFClient: pardon my ignorance / thought exercise / advice solicited

G'day:
This is a lazy-arse article, but it's Sunday and I am suffering from post-conference malaise. So... bad luck if you were after something incisive / thoughtful.

It perhaps might be thought provoking though.

And at least it's short. Once I get on with it.

CFML: Advice for Adobe re Railo

G'day:
I was a bit surprised to read this this morning:

The sole reason for adding this functionality was to make it easy for the frameworks to define the datasources from within the framework without going through the administrator. If one has to go through the administrator to get the encrypted password, that defeats the whole purpose. You can very well keep it defined there. So why define it in the application at all? 
As far as the railo approach is concerned, I don't know the details of their implementation. As Hima said, after putting the encrypted string, your code would not be portable because encryption will be installation specific. In case they are claiming the encrypted string is portable, it would mean that they are encrypting it with a static key same across all installation which is not at all a secure practice.

I dunno if Rupesh was meaning "in general" or just "in the context of this topic".

However, to be clear, the very first thing Adobe engineers - especially senior ones who seem to make decisions - should be familiar with is how Railo does stuff, and what features it has. In the context of this specific issue, as soon as I compared ColdFusion's functionality unfavourably with Railo's equivalent functionality, Rupesh should have spun-up his Railo instance and had a look. That's if he didn't already know about it.

As Adobe was playing catch-up with this feature, all the devs involved in it should have already gone over the feature in Railo and used that as a basis to make the CF implementation at least as good, if not better.

I'd be fine if Rupesh had said "yeah, we looked at that and didn't think it had merit because [reason here]", but it sounds like he didn't even know about it.

It would not surprise me if Rupesh doesn't even have Railo installed.

Adobe have to be all over what Railo is doing. They should be members on their mailing list (not just lurking, but actively discussing stuff), they should be checking out all the new features (and bugs!) as soon as they come in, and in general know exactly what the opposition is doing. Not least of all because they could learn a thing or two from Railo's implementation of things.

Obviously it cuts both ways, but I already know the Railo bods are fairly familiar with how ColdFusion operates.

When I read stuff like this, the silo of naïveté that the Adobe team resides in that I have a mental image of gets slightly higher, and the walls slightly thicker.

--
Adam

CFML: Adobe agree to revise their stand on prefixing of list-oriented member functions

G'day:
Just very quickly... you know I wrote an article the other day, "ColdFusion 11: if Adobe haven't quite sapped yer will to live yet..."? Well we got some input from community members other than just myself, and the resounding feedback was "prefix the list member functons with list".

And Rupesh posted this response today:

all right. marking it as ToFix and we will include it in the first update.
In case one has used these list methods, he/she would need to change the code.

Nice one. I guess that's two beers I owe Rupesh now. Cheers fella.

And... go the community input! See it does help if you let Adobe know what you think, rather than just sit there silently gritting yer teeth. So if you find a bug: raise it. If you think it's worth people knowing about, or if you need support making your case: let us know so we can pitch in too.

Anyway, cheers everyone involved in this: good work.

--
Adam

Looping in CFML: community input solicited

G'day:

Yesterday I wrote-up my experiences with the new cfloop() construct in ColdFusion 11: "ColdFusion 11: cfloop in CFScript very broken". The same construct exists in Railo, btw (it's nowhere near as broken).

I raised a ticket with Adobe summarising my findings: 3754577. Overnight Rupesh has come back to me, with this comment:

Though we have added a generic approach for the script syntax for all tags, it does not work in cfloop's case as the tag implementation is directly in the generated code. the exception being query or file and that is why looping over a query or file works but others don't.
Though it would be ideal to do this for completeness, is this really required? We already have cfloop equivalent in cfscript - using "for", "for-in" and "while" loops. file is the only thing that is not supported by "for" or "for-in". I feel we should stick to the "for", "for-in" & "while" and throw a good error for cfloop with indexed, array, list, collection and condition. Thoughts?

It's great to get decent, thoughtful, feedback. I put my own thoughts down in response:

I'm split on this on.

On one hand if you're gonna do this porting of tags to CFScript with this generic approach rather than with a situation-specific one, then I think the approach should be all-encompassing. If it's generic don't second-guess stuff, just do it.

On the other hand, I think perhaps having implemented cfloop() at all was perhaps a bad move. Instead it would have been better to augment the existing CFScript looping construct: for(). There's no reason why that could not have accommodated query- and file-looping functionality. The benefit of this is that for() is a familiar construct for everyone, and it doesn't necessitate yet another looping construct.

What you've ended up with is - same as with the list member functions - a situation where the language isn't "hackable". One cannot simply infer how the looping works from the behaviour of existing constructs. There is no rhyme or reason why one would use for() for arrays, but cfloop() for queries. It makes no sense. One needs to know the inner workings of what the CF Team decided to know how things work, which I think is fairly opaque language design.
I am going to solicit more community input on this, to see what people think.

I decided not to add it to my comment on the bug tracker, but I'll add it here. I also think too often the Adobe team opt for "what's quickest/easiest" rather than "what's best". And I really think this needs to stop. The language needs to come first, then how much effort is involved comes secondary to that. It would be better to not do it at all, rather than to an incomplete job due to timesaving.

A case in point is this looping thing. In CFScript we now have:

• for() - indexed, array, collection
• while() / do() - conditional
• cfloop() - files, queries
• listEach() - lists
• type-specific iteration functions

(I separate those last two out as there's no "procedural" way of looping over a list in CFScript, I think; one needs to use the functional way).

Adding in yet another way of doing looping just to cover files and queries seems wrong to me. They should have either just added in the appropriate iteration functions, or added functionality to for() to handle it. Or both. Both would have been the better solution. But cfloop() is just PHPifying to me.

But, anyway, it's not all down to just what I think (and I wouldn't even want that to be the case). I was hoping you people could pitch in on the conversation too. Care to add your comments onto that ticket I linked to above?

Cheers.

--
Adam

ColdFusion 11: Adobe goes some way to correctly identifying what constitutes an integer

G'day:
This is a follow-up to all the shenangians around isValid() and integers and what not: "Can we please agree that Adobe is not the arbitor of what constitutes an integer?". Adobe have done some work to improve things here.

ColdFusion 11: cfloop in CFScript very broken

G'day:
I started having a further look at what Adobe have done for CFScript in ColdFusion 11. According to their docs ("CFScript: Script support for tags") "ColdFusion 11 allows you to write all the tags in the script format in a very generic manner". A colleague of mine was looking at how <cfloop> was implemented in CFScript (yeah... why? I dunno... they shoulda just used for() loops), and we quickly came away going "shit, what a mess".

Defining datasources in Application.cfc

G'day:
This feature of both Railo and now ColdFusion hasn't been talked about as much as I think it should have been. Both CFML platforms - as of 4.1 in the case of Railo, and 11 in the case of ColdFusion - allow one to define entire datasources in Application.cfc. Not simple reference to existing DSNs created in CFAdmin (or via the Admin API, if you've ever tried that), but defining the whole thing right there in Application.cfc.

ColdFusion 11: what <cfclient> compiles down to

G'day:
One of Sean's comments on another article ("ColdFusion 11: <cfclient>... how does normal CFML code and <cfclient> code interact?") got me thinking:

This doesn't surprise me at all: cfclient generates JS that runs in the browser; outside cfclient, you have regular CFML that runs on the server. You can't expect them to know about each other. This is like the frequent RTFM questions on SO about using CFML variables in JS!

Whilst I don't think it's quite so painfully obvious as Sean would like us to think, he does raise a reasonably good point. I'll reproduce my response too (which is a reasonable prelude to this article):

I suppose it depends how the JS is generated. Is it extracted from the file at compile time and created? Or is it compiled in situ as part of the compiled class, then at runtime JS is generated from it and returned to the browser? I'll need to check that (I suspect it's done at runtime).

If it's done at compile time, then, yeah... there's no way initialising any variables referenced in the "server side" part of the source code which are also needed in the client side part of it, as the values won't be known.

If it's done at runtime, it should be easy enough though? Same as how one might do it with CFML writing out a <script> tag, containing JS variables which have CFML variable values as their values?

If it's all done at compile time, I don't see why <cfclient> is a *tag* as opposed to a different file type (.cfjs or something), as there's no merit in having both server-side (outwith the <cfclient> tags) and client side (within them) in the same file. Because never the twain shall meet, as you point out.

Looks like I have another blog article to write on the topic...

List of articles on Adobe ColdFusion Forums for Anit

G'day:
This is not an article, per-se, but just a list of links for Anit, I'll then be posting the link to this on Twitter. The links below are simply reproductions of my existing blog articles on the given topics, and do not represent new writing on my part.

Anit, these are the questions I wanted to ask the Adobe ColdFusion Team about some features of ColdFusion 11. As you suggested, I have posted them on the Adobe ColdFusion Forums. Here are links to the forum articles.

• ColdFusion 11: custom serialisers. More questions than answers
• ColdFusion 11: <cfclient> in the context of the CFML language, not the tooling
• ColdFusion 11: <cfclient> seems to require /CFIDE to be available
• ColdFusion 11: <cfclient>... how does normal CFML code and <cfclient> code interact?
• ColdFusion 11: <cfclient> ports a lot of CFML functions to JS
• ColdFusion 11: allowedextforinclude functionality has changed. But the docs haven't been

Thanks mate.

--
Adam

ColdFusion 11: allowedextforinclude functionality has changed. But the docs haven't been

G'day:
Remember this one: "ColdFusion 11: preventing files from being included? WTF, Adobe?". I can confirm this verymoderatelyslightly contentious feature has been changed in ColdFusion 11, but the docs have not been updated to reflect the change.

(Note: this functionality was changed to compileextforinclude, by the time ColdFusion 11 was actually released).

The issue is summarised thus (from the article linked-to above):

[...]out of the box ColdFusion 11 will only allow the inclusion of CFML and HTML files. Why? They cite "for security reasons". Here's a quote (posted in the bugtracker, originally from the pre-release forums):

"Vamseekrishna Manneboina: Yes, this was done as part of a security measure. You can now only include CFM/CFML files by default. You can specify additional extensions via a property called allowedextforinclude in neo-runtime.xml. By default, HTM and HTML file extensions are already added to this list/property, thereby allowing for inclusion of HTM and HTML files too by default."

OK, I disagree there's merit in this, some others agree, others disagree. But... so be it. I actually thought - if I was in a charitable mood - that the people that were "for" this change made a reasonable case for its inclusion, so - whilst not agreeing with them - I was content to just shrug and go "yeah, oh well".

ColdFusion 11: if Adobe haven't quite sapped yer will to live yet...

... could you do me a quick favour?

G'day:
A while back I raised this ticket with Adobe: 'List member functions should all be prefixed with "list"'; it's kinda self explanatory, but the gist is they'd implemented list member functions (good), but changed the names of the member functions to no-longer match their headless function counterparts. So the member function version of listAppend() was just append(); listEach() was just each().

I figured this was of dubious merit as it muddied what was a list-oriented member function and what was simply a string-oriented one (.append() could just as easily do a string-append as opposed to a list-append), and this notion got a lot of support: "Survey results: lists in CFML, and the naming of list member functions".

Credit where it's due, Adobe marked it to fix, and indeed "fixed" it before release of ColdFusion 11. So now we have myList.listAppend(), myList.listFind(), etc. But we still have myList.changeDelims(), myList.each() and a few others haven't got their list prefixes.

I duly raised another bug to cover this, yesterday: "listChangeDelims() member function missing".

Today Rupesh simply closed this ticket as "Closed/Withdrawn/NotABug", offering this insight:

delimiter is meaningful only for list and therefore there is no ambiguity on this. That is the reason the list methods dont need any separate qualification.
list.changeDelims() is better than list.listChangeDelims()
Same is the case for map, each and filter methods. They apply only for collection and I don't see any ambiguity there.

Honestly? Sigh.

ColdFusion 11: "Select ColdFusion Server Profile"

G'day:
I'm just getting rid of the ColdFusion 11 beta on my machine, and installing the release version. Straight away there's an intriguing new feature that wasn't in the beta:  "Select ColdFusion Server Profile":

ColdFusion 11: it should go without saying...

G'day:
I don't believe ColdFusion 11 is production-ready yet: the beta was too short, and - speaking for myself - I'm still finding bugs every time I decide to try something (not "every time I look for bugs" but "every time I try one of the new features, just to see how it works"). And not inconsequential bugs.

So I was out by a fortnight: ColdFusion 11 ships

G'day:
I originally guessed that CF11 would be released on May 12: "ColdFusion 11 release date confirmed to be no later than...", but I was wrong. It's just been released: "Announcing the launch for ColdFusion 11 and ColdFusion Builder 3".

I've not much else to add on that topic, other than to say I don't think it's ready: it needed another round of beta.

It'll be interesting to see how many of the bugs I've raised in it have been fixed. I'll start looking into that this evening.

Anyway, there you go. That's the "breaking news".

--
Adam

"ColdFusion today is a uniquely irrelevant product"

G'day:
Some of my elves put me onto this (no, I do not really have elves, but the person probably doesn't want to be identified as the person bringing this to my attention).

Here's a video presentation by Gojko Adžić entitled "How I Learned to Stop Worrying and Love Flexible Scope", which is about - at least in part - on how to plan a software road map. That in itself is moderately interesting. I have not watched the whole lot, as the streaming quality for me is very choppy, and it's a bit frustrating to watch/listen to.

But what is fascinating is that he's chosen Adobe ColdFusion's roadmap, and their general approach to software releases as the model "how not to" situation.

ColdFusion 11: <cfclient> ports a lot of CFML functions to JS

G'day:
I will start this article - which won't be a long one - by stating I am an adequate JavaScript developer, but I am by no means an expert. I'm at that stage wherein I'm au fait with the syntax and the nuts and bolts of writing OO-esque JS, but I don't spend enough time doing it to know the minutiae of "best practice" and don't automatically know the differences between the "best" way of doing something, and just "a way of doing something". Hence this article asks a question, rather than making any concrete statements.

ColdFusion 11: <cfclient>... how does normal CFML code and <cfclient> code interact?

G'day:
Another quick one. I'm raising these quick-fire questions here because Adobe have declined to suggest a better place to raise them, other than as comments on one of their blog entries. Well that was Ram's suggestion (which I don't think is terribly-well thought out). He declined to react to my suggestion that the Adobe ColdFusion forums might be a good place. Anit suggested Twitter or just emailing him, but I think there'd be public interest in this stuff, so don't want to resort to email.

As I'm the master of what goes on on this blog: I'll clutter this thing up.