I owe Adobe an apology, so here it is

G'day:
I've added this to the article in question, but I am also gonna post it separately as a testament to my stupidity, and to basically apply some scorn to myself.

invokeImplicitAccessor is quite cool. Although has some odd quirks

G'day:
In the course of writing up some of my experiences taking the "Ruby Bits Part 2" course, I was messing around with some equivalent CFML code, and came across some interesting idiosyncrasies. What would CFML be without idiosyncrasies, eh?

ColdFusion / JVM and DNS caching: maybe Adobe aren't out to get me after all!

G'day:
Well here's something I didn't know. Depending on how your ColdFusion server is configured, DNS look-ups it does might be cached "forever" (read: for the life of the JVM).

Ray followed up my earlier post about "Adobe possibly messing with ColdFusion community projects again", pointing this out in a comment:

Anyway - don't forget that CF has that bug where it caches DNS lookups. Maybe the IP changed, and your host CF install is holding on to the wrong IP. That could be why it worked just fine on your local machine and Sharon's.

Try using the IP on the host. Of course, if they have multiple servers on the box it won't resolve to the right virtual server, but you would get a response right away.

My response to Ray (and the next two paras are a re-edit of my reply to him) was that I didn't know that! We learn something every day.

... although Adobe seems to have fixed their own notifications on the bug tracker

G'day:
I buried this at the bottom of my previous article, but on reflection it's pretty good news in and of itself, so I'll elevate it to its own quick article.

The Adobe bug tracker seems to have started sending out update notifications at last!

Adobe possiblynot messing with ColdFusion community projects again

G'day:

Stop Press

(although, like, that can only be done before something gets published, I guess ;-)
There's a chance this is down to an IP address change on Adobe's end, and a DNS caching issue on my end. Stay tuned...

...Stop the press, take to it with a sledgehammer, throw press away

Well I owe Adobe an apology! It was indeed mostly an IP address chance at their end, and DNS caching on my end. Once I got the server restarted (with some config changes), the DNS issue is solved, and I can reach Adobe again. They have changed their bugbase JSON responses slightly so I need to rejig my end of things, but that's nae bother and I should have it sorted out tomorrow.

I really did leap to judge too soon here, and I feel a bit daft for having done so. I'm all for applying derision to a situation, but I do actually think it should have a foundation, and it doesn't in this case.

Apologies, Adobe.

I'm gonna leave the rest of the article here as a monument to my stupidity.

This time, let's nip something at the bud: I don't give a shit who interprets who is at fault for any of this, nor how people confuse the notions of fault and blame, and will contort analogies to convince themselves they're right (I am not blameless here). This isn't about that.

Adobe have messed with the viability of some community projects again. This time: my ones.

arrayEach() could stand some improvement

G'day:
I'm going to lobby to get Saturday renamed "Sidetrackday". I sat down to write up a bunch of stuff one Ruby, and so far have written some CFML, some JS, some PHP and some Ruby... but not the Ruby I was intending do. Oh well.

I've touched in the past on my opinion that ColdFusion 10's new arrayEach() function is rather poorly/superficially implemented (here too), but today decided to check out how other languages deal with the same thing, and try to conclude what's the best approach for CFML to take.

So what's the story with arrayEach()?

Digression:

Those docs, btw, are frickin' useless:

• Where's the code example?
• Where's mention of the arguments passed to the callback? How many? What are they?
• See also "other closure functions". Should that be a hyperlink, or is it just meant to be a pointless exercise of stating the obvious?
• Category "Closure functions". Again: no link. And there isn't a category elsewhere in the docs "Closure Functions".
• The function argument doesn't need to be inline. It just needs to be a function reference.

There's more wrong about those docs that there is that is right. That's quite an achievement.

End of digression.

So in lieu of the docs explaining this, what does it do? Here's a baseline demonstration:

rainbow = ["Whero","Karaka","Kowhai","Kakariki","Kikorangi","Tawatawa","Mawhero"];

