Andrew's ramblings

Another ColdFusion 10 WishList

Tags: Coldfusion

Following on from 10 Things ColdFusion 10 Really NEEDS from Jason Delmore, I thought I would compile what I would love to see in ColdFusion 10. And although everything in Jason's list is needed as an upgrade, my additional things focus on more of the language itself.

Even after playing with ColdFusion 9, it seems to be really unfinished in my eyes. And that's not because of the extra features, but because of the older features. So my wish list is to simply get back the roots and make the product a little more polished with the features that are already in there, and enhance it to make it a better more RAD product.

Object Orientated

Right now this has got to be the most important thing to ColdFusion, and this sort of ties into my next request. ColdFusion is built on top of an OO platform or language, which ever you wish to call it and it has never leveraged off this fact. In the past this may have been a good thing, but it is now time to move away from just a tag based syntax. The new cfscript is a good start in this direction, but it fails to deliver the full OO experience.

This new enhancement will become evident in some of my other wish lists.

Leverage of Java more

We all know that Java is the underlying Engine for ColdFusion, however we don't get the opportunity to mix and match as easily as we should. The new cfscript gave us the ability to import cfc, as well as persistent CFC's into a page, component that we would not have to provide the fully qualified path to the object.

What would have been nice is if we could have done this with Java, for example. Lets say we wish to do some things with the date that ColdFusion currently doesn't offer. We could always encourage Adobe to get it added, but the best and most simplest way would be to just import the Java package to begin with.

That is just an example, the Date is actually deprecated but it highlights how easy it is to leverage of what we have already and expand the language without creating new tags and functions for more functionality.

ColdFusion and Spring

ColdFusion also needs to get into the swing of the future here as well, and although the current framework ColdSpring has done a fantastic job. It is limited by doing all this after the code has been compiled and is done at runtime in most cases.

Now the performance of ColdSpring isn't something I have looked into, as most of the projects I have used it for it seems to be very quick and happy.

However, we really need to be able to have this in the Application as being under the hood. So that we can just do something like this in our code.

UserService userService;

And the getters and setters would be just implied to be there.

CFScript

Although ColdFusion 9 has introduced what we have been wanting for a long time, it is not fully ECMA compliant. And the current implementation just makes it feel so unfinished, if you are used to writing ECMA script, cfscript is going to feel like you are writing very sluggish code.

The other most important enhancement that cfscript requires is closures, coupled with OO and closures cfscript could, no I'll make that it can make the language more RAD than it currently is.

CF-ORM

Now although this is new, it also feels to be unfinished as well. I am not really complaining on this new feature, it is currently very bug ridden and hopefully as of updater 1 these will all be addressed.

However CF-ORM really needs to adopt an OO approach, and coupled with the cfscript closure enhancement it will end up making writing some things like HQL queries easier. Currently if you want to write conditional based HQL you are forced to write 10 times more code than you really need. This is not what I call RAD.

Also by making the language more OO aware, Adobe would not be writing more tags / functions, to do what is already part of hibernate. For example.

myEntity.load();

or even

myEntity.save()

Instead of wasting precious resources and reinventing the wheel so to speak, Adobe chose to incorporate the language in a more ColdFusion way of doing this. In my view I think they fully underestimate their users on this one.

MVC Pattern incorporated under the hood.

The biggest problem with ColdFusion as it moves forward, is it needs to get away from the concept of loose coupled pages. Now this is maybe the most hardest feature to add, but I am sure that a switch or flag in the Administrator would be enough to make it backward compatible.

The biggest and hardest part of any developer with ColdFusion is keeping our applications secure, and ColdFusion promotes bad code in its current form. By adopting a more MVC approach, we start to get rid of these bad coding practices and help lock pages down that should be locked down.

In the days when ColdFusion began this was not a bad concept, but in today's market it is almost imperative that ColdFusion look at adopting this pattern.

Overhaul CFDocument

