Odd behaviour with struct keys with dots in their names

G'day:
I've been looking at this one due to an interesting question on Stack Overflow: "Confusion in dynamic variable access in ColdFusion". I could not immediately see what the problem was, and it's taken me a coupla hours to work out what's going on.

ColdFusion 11 is not ready for release in one month's time. Simple.

G'day:
This is a short adjunct, designed to encourage the Adobe ColdFusion Team to respond to their community. It'd be helpful if you could retweet it.

In my opinion, CF11 is not ready to release for one very good reason:

2014-04-12 17:58 Untriaged ColdFusion 10 bug count: 67. List: http://t.co/XGoReqPrfq
— CfmlNotifier (@CfmlNotifier) April 12, 2014

67 ColdFusion  bugs not even looked at yet? Yer having a fucking laugh, Rakshith.

I wrote a speculative article the other day: "ColdFusion 11 release date confirmed to be no later than...", which intuits that we're about four weeks shy of ColdFusion 11 coming out. I think this is borne out by an increase of bug closures with "can't be arsed... maybe in two years time" (I think it actually said "Closed/EnchancementRequired" or "Closed/NotEnoughTime").

However as far as I can tell, Adobe haven't even bothered to look at a whole bunch of the issues their paying customers have raised with them.

I really don't understand how Adobe can be so dismissive of their clients. I seriously can't see how this is even "minimum professional" behaviour, let alone appropriate behaviour when they're in one of their very rare development cycles.

In contrast, Railo has the "luxury" of being able to do continuous development, so continuous issue triage/resolution, and they very rarely leave an issue untriaged (and even unfixed!).

Adobe choose to only do development on ColdFusion once in a blue moon, so they really have to at least triage all the currently outstanding issues. And, if they were to have any sense of professional integrity, fix the bugs, implement the features, or explain why they don't.

Adobe have done a bunch of good stuff for ColdFusion 11, but they are way more than a month away from delivering a professional product. Part of being professional is listening to one's clients.

I would like Rakshith to respond to this article. And what's up with their bug-fixing...

--
Adam

Ye Olde XMLSearche Bugge

G'day:
Henry mentioned this last night:

XMLSearch() is not thread safe since CF7 http://t.co/ubz29eJOOt #coldfusion Just encountered in CF10.
— Henry Ho (@henrylearn2rock) April 8, 2014

That sounded like something I could get my teeth into, so had a look at it this morning.

Railo: I've got to the bottom of that code I asked you to test for me

G'day:
Thanks to everyone who helped out with my challenge in this article: "Railo: help me replicate a bug I'm seeing on one of my machines". I think the reason I was seeing the difference in behaviour is twofold:

1. I'm a dropkick;
2. Railo's setting "Local scope mode" (which I can't find docs to link to [grumble], so I'll need to explain it).

The reason why I suspect I'm a dropkick is that I think this is all down to my machine at work having "local scope mode" set to "modern", whereas every other instance I have been looking at is set to "classic". I do not recall switching my work machine to use this setting (and I'll be switching it off as soon as I sit down at it on Monday), but it seems like this is what the difference is.

Thanks to Gert for pointing me in the direction of the various Railo "make Railo work differently from ColdFusion" settings that Railo has.

Railo: help me replicate a bug I'm seeing on one of my machines

G'day:
A few days back I raised a bug with Railo - "Bug with scoping inside iterator functions" (RAILO-3000) - which only happens on one of my Railo installs (out of six installs, on four different machines). Micha can't replicate it either. I'm trying to get to the bottom of what's going on, and what's different about my install.

Update:

I've got to the bottom of this. See "Railo: I've got to the bottom of that code I asked you to test for me"

Here's the code:

ColdFusion 11: bug triage (and fixing?) seems to have stalled

G'day:
Ages back I wrote an article "212 untriaged ColdFusion 10 bugs", and indicated my horror at how many bugs in the current version of ColdFusion that Adobe had seen fit to simply ignore. I don't mean "not fix", I meant "just completely ignore; ie: not even acknowledge the bug had been raised".

