The story thus far

The truth is that it was possible to build ColdFusion-powered Flex applications in the Flex 1.x era. Flex applications ran in the Flash Player, and the player knew how to make HTTP calls, SOAP requests, and AMF requests. ColdFusion knows how to respond to all three of these (responding to HTTP is what ColdFusion primarily does, and ColdFusion Components can be accessed via SOAP and AMF). As such, a Flex application could be powered by back-end ColdFusion by default. Since both Flex and ColdFusion talk the same underlying bits, they could be used together. And indeed, some ColdFusion developers (myself included) have built and deployed ColdFusion-powered Flex 1.x applications.

But while many ColdFusion developers tinkered with Flex, far fewer have actually built and deployed these applications. There are several key reasons for this:

• The biggest obstacle was price. Compared to the cost of ColdFusion itself, and taking into account the typical ColdFusion applications and the budgets associated with these, Flex pricing was a real barrier to product adoption.
• Deployment was more complex than most ColdFusion developers would like. Most ColdFusion developers shy away from J2EE deployment (most ColdFusion Enterprise deployments are actually deployed standalone instead of on top of a J2EE server).  This is primarily a simplicity issue. There is something very compelling about running an installer and clicking Next a bunch of times and just knowing that everything will work. And Flex 1.x required a J2EE deployment.
• The integration was poor. As already explained, ColdFusion and Flex 1.x could work together, but the integration was not particularly clean or intuitive. In fact, ColdFusion had no real knowledge of Flex 1.x, and Flex 1.x knew nothing about ColdFusion. There was no special integration or interaction between the two.

But now all of this has changed.

Page 3 of 6

Previous Page

Next Page