Some of their proprietary extensions are definitely interesting and useful (onMissingTemplate() for Application.cfc is probably what appeals most to me). However, they also seem to be driving their implementation of the language very much into "Java-Lite" territory with the addition of interfaces and abstract CFCs (and null support). A lot of Java and C++ developers don't seem to be able to figure out abstract classes properly so I really don't think that adding that sort of thing to ColdFusion is a step forward. I really think that the folks clamoring for "more OO" in ColdFusion are a very small minority (albeit very vocal!) and that such things don't address what the vast majority of ColdFusion developers really want from the product.

All that said, choices are good and the more ColdFusion engines out there, the more it validates the use of ColdFusion as a rapid application development system.

Flash Paper is a waste of time, users don't get it, I don't see what it offers over PDF reader. I bet Adobe quickly depart from it, they have two products that do the same thing.

"are a very small minority" I'm not sure who your talking to, but all the developers I speak to want more OO stuff, there is no good reason not to have more OO stuff. If you don't understand it stick to procedural programming.

I think it's good timing it might make Adobe think about the CF8 features when BD release this.

Still, I really don't understand why anyone would use BlueDragon over ColdFusion. There is hardly any cost benefit.

Personally I wouldn't miss XML or Flash forms because creating forms with CSS instead is far more flexible than CF's XML forms and Flash forms take too long to initialise. Wouldn't support for FlashPaper require a license from Adobe? Perhaps New Atlanta thinks there's not enough enthusiasm for Flashpaper? Adding support for jpg and png output is another logical step forward. I bet CF9 or 10 will have it. ;-) BD7 did inspire possible support for cfthread in Scorpio.

Whether anyone prefers BD7 or not I don't think matters as a bit of competition and innovation ultimately benefits the CFML community. Everyone wins, although Adobe may lose a few sales, but then again if Adobe try to stay ahead of BD they will find new customers who were perhaps considering .NET, java and php technologies.

I couldn't care less about flash forms, or flash paper, and I applaud bluedragon for not wasting their time implementing these features.

Now that we have 2 very solid CF engines (BD/CFMX) and one thats damn close (Railo), and even some more on the way (Ignite, and to a lesser extent coral), It might be wise to have an independent board which would dictate a "standard" CF version. The standard CF language would be accepted by anyone who wanted to be in the club, and their tags/functions would have to all input/output the same way.

Now, on top of that each company would be free to build anything they want. Adobe could offer flex/flash/pdf goodness, BD could offer .net integration. Enterprise features and clustering available for more $.

This would be nice for people (myself included) who want to work with some open source stuff, and want it to work on all platforms. Right now, I am working with BD.net, and Railo, and occaisionally CFMX 7. It would be nice if people working on open source projects could stamp a "meets CF8 Standards" on the front so i knew what to expect.

I would say also say to open source CF, but i've already said a lot, and im beginning to stray....

I also wonder why BD has not bothered with flash paper. There is a much wider deployment of flash player than there is of acrobat reader and there is more you can do with it because of the technology behind flash player. Some kind of "display everywhere" technology is critical, and PDF is not quit it. It is close though. Flash has a much larger reach and that is why Adobe should dump acrobat reader/publisher and use flash as the display engine. Good thoughts on this thread all around though.

In most cases there is zero cost benefit to choosing BlueDragon. But, they do offer some features, that in certain situations could blow CF out of the water. And in turn, there are many situations where CF is the better choice.

The BlueDragon.NET version, for example, will save sessions across a restart.

Sean,

I spoke to some New Atlanta folk about Event Gateways, and was given the impression that cfthread / cfjoin can be used to emulate a lot of the Event Gateway functionality. They psuedo-coded a example of a the 'directory watcher' gateway (This is all in my Blog). That aside, I'm not fully convinced.

Now if we enter into the pure speculation realm... ServletExec (New Atlanta's J2EE server product) is just a servlet engine and does not implement the full blown J2EE server spec. I thought that the Event Gateways relied on functionality beyond servlet engines, which is why it may be harder to implement such features for BlueDragon than it would be for ColdFusion (which is built on JRun which is a fully featured J2EE Server).

speculation off

Virtually all office and home computers can read PDFs as the top 10 PC vendors ship Acrobat reader pre-installed and anyone who doesn't have it will want to install it sooner or later as there are over 200 million PDF documents on the web according to Adobe, all indexed by Google etc. (I just checked Google and it actually claims 1 billion PDF docs!) How many flashpaper files are there? A handful by comparason.

PDF is used in large organisations (I haven't encountered any widely using Flashpaper) and Office 2007 has a PDF export option (as a free download from Microsoft). I don't believe it supports flashpaper.

PDF is here to stay, it's been going for 15 years and everyone knows what Acrobat/PDF is. I can't say the same for flashpaper. I'm sure it has its place but it's no way a "must have" feature like PDF is for CFML engines.

And if you're viewing an embedded flashpaper document, how do you save it to disk? There's no save button! You'd have to 'view source' and use a file manager to dl and save it. The few sales that New Atlanta may lose by not supporting Flashpaper are probably offset by those who find png/jpg output a solution for their needs. For example, thumbnailing web sites/pages.

Suppose you wanted to offer your customers the option of dynamically creating a certificate of merit from your website that they could save/print/email, etc. PDF could do this, but it might take you (as in my case) over a year to get all the bugs worked out do to browser and PDF viewer incompatabilities. When dealing with large corporations, you can't just say to them, "update your Acrobat Reader (or flash player) to the latest version. If they are your client, you want it to work for them with as little error as possible. Flashpaper gives you that ability.

Two of my biggest clients have a locked down desktop so users can't freely upgrade apps and plugins. That's why I output PDF because the requirement caters for really old computers (2000+) as opposed to just old computers (2002+). I have never come across an end-user compatability issue because of a CF generated PDF using either embedded or linked techniques.

From a cafe in St. Lucia, South Africa...

Jan

Saying it "isn't developed for years" is just plain laughable - after the big Flex integration release last summer and all the stuff that's being done in Scorpio right now (a few parts of which have been sneaked at various conference).

sorry i was inaccurate about gateways. i talked about cfml gateways, and yes there's only page called Developing event gateway listener CFCs and nothing about problems i have with them like not responding gateway without anything in error log, cfabort ...

but i can't agree with you that it is developed - for me only difference between cf6 and cf7 are problematic gateways (using, debugging them) and killed java class reloading. both versions use too old versions of quite common java libraries and things like jasperreports, hibernate and many others simply can't be used with cf or you have to rename java packages. so that's my view of coldfusion development ...

and one thing i really don't understand - why i can't use standard j2ee datasource in servers other then jrun when java has standard way to do it ? that's slyness

Jan