I am going to agree with Jason on this one, as with most of his I think this one is more important. In my job we use this a fair bit on generating PDF's, however I found that the bugs and things that you expect are well too many to list here. But the number one problem in CFDocuments that got me, was when I reported a bug / Enhancement that would stop us from wasting paper.

Currently CFDocument when it creates TOC's, the headers that you setup have to be on a separate page, this is not bad if the header is a chapter. However if you want to write sub headings for the chapter, these then become new pages in the document. This has got to be the most stupidest thing I have ever seen Adobe decline to fix. In today's world we need to reduce the amount of waste we produce, and if we end up creating 15 extra pages than we should for one document then it means 15 extra wasted pages for no reason.

And a company the size of Adobe should be more vigilant on these type of bugs and E/R's

Replace JRun

Again I would have to agree with this, JRun was marked as having an End of Life. That means that although Adobe are still selling the product, the only ever support it is going to get is with the additional features that ColdFusion might ever need from it.

Every developer knows that if you are not going to maintain a product, then the life of that product is essentially dead. However I recall having a debate with the ColdFusion product manager on this one, as far as we are concerned as developers it might be ok for the likes of ColdFusion. But what if we want to use the multi-server version, and deploy other Java applications on to this?

We can't because the Application Servers of today have moved well and truely passed what JRun supports these days, that means that a developer has to make a decision as to if I deploy this as a Multi-Server what is the likely hood of me adding other Java Servelets to the Application Server to integrate with ColdFusion.

So again I am with Jason, if the product is technically a dead and buried product there is no reason anymore to continue with something that can't even keep up with today's applications.

Make a free Edition

As with jason I fully agree, and have blogged about this in may of my posts in the past. The best way ColdFusion can move forward is that the CFML engine is segregated from the features of the Application. Adobe could then sell ColdFusion as a bundle, with all the features and/or they could sell just the features a user may want.

That might seem strange, but with Railo and openBD out there having to write code to keep up with the CFML by Adobe. It would make better sense that Adobe either handballed the engine to these two or the 3 of them agreed to join forces and develop a single CFML engine.

Adobe would benefit more from this, than they currently do. Because they are then opening up a new user base that their product can also be used with, and by having a fully fledged open sourced CFML engine that is capable of being enterprise aware it would become more viable and cost effective to hosting companies as well.

Think of it this way, if you only ever going to be writing CFML then the cost of hosting would be cheap as. And the hosting companies could charge a little extra for the one or two features you may want, or for the full features.

The business model would not only benefit Adobe, but developers and hosting companies would benefit more.

But more importantly, the user base of ColdFusion would increase more. Many larger companies are being swayed by the fact that it is cheaper to develop with Open Source products these days, because there is more that these other solutions offer that Adobe can't. This option would mean that Adobe can be taken a bit more seriously in these areas as well.

And can you imagine it if you could buy the RDS plug-in, and get that support in Railo and openBD!!

Plugin System

This is also apart of the making ColdFusion free as well, but it should be added even if the above never happens. I know we have a CFX way of doing it, but this is another feature that has never been updated since it began its life either.

In other words, I want to write a proprietary set of features the CFX option doesn't cut it. And that's because even though I added this as an E/R back in the days of ColdFusion MX 7, it never went any further than that. But either way we need a way that we can write Java code, and be able to incorporate this into a plug-in system that is fully interchangeable between the plug-in system and ColdFusion itself.

As it stand now, the CFX option doesn't allow this integration where we could access the scopes in ColdFusion or other things in ColdFusion.

But if it was a plug-in based way, and conformed to a standard that Railo and openBD uses. We know that we can write a plugin that can be used across all three engines.

In Conclusion

There are many of you that may have different views than me, and like Jason I too see what he wishes that ColdFusion should have and I have added what I would also like to see ColdFusion adopt in the next version.

The most important thing is that ColdFusion is alive, and as a community we are thriving beyond belief and that has to be a good thing. But the most important thing is that Adobe needs to take ColdFusion in a new direction that can flourish even more. And I believe that what I have suggested is making that direction, more appealing to far more developers than it can in its current state.