99

G'day:
Just quickly... Adobe's got the Untriaged ColdFusion 10 Bugs List down to fewer than 100 now. Nice one! We're getting there!

--
Adam

ColdFusion: Good communications from Adobe

G'day:
I'm always quick to berate Adobe for poor communications, so - fair's fair - here's a "hey nice one!" at them - Rupesh in particular - for some feedback he's given on one of the tickets I had raised on the bug base.

Ages ago I found that there was no native way in CFML to determine if a variable is a file handle. EG: we've got isStruct(), isArray() etc, but no isFile() or similar. I wrote an article about this: "How do I know if this variable is a file handle?" I also raised an enhancement request (3299625) to get it dealt with.


Pleasingly it's been marked as "fixed", so in ColdFusion 11 we'll have isFileObject() (which I think is a better name than my suggested isFile()). The reason I know this detail of what the function will be is because Rupesh has taken the time to feed back on the ticket. This is cool. It might seem trivial, but this sort of community engagement is really good, and makes Adobe look far less faceless than they come across sometimes.

So cheers for the feedback Rupesh. And keep it up!

--
Adam

Expectations management: date casting in QoQ

G'day:
Just a quick one today. I camne across some unexpected (to me) and pretty unhelpful behaviour in QoQ yesterday, with the cast() function.

ColdFusion: Adobe have only gone and done it again! (but in a good way)

G'day:
A great tract of "status update" messages came through @cfBugNotifier this afternoon, and Adobe are now down to 138 untriaged ColdFusion 10 bugs. That's down another 20-odd from a coupla weeks back when they had a big run and knocked it back from 200-odd down to 160-odd. This is definitely good process.


What's good in this tranche? There's a bunch of stuff relating to REST services, and some image-processing odds 'n' sods. Neither immediately affect me, but some sound like good fixes to get sorted out. The only ones that do affect me directly, are these two:

Good work Adobe ColdFusion Team!

G'day:
I've run a coupla articles about how many ColdFusion 10 issues there are outstanding in the Adobe ColdFusion bugbase, and how there seemed to be total inertia in dealing with them:

• 212 untriaged ColdFusion 10 bugs
• Follow-up to "212 untriaged ColdFusion 10 bugs"
• Bug watch: 212206 untriaged ColdFusion 10 bugs

Well I'm pleased to say there's been a flurry of activity recently - in the last day or so it seems - and we're now down to [checks]... 165 untriaged ColdFusion 10 bugs (at time of writing). That's still quite a few, but it's also 40-odd fewer than there were a week or so ago.

ColdFusion: CFSQLTYPE issue Status => "To fix"

G'day:
Yeah, I've been slack recently. I've got something in the pipeline (or about four things in the pipeline), but they're all too labour intensive, and I've been sidetracked onto other things when I have the inclination to be technical.

Anyway, here's a quick one. Do you recall the article I wrote a week or so ago "Minor common-sense tweak to CFML from Railo"? Well I raised an equivalent issue with Adobe for ColdFusion: "Support plain-named query param types" (3616682). To save you the click through, the gist is this:

Railo supports more obvious type names for <cfqueryparam> tags, eg: "integer" rather than "CF_SQL_INTEGER". CF could join the party on that one.

Whilst I'm here, how about getting rid of the "cf" on "cfsqltype". Indeed, just get rid of "cfsql". It's a type. It's in a <CFQUERY> tag... we know it's CF and SQL, so why belabour the point?

Anyway, I got notification today that Adobe have marked it "to fix".

Cool! Nice one Adobe.

--
Adam

Bug watch: 212206 untriaged ColdFusion 10 bugs

G'day:
The code & testing for the article I'm writing is going to take a few hours, and Mon-Fri I only have a coupla hours available each day to write said code, so I'll not get to the actual article until the weekend. In the meantime... where are Adobe at with bug fixing?

A while back I posted an article "212 untriaged ColdFusion 10 bugs", and a follow-up a few weeks later "Follow-up to ~".

As of today, there are 206 untriaged bugs raised against ColdFusion 10. This is a net reduction of six since May, three months ago.

Most popular unhandled ColdFusion bugs

G'day:
Apropos of not much, I grabbed a list of all the ColdFusion bugs in the bugbase that:

• have ten or more votes;
• do not have a status of "fixed".

Here's a table of them, and my thoughts.

The process of creating a clear repro case for a bug: <cfchart> vs Async CFML gateways

G'day:
It's bank holiday Monday and it's gloriously sunny outside, but for some reason I am investigating a bug I didn't even know existed nor would ever be likely to encounter. I'm a dick.

Damn you and your opinions, Dave Ferguson

G'day:
(Just kidding Dave... that's just a reference to Scott saying I'd be doing a blog article about you after hearing the latest CFHour: "Show #189 - Manage Your Indention").

This is clarification of something Dave did dwell on during that podcast, in reference to my article 'Really, Adobe: "NotWorthEffort"'. And to fulfill Scott's observation that I'd feed-back on what Dave said.

That article draws attention to what I perceive is slack-arse-ness on Adobe's part in how they dealt with a user-raised issue on the bugbase relating to the toScript() function (3041310).

The lads on CFHour made a few points / observations which are relevant, but at least partially tangential to the point I was trying to make.

Firstly: yeah, the code that toScript() generates works. It's slightly verbose, but it works. That's a very low bar to set though, isn't it? The approach taken here demonstrates a certain lack of finesse that one might expect from a function Adobe (OK: it was Macromedia) have provided to effect a better solution that just rolling one's own. And surely that's the intent here? It also kinda shows their hand in regards to their JavaScript capabilities, which seem to be "less than ideal" (I'd actually say: "not up to the job").

