Stake Five

There’s been much rubbing of magic lamps and wishing of wishes over what features we should throw into ColdFusion 8 aka Scorpio. Sean has the roundup of comments from Simon Horwith, Brian Kotek and Brandon Harper. Which will be granted? Only Damon can tell… ;-) Loudmouth that I am, I can’t help but add my own 2 paisa to the debate.

CFML is a simple language. Joe/Jane developer can get up and running building a CF application in a fraction of the time it would take with practically any other technology. At heart, CFML is a language rooted in tags. There’s no need to digest half a dozen reference books to dive into CFML - you can just pick the tags you need and go from there.

Adding new language features to parallel those available elsewhere (Java, Ruby, whatever) does not detract from this power - it adds to it. Your applications can be as simple or as complex as you want them to be. But even when they’re complex, the complexity can be isolated at a layer of abstraction above the actual business logic, because the business logic is still largely composed of simple, powerful tags. The key, of course, is to ensure that the features we add do not mess with CFML’s essential simplicity; if there’s one thing the CF team is paranoid about, this would be it.

But addition of any new feature is tempered by the time we have available to release, and the number of other features in queue. Prioritisation is a hard task, especially when we have you, our vociferous users, to answer to. Some features will make it, and others won’t - you know how the game is played. So you’ll see some new features that will enrich the CF language, allowing more object oriented behaviour and what-not. And you’ll soon see others like CFPRESENTATION and CFPDFFORM, which Jason showed off at CFUNITED, that will continue in the CF tradition of making hard things easy.

Some have asked whether CF should ship a framework to help define how to build applications. I would have to disagree. Each framework brings its own architectural philosophy to the table, and each is valid in its own space. Today we have frameworks that are great for building web applications. But what about frameworks for applications with Flex front ends? What if someone were to build a framework to enable CF as a data integration hub, using all the rich network interfaces that are available? Each of these will have their own specific requirements - no framework is sufficiently generic to address all needs.

CF goes far enough to make things easy, but at the same time stops short of defining how you should build your applications. That little detail, we leave to you…