arrayEach(
    rainbow,
    function(v){
        writeOutput(v & "<br>");
    }
);

This outputs:

Whero
Karaka
Kowhai
Kakariki
Kikorangi
Tawatawa
Mawhero

Basically what arrayEach() does is loop over the passed-in array, and then passes the value of each element to the callback function. The callback function receives one argument, that value. That's all it receives. And it can return a value if it likes, but nothing is expecting the value, so for all intents and purposes, the callback's method signature is:

void function callback(Any value)

Superficially that's fine. However it's a very isolated-element-centric approach. What I mean is that as far as the callback goes, the value it receives - for all intents and purposes - is not an element of an array, it's simply a value. You cannot act on that value in its content in the array. What? Well let's say I want to transform the array's elements. A simple example would be to upper-case the elements of an array of strings. Maybe like this:

rainbow = ["Whero","Karaka","Kowhai","Kakariki","Kikorangi","Tawatawa","Mawhero"];

arrayEach(
    rainbow,
    function(v){
        return ucase(v);
    }
);

writeOutput(rainbow.toString());

Well... no. Remember how I said that nothing is listening for a return value? Well it's not. So you're returning your upper-cases element back to the ether. v is a disconnected value here: the callback doesn't get it as part of the array, it just gets it as a value.

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

CFML: Mostly pointless custom tag exercise

G'day:
Yesterday I wittered on about IRC, and how I landed there as part of an exercise to help Kyle with a code challenge he was having. Kyle wanted to know if it was possible to write a custom tag which emulated <cfmail> (easy), except including the fact one doesn't need to specify <cfoutput> tags in the body of a mail message with <cfmail>. That got me thinking.

First up, here's a <cfmail> example of what I'm talking about:

<cfset msg = "G'day world">
<cfmail to="dac.cfml@example.com" from="dac.cfml@example.com" subject="#msg#">
#msg#
</cfmail>

And this yields:

type:  text/plain; charset=UTF-8
server:  127.0.0.1:25
from:  dac.cfml@example.com
to:  dac.cfml@example.com
subject:  G'day world
X-Mailer:  ColdFusion 10 Application Server
body:   G'day world 

Note how #msg# was resolved in the body of the <cfmail> tag without there being any <cfoutput> tags around it.

If I was to knock out a quick mail.cfm custom tag and try that:

I... aaaah... see

G'day:
That heading works better if one is aware of how non-rhotic the Kiwi accent is.

Anyway, I was wittering away "helping" someone (Kyle Macey) with a CFML problem last night, when someone suugested taking the conversation to a different venue as the list of people being referenced in the conversation was taking up most of the Twitter message space.

And someone suggested using IRC.

Knock me over with a feather... people still use IRC?

Wow: ColdFusion's built-in functions will now be first class in ColdFusion 11

G'day:
Gotta be quick: at work. A while back I wrote an article "Callbacks and built-in functions as first-class functions", and floated the idea of promoting built-in functions to be first class: 3434441.

A few weeks back that ticket got marked "to fix", which I thought was good news.

Even better news: it's now been marked as "fixed/to test". So it's been done! Nice one!!

Update:

I've raised this with Railo too: RAILO-2629.

What this means is that one will be able to treat built-in CFML functions  - eg: listAppend(), ucase(), etc - as objects, being able to assign them to variables, pass them as arguments, etc. Here's a very contrived example:

ColdFusion: Latest from Adobe on the getParameter() thing

G'day:
Just noticed this new comment on 3222889:

Of course the method is there since it is part of the interface. It is just that the call for getParameter('param') is returning null and we will have to debug Tomcat source to understand that. This object is coming from Tomcat and we don't have any control on it and hence we can't do much about it.
However, I am curious to know the scenarios when you would like to use it. We anyway provide you the Form scope through which you would get all the request parameters. What would be the scenario when you would not want to use the Form scope and use the getParameter method of the request object?
We exposed the API to get the underlying application server's pageContext object and we are giving that. But if some method on that object is not working correctly, it would certainly be not a bug with ColdFusion, would it? 