I followed this up a coupla months later with "Bug watch: 212206 untriaged ColdFusion 10 bugs"; in that two months they had managed to triage a net of six tickets that had been raised.

Just a week later we were down to 165 untriaged bugs: "Good work Adobe ColdFusion Team!", and they had made good progress from there, getting it well below 100 untriaged bugs, and got it down to a low of 40 on Jan 22 this year. Again: good work!

ColdFusion: Of integers and indolence

G'day:

Yes, OK, I'm still banging on about integers and ColdFusion bugs. It's my blog and I can talk about whatever I like! ;-)

You might be aware that I am particularly nonplussed about Adobe's reaction to bug 3712010, which relates to integer validation via isValid(), and how it is broken.

I started by just being mildly annoyed by how ColdFusion can make such a pig's ear of something that should be simply. But the more Adobe (or, hey, let's say it: Rupesh from Adobe) squirms about the place and tries to justify why they shouldn't just bloody fix a fairly obvious bug, the more annoyed I am getting about this. I dislike having my intelligence insulted, and I also dislike the collective intelligence of the ColdFusion community insulted. Especially by someone who very clearly should not be in the business of insulting anyone's intelligence.

It's all getting a bit stupid, but one of the comments posted today on this caught my eye and made my blood boil just that bit more. I've asked Carl if I can reproduce his comment, and he has said it's fine. So here it is. I've dollied it up for formatting, but it's othewise unchanged.

Your ColdFusion bugs - visualised

G'day:
I'm stealing some of Ray's code here, and making it more general and exposing it for all to use.

ColdFusion 11: Adobe listening to their clients

G'day (from London again now):
Earlier in the week I wrote an article "ColdFusion 11: lists and arrays and empty elements and weird ways to fix stuff", which commented on some poor logic / common sense behind the way Adobe had chosen to fix an issue around how the application setting this.sameFormFieldsAsArray works, in that the array it creates ignores empty form values.

ColdFusion 11: lists and arrays and empty elements and weird ways to fix stuff

G'day:
Someone has asked me to draw attention to this issue (3560964), as they are dissatisfied with the way Adobe have handled it. Personally, I'm ambivalent, but err more towards the community members' positions than Adobe's. The detail of the ticket boils down to this:

Prior to CF10 to turn a repeated form element into an array we used getPageContext().getRequest().getParameterMap().

This worked smoothly this feature was replaced in CF10 with the application flag:
<cfset This.sameFormFieldsAsArray = true> This works nice except it removes empty elements. getPageContext()...getParamterMap() now returns an empty struct.

Breaking out of an each() loop

G'day:
I'm just soliciting opinions here. I'll raise a ticket for it anyhow, but let's see what people think.

ColdFusion: Fixing any bug has backwards compatibility concerns

G'day:
I'm going to bang on about isValid() and integers some more. You've been warned.

Right, so I was horrified to see that this is the case in ColdFusion:

isValid("integer", "$,1,2,$,2352345,$"): YES

And, what's more, having used ColdFusion to establish that $,1,2,$,2352345,$ is in fact an integer, if I then try to use it as an integer, ColdFusion breaks. At least it gets this half right. I discuss this at undue length in "Can we please agree that Adobe is not the arbitor of what constitutes an integer?".

Good old Rupesh poked his head above the parapet briefly, and offered a better response than one might expect here:

Rupesh Kumar • a day ago

There is no doubt that this behavior is incorrect. It is obviously wrong and it should be corrected. However, it has been like this forever and making such a fundamental change has a great potential to break a lot of applications. We dont want to do that in this release. As Rakshith has already communicated, we plan to take up such changes in 'Dazzle' where we will correct the behavior without worrying about backward compatibility.

This is an improvement over his earlier comment on the topic:

• 
  Rupesh Kumar

  2:53:06 AM GMT+00:00 Apr 24, 2012

  This has always been the behavior and changing this would result in backward compatibility issue. It will not be fixed.

There's a fundamental error in Rupesh's internal logic here. To suggest that fixing a bug somehow has backwards compatibility issues is utterly specious.

Intrinsically "a bug" causes some manner of behaviour to occur. It's a bug because the behaviour is incorrect. And, intrinsically, if a bug is fixed, it is implicit that the previous behaviour will change. That's the entire reason for fixing the bug: to replace incorrect behaviour with correct behaviour. So, on the face of it (and this is why I say his position is specious, not simply out and out frickin' stupid... although it is also that), this creates a backwards compatibility consideration. Because the new (correct) behaviour will be different from old (incorrect) behaviour.

But this is the nature of fixing bugs. The behaviour of the buggy functionality changes because it becomes "not buggy". If we were to clamour "backwards compatibility!" each time we considered fixing a bug... no bugs could ever possibly be fixed. And clearly we do fix bugs (obviously). So "backwards compatibility" is not grounds for not fixing bugs. Because it is not actually a valid consideration.

CFML: Expressions and operators and doing weird s***

G'day:
I want to just return to the topic I touched on here briefly the other day in the article "ColdFusion 11: good stuff", and discussed more thoroughly on the Railo Google Group as "Probable bug in null-coalescing operator". I have moved my opinion here from "probable bug" to "definite bug". And the buggy behaviour relating to this extends further, and into both Railo and ColdFusion.

My contention is that Railo have implemented the null-coalescing operator (tritely referred to as the "Elvis operator" by some. Spare me) slightly incorrectly, as it confuses the notions of "null" and "non-existent" which are two distinct concepts. Also, in implementing this "non-existence-coalescing operator", it's done some rather fishy things in the process.

All of this has also now found its way into ColdFusion 11, unfortunately.

Can we please agree that Adobe is not the arbitor of what constitutes an integer?

G'day:
My... what a lot of ColdFusion chatter this is at the moment. It's bloody good I'm on holiday at the moment so I can keep up with it (and... erm... instigate some of it... ;-).

But for this article / gripe session, I want to reiterate an old article I wrote about integers. And ire.

ColdFusion 11: preventing files from being included? WTF, Adobe?

G'day:
This is a follow-on from my earlier article "ColdFusion 11: first bug. Bad bug.". I'm writing it up separately here as it's a slightly different issue, worth discussion.

That previous issue cropped up because I was trying to run my TestBox regression tests on ColdFusion 11, and somewhere under the hood TestBox includes (via <cfinclude>) some JS and CSS files. This is not an uncommon practice (more common with JS than CSS, that said), and a handy way of writing out JS at request time. This is necessary sometimes to "pass" server-homed data to JS code, before running the rest of the JS out of .js files, executed on the browser via script tags.

I also know of one application that uses this to good effect generating dynamic .doc files, wherein the doc template is saved in XML format, and by including the file, runtime CFML expressions are processed into the resulting .doc file. This is really pretty cool.

Adobe in their infinitesimal wisdom have decided to prevent this functionality by default. Yeah, now 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."

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

Not to put too fine a point on it, but... Vamsee... what the hell are you on about? What security measure? What security are you protecting against here? What's the use case?

ColdFusion 11: first bug. Bad bug.

G'day:
Well that didn't take long.

One can no longer <cfinclude> any sort of file except a CFML file. EG:

<cfinclude template="junk.js">

This yields:

Invalid template junk.js provided for CFINCLUDE tag.

CFINCLUDE tag only supports including ColdFusion templates.

The error occurred inC:/apps/adobe/ColdFusion/11beta/gettingstarted/cfusion/wwwroot/shared/misc/junk/junk.cfm: line 1

1 : <cfinclude template="junk.js">

TestBox, BDD-style tests, Railo member functions and bugs therein

G'day:
One of the promised features of ColdFusion 11 is to bring "member functions" to ColdFusion's inbuilt data types. Railo's already had a good go at doing this, and has reasonably good coverage. See "Member Functions" for details.

One concern I have is whether ColdFusion 11 will implement these the same way as Railo already has. I mean... they should do, there's not much wriggle room, but who knows. If there's a way to do it wrong, I'm sure Adobe can find it. With that in mind, I want to be able to run through some regression/transgression tests on both systems once ColdFusion 11 goes beta, so in prep for that, today I knocked out some unit tests for all the struct member functions.

What I did is to go into the ColdFusion 10 docs, go to the "Structure functions" section (to remind me what all the functions were), and write unit tests for the whole lot. I used the ColdFusion docs rather than the Railo ones because the CF10 docs are more comprehensive than Railo's (this is an indictment of Railo's docs, not a recommendation for the ColdFusion ones, btw!), plus I wanted to make sure I covered any functions Railo might have overlooked.