CFML: A bit more on getFunctionCalledName(): it's broke in Railo

G'day:
Sorry for the "slow-news week" this week (well: it's been a coupla weeks now). Everything I'm planning to write up will take a while to prep, which means I find excuses to do something else instead.

A while back I wrote about getFunctionCalledName(), mostly because I can never find it in the ColdFusion docs as I never remember enough of what it's called to google it properly. So that article was purely google-bait (it didn't work, just in case you're interested... I still cannot ever remember what getFunctionCalledName() is called, nor can I successfully google it up).

ColdFusion & JSON: yet another bug

G'day:
This might actually be a manifestation of the same issue I wrote about a while back: "Right... so JSON is being a pain in the arse again". And I didn't spot this one myself - I've given up on using JSON in ColdFusion as it's just too unstable - but read about it on a thread on CF-TALK (it's not in the archive yet, so I cannae link to it).

Anyway, this time the issue is with ColdFusion and "strings that look like numbers" again, but a different slant on it. Consider this code:

number = .0006;
struct = {number=number};
json = serializeJSON(struct);
writeDump([
    {number=number},
    {"struct.number"=struct.number},
    {struct=struct},
    {json=json}
]);

On ColdFusion (9, and apparently 10 too, going from the thread I can't link you to...), the output is this:

array
1	struct NUMBER .0006
2	struct struct.number .0006
3	struct STRUCT struct NUMBER .0006
4	struct JSON {"NUMBER":6.0E-4}

Nice. Thanks for that, ColdFusion. Just in case yer really going "wah??" there, that's scientific notation for 0.0006. So, ColdFusion... which part of "turn this into JSON" did you interpret as "turn this into JSON and any numbers with more then three decimal place? Scientific notation please". Just to demonstrate that this is not "just one of those things", here's the output in Railo:

ColdFusion: Really, Adobe: "NotWorthEffort"

G'day:
So I started to write an article on the performance of evaluate() (and whether it's still a problem), but I got sidetracked by other CFML stuff I was catching up on, and now I'm on to article two of three articles to today that I'm writing instead. Mostly cos they're easier than the evaluate() one.

This is another one on toScript().

Whilst researching the earlier article, I looked to see what other bugs there already were with toScript(), to see if I was treading already-trod ground (no, as it happens). Ad I came across this bug, raised by Ray Camden a while back: 3041310. The gist of it is demonstrated by this code:

cfRainbow = ["Whero","Karaka","Kowhai","Kakariki","Kikorangi","Tawatawa","Mawhero"];
jsRainbow = toScript(cfRainbow, "jsRainbow");
writeDump([cfRainbow,jsRainbow]);

The result of this is:

toScript()? New to me. New bugs to me, too

G'day:
I'm in Portumna visiting my boy... well not right now, I'm in the pub starting my second pint of Guinness, but the point is I'm away from home and am on my baby netbook rather than my usual rig, so blogging / coding / internet access / my-ability-to-do-useful-things are all severely curtailed today.

That said, to kill time, I'm writing a coupla articles.

Whilst on the subject of things in ColdFusion that don't work

G'day:
I also found this one whilst testing Adam's code (as per previous article).

This doesn't work in ColdFusion (9.0.1):

a = 1;
b = 2;
writeOutput("Result: #a == b#");

I get:

Error Occurred While Processing Request

Invalid CFML construct found on line 4 at column 25. ColdFusion was looking at the following text:=

But this is fine:

a = 1;
b = 2;
writeOutput("Result: #a EQ b#");

Obviously both should work fine. And they do on both Railo and OpenBD.

That's all I have to say on that. Bug raised: 3600686.

--
Adam

Stupid (but trivial) bug with htmlEditFormat()

G'day:
I was putting Adam Tuttle's htmlDecode() UDF through the approval process just before, and found a daft (and admittedly pretty inconsequential) bug with htmlEditFormat() whilst I was about it.

Another day, another ColdFusion JSON bug (and a Railo bug too, just not with JSON)

G'day:
Well at least this time it wasn't something that caught me out. This one wasted someone else's time.

Yeah, so it wouldn't be my working week without another CF vs JSON issue

G'day:
Poor old me, and poor old Mockbox.

I just found this one when testing Mockbox 2.1. Testing it to see if we could upgrade to it (no, not until this is fixed). We already could not upgrade to 2.0 due to another issue (MOCKBOX-6), so on 1.3 we stay for the time being.

Both of these issues have been ColdFusion problems that Mockbox has been victim of though. Which sucks a bit for Luis & co.

Stand-alone repro case for that weird interface bug

G'day:
This is a follow-up to the article from yesterday detailing some weirdness I was getting when using Mockbox to mock methods in CFCs which implemented interfaces.

I have no factored-out Mockbox as a factor in this issue. The tangentially-related issues in Mockbox still stand, but I wanted to have a repro case that did not have any third party code in it. And now I have one.

Well done Adobe ColdFusion Team

G'day:
Hopefully you've heard there's a patch out for ColdFusion 10 (now version 10.0.11) for the web sockets security hole that Henry Ho noticed a week or so ago. I did some investigation on the issue, and identified four separate problems with the web sockets implementation on un-patched (10.0.10 and below) ColdFusion 10 installations.


The good news is that two of those four issues are fixed, and they are the two significant ones:

• public CFC methods were callable via web sockets. Only remote methods ought to be externally accessible;
• non-web-accessible CFCs were accessible via web socket requests, provided there was a ColdFusion mapping to them.

I've verified those are now fixed.