This kinda conflicts with Micha's findings about the same, doesn't it?

I'd also like to point out that this has already been explained in comments against the ticket. However it would of course require Rupesh to pay attention to them.

But fair's fair: there's not a huge amount of detail from Damon there. I will touch base with him and see if I can get a better understanding of what's going on, and why he needs this, and replicate it here.

And now I have a day job to attend to.

--
Adam

CFML: Things I do like: contrasts

G'day:
This is a follow-up from yesterday's article "Things I dislike: jobsworths". In this article we see the constrast between how Adobe conduct themselves, and how Railo do in a similar (well, hey, identical) situation. The very same situation.

Yesterday I observed that the blameshifting and general work-avoidance tactics from elements of the Adobe ColdFusion Team is very bloody slack, and really not acceptable. This is in the context of an - admittedly minor / edge case - issue with how some methods within the ServletRequest implementation (or usage, not sure) seem to work. The issue itself is - as I say - inconsequential, but Adobe's antics of excusing themselves from doing anything about it were lamentable.

In the course of troubleshooting / reproducing / investigating this issue, I noticed the same behaviour seemed to be occurring on Railo. In the spirit of fair play, I hit Railo up about it as well to see how they'd deal with it (and expecting some technical guidance which I was unlikely to get from Adobe).

The contrast in reaction could not be more profound. Just to give the executive summary before I start copying and pasting material you could have already read elsewhere: Railo technical support rocks. And in particular Micha goes above and beyond what I'd expect from any vendor's engineers. At this really really puts to shame how Adobe's team conduct themselves.

Decompiling ColdFusion's code: from the EULA

G'day:
This is just to save me typing on Twitter.

Things I dislike: jobsworths

G'day:

Update:
For non-UK-English-speakers, from Wikipedia:

A jobsworth is a person who uses their job description in a deliberately uncooperative way, or who seemingly delights in acting in an obstructive or unhelpful manner.

I started to have a quick look at ColdFusion 10's new ESAPI functions this morning...  I'd give you a link for those, but they don't seem to be categorised in the docs (and I can't annotate the docs accordingly, cos the site is still broken since it was "upgraded" to use the new wiki)... and quickly got deviated onto the bug tracker.

Thank F*** that fell foul of the Adobe Forums moderators

G'day:
I got this in the email this morning:

You have received this email because the content you posted below has been rejected by our moderators.

And what was it that I said to warrant this?

(NSFW content below the fold)

Bad Request

G'day:
Miscellany about 400 (the first two courtesy of Wikipedia's page on the subject):

CFCamp: what am I seeing on Day 2?

G'day:
I'm sitting in the pub in Portumna, having completely my paternal input for the day, and just killing time until it occurs to me what else to do. And drinking Guinness (end of pint one). It will distress my mate Brian - with whom I was discussing this at the pub in London on Thurs - that I truly cannot detect a difference in a pint of Guinness served in London, and one served in Ireland. That said, they're both good.

I've not been doing any interesting coding in the last couple of days, and I am still digesting my last Ruby tutorial, and don't even have anything to complain about (well, OK, I could come up with something, I'm sure, but I'm in a happy mood so will leave that for next week ;-).  What I am is jealous of all the chatter from people reporting on the first day of NCDevCon, and the ongoing chatter about StrangeLoop over in the States. But of course we (in Europe) have our own conference coming up: CFCamp. As I wrote earlier I'm off to it, and I've given you my thoughts on which sessions I'll be attending (probably) on Sunday/Monday.

And now for Day Two...

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

Null coalescing operator for ColdFusion 11

G'day:
I just noticed the ticket I raised with Adobe for adding a null-coalescing operator to ColdFusion has been marked "to fix". Nice one!

I suggested two possible syntaxes: either be like C#  and use ??, or like Groovy (and Railo) as a variation of the ?: operator. Personally I prefer the former, as I think the similarity to the ?: operator isn't there, and it's confusing/misleading to have the same syntax used for two different things.

But for the sake of sideways compatibility, erring towards how Railo have done it might make the most sense.

I'm liking all these wee developer-centric features going into ColdFusion 11. I'm more excited about this stuff than I am about social media and mobile stuff.

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

CFML Suggestion: being able to stipulate passing data by reference

G'day:
I'm just soliciting opinions about a potential feature request here. I'd like to be able to force CFML to pass arguments / parameters by reference rather than by value.

Follow up to "Preventing Adobe from messing with ColdFusion community projects" & the CFHour Podcast reference to same

G'day
Just a quick copy and paste job today. I put this on the comments @ CFHour because it was in direct relation to their coverage of my earlier article "Preventing Adobe from messing with ColdFusion community projects".

My comment was thus:

G'day chaps
Hey, I realise my headline was perhaps slightly inflammatory, but that was just a hook to get people to go "WTF is he on about now?" as are a lot of my "headlines". If you actually *read* what I say about "blame" it was just a reaction to what Ray said, and I wasn't really making too much of a thing out of blaming Adobe for anything.

Ray said "not Adobe's fault that it happened", and my point was that [action X] happened. This impacted [thing Y]. [action X] was due to an action on the part of [entity Z]. That being the case, the way that [thing Y] was impacted by [action X] is the fault of [entity Z], because [Entity Z]'s action caused the problem. Something happened due to Adobe's actions: it's their fault. I didn't suggest they did it wittingly or maliciously, but they *did* do something that caused other people problems.

I did not mean they should not do what they did. I did not mean that relying on the stability of a third party system that makes no promises about stability is not foolhardy.  I was speaking more philosophically than anything else.

And *all* I said on the topic was "Ray's response [...] is a bit unhelpfully dismissive here". Going to to qualify that I thought that was unusual. I said this because he was simply saying "well you shouldn't do that", but the unfortunate truth is there's no other choice *but* to do it that way given the options available. So simply saying ppl shouldn't do it is... *unhelpful*. I'm sure if there were other options, then the ppl would have taken them. For the very reasons Ray cited.

What I might have expected from Adobe was a "oh shit! Sorry about that :-S didn't realise you were doing that [etc]".

Also you seemed to focus a bit too much on what you're inferring I meant (which given the way you reacted, was pretty much a misreading of what I did actually write), without really focusing on what I'd prefer you to have picked up on which is a suggested project to get all the docs onto neutral ground and offer it as an API for all and sundry to use / maintain.  Which I thought was a good result to come from all this? Maybe not. A couple of people have been keen about it anyhow.

Still: no harm done. Good podcast all round.

Anyway... I do get where they were coming from, but I think it was based on an interpretation of things that has been unreasonably conflated, IMO.

I do also think there's a pleasing bit of irony that these third-party ColdFusion documentation projects only exist due to perceived (validly so, historically) shortcomings in Adobe's offering, and then they are undone by... the very thing they're trying to fix. That it happened is not pleasing. But the irony is.

If you haven't listened to the podcast, get over there and do so!

Cheers.

--
Adam

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:

CFCamp: what am I gonna go check out (on Sunday/Monday)

G'day:
So I'm off to CFCamp, thanks to Mike Hnat and the other sponsors who pitched in to get me over there (I've said it already, but I'll say it again, and I'm gonna keep saying it: you guys rock). But what am I gonna go see whilst I'm there?

How sausages are made

G'day:
Today I pulled back the curtain on some of ColdFusion's inner workings... and hastily closed the curtain and declared "nothing to see here. Move along".

Ruby: blocks (recap), proc(edures), lambdas and methods

G'day:
This is a continuation of the article I knocked together a week or so ago, last time I did a Ruby course @ CodeSchool. I've beend ead slack at keeping up with those courses... I meant to do a coupla this weekend, but fiddled around with CF, JSoup and the Adobe ColdFusion docs instead. Oops.

Last time I talked about "blocks" in Ruby, and demonstrated my superficial understanding of them. The course I gleaned that info from also covered procs and lambdas too. So I'll compare that lot today...

ColdFusion 10 docs are under Creative Commons licensing

G'day:
This is just a follow-up to my weekend's article regarding the "archiving" of ColdFusion documentation. At the time I had a query regarding who the CF10 docs are licensed. The CF9 ones are cleared labelled as being under a Creative Commons licence (bottom left of each page), as per this example from the <cfabort> docs page:

Today Frank Jennings from Adobe contacted me, with the following information:

On Twitter:

@dacCfml @cfjedimaster @RussMichaels @Adobe CF10 docs are covered under CC that allows anyone to share with attribution & without resale.
— Frank Jennings (@fermatjen) September 16, 2013

CFML: When to use pound-signs

G'day:
I'm writing this so I can link someone to it. It's just what it says on the wrapper, so won't be of any interest to anyone who already knows this.

I still fairly frequently see people using pound-signs (#) in their CFML code when they don't need to. This also includes code in the CFML docs, which is concerning! Pound-signs seem to be the apostrophe's of the CFML world: people know they exist, and are necessary, but don't necessarily know the (fairly simple) rules, so "if in doubt, pepper them about".

However pound-signs have even more simple rules than apostrophe's. Here are a list of rules:

1. Pound-signs are necessary when there is scope for a CFML expression to be interpreted as a literal string rather than an expression;
2. err...
3. ... that's it.

When can this happen?

Scraps, scrapes and soup

G'day:
Yesterday I noted - fairly "emphatically" - that changes to Adobe's ColdFusion docs site (not the new flash-harry CF10 stuff, the old stuff that they never update) have allegedly broken some community sites like cfquickdocs and CFGloss (the latter is currently redirected to the site's homepage). This seemed to be because the HTML structure (or the URLs? I don't actually know for sure) had changed and these sites relied on scraping the site to get the content for their revised UI for the CF docs. These sites exist because the CF docs site is not particularly user friendly as far as searching and navigation goes. And the URLs are completely unhackable (in that good sense of hackability, eg: "cfabort.html" would be good because one could infer other tags' pages from it; "WSc3ff6d0ea77859461172e0811cbec22c24-7fde.html" is bloody stupid), so whilst the content is OK, finding it can be a challenge sometimes.

Stop Press:

CFQuickDocs is at least partially back up again. The CF8 and CFMX7 docs work: CF9 still doesn't.

Ray pointed out that it's entirely Adobe's prerogative to change their URLs/HTML if they want, and went on to say anyone relying on page scraping for their content need to be aware of the instability of their chosen approach. And, accordingly, if Adobe changed their docs, it's not their fault if other sites break. I would say that given they performed the action that caused the breakage that it is their fault. However - all things being equal - it's perhaps not something they should intrinsically lose sleep over. That's the thing, though: I don't think all things are equal here. These third-party documentation sites are providing a service to the community that works around shortcomings in Adobe's own approach, and accordingly I think they warrant some respect from Adobe. My own case in point is that I need to scrape bug content from the bugbase for my CFBugNotifier process, because there's no other way to get the info. And given Adobe don't see fit to provide notifications when bug status changes, I think I offer a community-useful service here. And if they changed the bugbase mark-up and CFBugNotifier broke, that would be a detriment to their community. And their fault

Another consideration is that the Adobe docs - except the CF9 ones (and formerly the CF10 ones, I found out today: "ColdFusion copyright and trademarks and third-party notices") - are copyrighted. So people aren't really supposed to be copying them for their own use. Which is what page-scraping is doing. This is why my "copy" of the bug-base entries doesn't maintain the actual content, it maintains a hash of the content. That way I can quickly check if anything has changed (if not exactly what has changed). This doesn't infringe Adobe's copyright.

Anyway, whatever. I think I was a little more belligerent about it than I needed to be, but I think also that Ray was a little more dismissive of the broader picture than he needed to be (whilst being technically correct). And this blog article is not about that anyhow (he says, being almost 500 words into it!).

Preventing Adobe from messing with ColdFusion community projects

G'day:
I was chatting to me mate Andrew Myers on Twitter this morning, and he brought this Twitter exchange about - basically - the death of CFQuickDocs at Adobe's hands to my attention:

ColdFusion Builder to Sublime Text 2

G'day:
At work the powers that be have decided we are going to pilot using Sublime Text 2.

Short, Self Contained, Correct (Compilable), Example

G'day:

This is a lazy post, as it's just linking to another article, and a bit of me wittering on. But so be it.

Maybe you read my article ages ago, "Need help? Know how to ask for it". Here's more advice along the same vein.

Peter Boughton (who doesn't appear to exist on social media, damn him!), is one of the most clued-up CFML dudes I know, and is the most helpful person - by far - on the ColdFusion feed on Stack Overflow. Today he was addressing a question on Stack Overflow, and was confounded by example code that didn't compile, thus making it a bit hard to work out what was wrong with it. Yeah, sure, he could wade through it and fix it and then run it, but - really - why should he have to? If you're asking for help, then you should be doing as much of the work as possible to present your problem, and the person helping you should only be doing the bare minimum of wading through your stuff to work out what's wrong with it. They should not be fixing your example code so that it can even run! In most of the help forums we are just volunteers, and we give up our time to help. So it'd be good for people to respect that idea, and minimise the amount of time we need to invest in getting your code working.

And the thing that most people really seem to not get is the code needs to fulfill the following criteria for it to be effective example code:

• Short. Only the stuff that demonstrates the issue. Nothing that is not related to the issue. It's noise, and unhelpful.
• Self-contained. It should be able to be copy and pasted and then executed. it can't have dependencies on other bespoke code, database connections, environmental considerations, etc.
• Correct. Well obviously if one needs help with code there will be some problem with the code somewhere, but it should compile, and there should not be any problems with it that aren't directly related to the "thing" that you can't work out.
• Example. Not just a swag of code copy and pasted from the middle of yer app. An example of the problem. A test case.

That's my summary of the very good doc that Peter pointed the person asking the question to. The doc is here: "The SSCCE: Short, Self Contained, Correct (Compilable), Example". If you ever need to ask for help with code… read and understand that. And as per my earlier article, also read and understand this one: "How To Ask Questions The Smart Way".

And don't waste people's time, when you're expecting them to help you.

Righto.

--
Adam

CFCamp 2013

G'day:
Yesterday Michael Hnat, organiser of CFCamp dropped me a line, and made me an offer I could not refuse...

"What you didn't know about CFML", eh?

G'day:
A few weeks back the existence of a document / flyer / thingey entitled "What you didn't know about CFML". A lot of people sent Twitter messages announcing its existence, other people (sometimes the same people) had various 140-char-long observations to make about it. I think conceptually it's a good idea (-ish), but it could do with some polish. Here are my thoughts on it...

"ColdFusion (CFML) is an application server and software development framework..."

Well ColdFusion might be those things, but CFML isn't. CFML is - and we all know this - is the language ColdFusion - and Railo, OpenBD (kinda) - processes/serves/uses. The doc should get its terminology right here.

The original wording - which doesn't include "CFML" - must've come from Adobe: if one googles "ColdFusion is an application server and software development framework", there are plenty of matches for that exact paragraph used on the flyer. Interestingly (?) I cannot find the text on Adobe's own website though. I guess their description has moved on, they now say:

Adobe® ColdFusion® application server enables developers to rapidly build, deploy, and maintain Java™–EE applications for the enterprise.

That said, I think the description is fine, other than the misuse of "CFML".

Myth: No One Uses CFM Any More

There's some supposed metrics here: 12000+ companies, 778000+ developers etc using CFML. But there's no references to corroborate these figures, so they're a bit empty. Down the bottom there are some reference sites which I guess are used for some/all of the figured cited (each figure should have  a reference), one of which is trends.builtwith.com. This actually claims to have well over 200000 sites using ColdFusion, so that might've been a more impressive figure to use.

Prelude to a storm

G'day
I started doing some research for this evening's blog article just now. It's relating to that "What you didn't know about CFML" thing that did the rounds last week, and the Adobe ColdFusion Evangelism Kit. After one minute of research I'm already fucked off.

CFML: Way to make me feel thick, Sean... by explaining <cfparam> to me

G'day:
OK, it's not about <cfparam>, but relating to its CFScript-ready chum: param.

Yesterday I wittered on about things I don't like in CFScript, and one example I used of "how not to do it" was the <cfparam> tag's CFScript equivalent, which seemed to be just "<cfparam> without the '<cf' and '>'":

<cfparam name="foo" default="bar" type="regex" pattern="[a-z]+">

Becomes:

param name="foo" default="bar" type="regex" pattern="[a-z]+";

Sean quickly pointed out that that is unnecessarily verbose and disagreeably ugly, but the unnecessary part is because... actually it's not necessary. Because one doesn't need to be so verbose with param. These all work:

param favouriteNumber;
param favouriteNumber=3.1415;
param numeric favouriteNumber=1.1414;

That is much better syntax. It doesn't match anything else in CFML that I'm aware of, but it's quite neat so I'll forgive that.

I had a look around last night, and I could neither find reference to this in the docs, and only actually one place that mentioned param at all, which was the "what's supported in CFScript" page of the docs. However looking again this morning, I've spotted this page too: "Tags" (the irony being that the info about a non-tag is on a page entitled "tags" is not lost on me). Adobe really need to lift their game when it comes to documenting CFScript: it is not longer a second-class citizen when it comes to CFML, yet it's still treated that way in the docs. The <cfparam> page should detail the script equivalent, and each CFScript statement / keyword / construct should have its own separate page (again, with a link across to the tag equivalent).

Things I don't like about CFScript

G'day:
This is a lunch-time article so I gotta be quick.

Now don't let the title put you off... I love CFScript and that's what most of my code is written in. I think tags only have a place in files in which one is interacting with text, other than that, one's code should always be in script. However some of the ways things have been shoe-horned into script make me shudder slightly. Or a lot.

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.

</cfform>

G'day:
This is gonna be quick as I'm a) hungover (yeah... 10pm and I'm still hungover from y/day!); b) had a few medicinal beers to try to deal with (a); c) absolutely nackered, and want to just vegetate and watch a DVD.

I want to actively participate in the demise of <cfform>, <cflayout>, <cfajax> and the like as "a thing" that CFML developers might accidentally use.

CFML: cfcontent in CFScript

G'day:
As per my earlier article about a <cfqueryparam> enhancement I raised, which Adobe have put in the pipeline to be fixed, here's another one which could use some votes to get re-opened and fixed:

No equivalent in cfscript for cfcontent

There is currently no support for cfcontent in cfscript can we have it please.

This is ticket 3133316. It's an easy obvious thing that should be implemented in CFScript. I haven't needed this thing every single day, obviously, but I have needed to recode files on occasion when I find I do need to use <cfcontent> in an otherwise CFScript-only file.

It's currently marked as Closed / NotEnoughTime, but I'm sure if enough people got behind it, it can be reopened and dealt with.

I don't mean to attempt any ballot stuffing, so don't just go vote for it because I asked you to. But if it's the sort of thing you have had a need for, or think should be in CFScript as a matter of course, please add your vote.

Cheers.

--
Adam

Ruby: third tutorial (part 1 of tbc)

G'day:
I first encountered Code School a few months back when Ray pointed out that they were having a free weekend. Having taken advantage of the freeness and being satisfied with the quality of their content (if not their delivery, in places), I signed up for a paid-for account. And - as is often the way with these things - did not touch it again. That was a waste of money! Anyway, I can't afford to be throwing money away, so I forced myself to sit at the computer last weekend and work through another course: this time "Ruby Bits Part 2". I'd enjoyed the first two Ruby courses I'd done, and intend to complete the entire Ruby track: then courses in all. So here are my CF-developer-centric thoughts on this third course.

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