To make this more interesting (because, let's face it, it's not an interesting task; either to undertake, write up, or for you to read about!), I decided to have a look at TestBox's BDD-inspired testing syntax. The short version of this side of things is that I rather like this new syntax.  I don't think it's got anything to do with BDD (which is an approach to documentation and test design, not a syntax model), but it's interesting anyhow.

Anyway, stand-by for a raft of code (there's a Gist of this too: Struct.cfc):

Slow news day & Adobe charging twice for CFML features

G'day:
You'll be pleased to know that Brendon McCullum got his 300 runs, becoming New Zealand's highest scorer for an innings, finally falling on 302. New Zealand declared on 680, which is their highest innings score in test cricket. We now have 56 overs to bowl India out to win the match. Which is seeming possibly on the cards as they are already 28/2: "McCullum, Neesham bat India out".

Increasingly the news media is relying on Twitter banality for its news content, and - whilst not a news organ - I don't see why I should be any different. So today's article is brought to you via a comment on Twitter.

I think I'll stop reporting ColdFusion 10 bugs & submit them as CF11 feature requests... since that's what's happening anyways :(
— James Moberg (@gamesover) February 18, 2014

James raises a very good point, and one I've been meaning to comment on for a coupla months now. Adobe are currently working through their bug backlog, and a lot of bugs are being fixed, with the comment of "this will be available in the next major release of ColdFusion" (ie: ColdFusion 11). That has a veneer of good news about it, but let's stop to think about this.

ColdFusion 9 and ColdFusion 10 are the current versions of ColdFusion. They are both still within their standard support phase (ColdFusion 9 until 31/12/2014, and 10 until 16/5/2017. Ref: "Adobe products and Enterprise Technical Support periods covered under the new Lifecycle Policy").

Railo bug? Or ColdFusion bug...

G'day:
I've had a bit of a break, as you will have noticed. I'm now sitting in my folks' place in Auckland, watching the cricket with me dad. New Zealand are desperately trying to salvage the match against India from certain loss. Currently NZ is on 363/5, with McCullum (183*) and Watling (92*) being the last real line of defence against India. NZ only lead by 118. We kinda need a lead of 250 to not lose (India have another innings yet, and there's still a day and a half to go). We're definitely not gonna win, but we might be able to eke out a draw.

I know hardly any of that will mean anything to most of my readers. However cricket represents "summer" to me.

But enough of the waffle.

Segue alert. One of the most noted wafflers in the CFML community - Scott Stroz - discovered some interesting behaviour when we was migrating some code from ColdFusion to Railo, and initially suspected a bug in Railo. I've had a closer look, and I think it's more likely a bug in ColdFusion, with the behavioural difference with Railo being that it doesn't have the bug. However I'm only 90% convinced of this. Here's the deal...

Enhancement suggestion for parseDateTime()

G'day:
A quick one. parseDateTime() is used for taking a string and trying to convert it into a date object (as reflected by the date represented by the string).  It does a pretty shocking job of it, as demonstrated by the following code: