The World's Favorite Open Source GPL J2EE CFML Runtime Engine

BlueDragon Developer's Journal

Subscribe to BlueDragon Developer's Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get BlueDragon Developer's Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Open BlueDragon Authors: Reuven Cohen, Elizabeth White, Michael Sheehan, John Gauntt, Salvatore Genovese

Related Topics: Open BlueDragon Developer's Journal, ColdFusion on Ulitzer

BlueDragon: Article

It's Time To Standardize CFML

"ColdFusion, BlueDragon, Coral Web Builder, IgniteFusion, Railo..."

ColdFusion, BlueDragon, Coral Web Builder, IgniteFusion, and Railo. All are CFML engines, but none of them support the same implementation of CFML as each other. This, in the long run, is not a good thing.

Up front, I am not opposed to other CFML engines. Yes, I use only ColdFusion in production environments, but I have played around a with BlueDragon and other CFML engines. That being said, I feel that we need a common CFML base from which to base all CFML engines; a CFML core, if you will.

One thing I have noticed is that you have tags that do not behave the same across platforms. A prime example of this is CFDOCUMENT on ColdFusion vs. BlueDragon. Blue Dragon will create raster documents, but not FlashPaper, and ColdFusion will perform inversely. This is not a good thing. I understand the marketing pitch of "Our tag does something theirs doesn't.", but this is nuts. As developers, we want a tag to perform the same no matter which platform is the deployment target.

We are at a point in the life of CFML, as a language, where there needs to be some sort of standardization to the CFML language. How will a CFDOCUMENT tag act? How will a CFCOMPONENT tag act? We should be at a point where CFCOMPONENT will work the same no matter what platform you are on. Most developers don't want to have to consider: "Will this run on ColdFusion AND BlueDragon?". We want it to just work.

A harmonious approach would be to say "Let's have a conference and sort through it." Fact of the matter is, that's just not going to happen.

Adobe is the 800 lb. gorilla in the room on this issue. As much as we would like to laud New Atlanta for what they've done with their CFML engine, Adobe is still, and will continue to be, the market leader. When people think CFML, they think ColdFusion; and when they think ColdFusion, they think Adobe (or Macromedia, or Allaire, but that's another topic).

What does this mean for standardization? From a business standpoint, it means that all other CFML engines need to, at least, fully support the market leader's implementation. Beyond that, the "unofficial" CFML engines can add new functionality (i.e. CFTHREAD). If it's deemed viable, then they can see it assimilated into ColdFusion (as has happened with CFTHREAD).

Sure, other CFML engines say that they support 90% + of the ColdFusion implementation of CFML tags and functions. What about that other percentage that isn't supported? It's true with any CFML engine that isn't "the official product": If you don't support all of Adobe's functionality, you are not compatible with ColdFusion. Plain and simple. Partial support is not an option here. In standards, it's an all or nothing game.

Is Adobe going to open up CFML as language? Why should they give away the market? It's bad business to do so. All they can do is innovate, and hope that other CFML engine vendors can keep up.

Under Allaire, Macromedia, and now Adobe, ColdFusion and CFML have flourished. They have been good stewards of the CFML language. I see no reason to let them not lead the way on CFML standards going forward.

Until the other CFML engines come in line, there is still going to be a choice: "What CFML engine am I developing for?" Most likely, the answer is going to be ColdFusion. However, if any of the other CFML engines can fully support Adobe's CFML implementation, that question becomes much more complicated. We are not to that point yet. One day, however, we may be at that point where the decision as to which platform to develop on becomes a bit more difficult to answer.

More Stories By Andrew Powell

Andrew Powell has been architecting and developing Web applications for over 10 years using ColdFusion, Java, ASP.NET and ASP. His background includes experience running IT Departments for firms in the executive search and aviation consulting fields. You can read his blog on everything ColdFusion, Java, Flex & AJAX at

Comments (6) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
Vloten 04/06/07 06:14:47 AM EDT

I love CFML and defining standards would only
help it from the "proprietary" mentality.
The fact that in all of Ben Fortas books there
is no mention of BlueDragon, IgniteFusion
or Coral, speaks volumes.
I believe if the CFML engines worked together
the could grow the user base rather than scare
people with compatibility issues and bickering.
The new options (including freeware) for CFML
have given new life to the language.

Fred B 03/30/07 10:05:06 AM EDT

When Smith goes open-source it will become a good choice of engine by which to define a CFML core - because being open-source it will be community-driven.

James 03/05/07 03:36:32 PM EST

Andrew, could you expand upon your comment "If a standard is ever developed, then the ability to conform to it is made that much easier by a community of developers."

I see open source initiatives being more about the addition of functionality, and the patching of existing issues. The one thing I don't think of is standards (although, that's not always the case, it's not something that I think of immediately, or even secondarily).

Good article, BTW.

charlie arehart 03/04/07 05:30:27 PM EST

Andy, this is a very old argument that's been hashed out many times, as I can attest from my time New Atlanta (2003-2006). The conclusion was always pretty much the same as you've laid out: only Adobe can forge a standard, and there's no real motivation for them to do so. Now, I have to challenge some of your conclusions about where that leaves us.

You assert that it's the job of the other vendors to "toe the line" and follow the de facto standard (CFMX), and you're not alone in that sentiment, but let's clarify that this is not always as easy as it seems.

For one thing, there is no well-defined spec. You say "CFCs should all work the same", but people have been discovering new and undocumented things about CFCs since their creation. And only sometimes are those documented (or resolved, if a problem) in a new release.

And this lack of complete specification of functionality goes for pretty much every tag and function. I can attest to it because I saw it while with New Atlanta. People would present code that "worked in CF" but "failed in BD", but there was no documentation to support the behavior they were using.

Of course, their argument was frequently the one you made: "well, CF makes the standard, others should follow it." And over time (BD is now almost 7 years old), such little kinks have been worked out despite the lack of a "spec".

Indeed, others took things quite differently. When something would fail in BD and they looked at it, they'd as often as not wonder why it ever worked as they coded it in CF. It's understandable that CF would often have to implement backward compatibility that might let code do curious things but still "work" for the sake of keeping the peace with current customers. Still, again, such might not ever be documented.

As for CFDOCUMENT, and BD's not supporting FlashPaper, well, I'll let New Atlanta speak for themselves, but I know while I was there I looked into the prospect of doing it and I couldn't find any publicly exposed API from MM/Adobe for any 3rd party to create FlashPaper. In that case, it just isn't possible for 3rd parties to be in "conformance".

Still, I will conclude with a common refrain i did offer when I was there: people use an alternative engine because it solves some problem. Contrary to popular belief, that problem is *not* always price. It may be that CF doesn't do something they need, or it may be that the alternative implements something before CF does.

Certainly, there are also instances where CF does something that the alternative does not. In that case, it's simply up to the folks choosing the engine to pick that which serves their needs best (or acceptably, if there are many issues to be weighed).

The folks perhaps most ill-effected by the variations are those building software that might be used by folks on the multiple engines. And for them, they may well have to decide which engines are worth their saying they will support. This is no different than a vendor of such code may have to decide in indicating what databases they will support (if the code includes SQL). I'm just trying to share a little perspective.

Again, I'm no longer with New Atlanta (makers of BlueDragon), but I can say (as I did then) that I really think the existence of alternatives has been good for the community. Others have commented the same. Competition breeds innovation, and that's good for everyone. Those of us around since the Allaire days can attest that information about upcoming releases has been far more forthcoming in the past couple of releases. It would seem reasonable to conclude that this too stems from the effect of competition, and Adobe trying to give people ever more reasons to use CF (or to keep them from considering an alternative).

And let me say for the record, since some may wonder if this note "shows my stripes", I am now very happily working with and supporting people using CF as much as (indeed more than) BD or Railo (the only other two I've really looked at closely). I'm very happy to see what's coming in Scorpio. It's exciting times for CFML developers, regardless of their engine. I may be a bit more pragmatic (even "ecumenical") on this matter than the average CFer. It only comes from experience on both sides of the fence. Though I now rest squarely atop it, I've played in both yards.

To stretch the analogy, I've even spent a lot of time in the homes of both the neighbors and know them a lot more than many in the neighborhood. The seeming strife that must exist between them isn't at all what most would think. Still, each has their own mouths to feed and will be protective.

And we on the outside looking in are certainly entitled to our opinions. I guess the question is whether we live in a planned community where each house is expected to be the same. I've lived in each kind of community, and they have their pros and cons. But there I go waffling again! :-) I'll let others carry on the debate.

Andrew Powell 03/03/07 05:06:13 PM EST

I think it can only bring good things. If a standard is ever developed, then the ability to conform to it is made that much easier by a community of developers.

Randy Johnson 03/03/07 12:17:30 PM EST


Interesting article. How do you think the smith project opening up their cf server to open source is going to play into all of this?