It's official - the Adobe acquisition of Macromedia has been finalized and our beloved ColdFusion has a new home. Is this a bad thing? No, not at all.

There was a lot of talk within the community about how this may adversely effect the server, but talk is cheap and, in this case, also very premature.

In order to give the community a breath of relief and put a stop to much of the hypothesizing, I interviewed Dave Mendels, senior vice president of Adobe's new Enterprise and Developer Solutions Business Unit, about Adobe's plans for the ColdFusion Application Server. Rest assured, ColdFusion's future does look bright - I for one am very excited about the possibilities for new features that lie in store for CF, not just as a developer but as a business person as well. With the right product integration, Adobe could place ColdFusion at the heart of mission-critical applications within large enterprises everywhere where Adobe products are in use. I say this mainly because, after looking at the server product offerings that Adobe had prior to the acquisition, it's clear that CF could well become poised at the center of out-of-the-box offerings in the areas of digital document creation, document management, and workflow. This would never replace ColdFusion's "traditional" role as a Web application development platform that offers rapid development and makes it easy to put databases on the Web, but it would certainly augment those features nicely. You can read my interview with Dave in this month's issue of CFDJ.

While I'm on the subject, I'd like to talk about this idea of ColdFusion's "traditional role" as a Web application development platform that offers rapid development and makes it easy to put databases on the Web. In last month's editorial, I spoke about the changing state of the Web (http://coldfusion.sys-con.com/read/154216.htm) and announced that CFDJ will be including more articles that focus on the use of technologies such as AJAX and Flex in order to take our ColdFusion applications, and the experiences that we as developers provide to our customers, to a whole new level. Plans are in the works to begin including Flex 2.0 articles in the near future, but in the meantime you may have noticed the inclusion of more AJAX articles in recent issues. Next month's issue includes an article by Joe Danziger on building an AJAX shopping cart for your CF applications - I recommend trying it for yourself (it's a lot easier than you might think). I welcome all of our readers to provide feedback about these articles and the addition of content focused more on AJAX and Flex for CF developers by e-mailing me at simon@horwith.com.

What I didn't talk about in last month's editorial was how this changing state of the Web will impact the role that ColdFusion plays in your "Web 2.0" applications. Let's face it: ColdFusion could be described as a tool for rapidly putting database data on the Web. This is a simple description and certainly not all-encompassing given what the server is capable of, but it's also not inaccurate. That is its most popular and most frequently used functionality. ColdFusion is not, but any means, a presentation server… yet the vast majority of ColdFusion applications have HTML front ends and this HTML is typically generated on the server. Don't get me wrong, there's nothing wrong with this, but it's not necessarily the case when we're talking about next-generation applications. In the case of AJAX yes, ColdFusion still generates the client code. In the case of Flex/Flash, this is not the case - the client application is either a precompiled SWF or a SWF that's been generated by a Flex server (unlike CF, Flex is a presentation server). Getting back to what Web 2.0 is all about, smart clients are just that: "smart." Whether ColdFusion generates the code for that client or not, the role that ColdFusion plays in these applications has changed. No longer does ColdFusion have to assume the responsibility of not only fetching data but also presenting the data (as well as the interfaces for managing this information). Smart clients need one thing from ColdFusion - data. Of course, sometimes applications do more than simple CRUD operations, so I'll refine my definition of this new role.

In next-generation Web applications, ColdFusion, and ColdFusion applications, will play the part of "service provider." Clients will never be able to perform complex server-side tasks like manipulating enterprise data and other resources, but they are smart enough, with ColdFusion providing the services they need, to give users a much better experience leveraging the enterprise resources that your ColdFusion code provides services for. While ColdFusion's traditional role of exposing services for working with database data may still be the same in the next iteration of the Web, it's now more focused only on that task. Persistence, the presentation of data, and playing the part of controller when users require different views are no longer going to be the responsibility of ColdFusion in these next-generation applications.

What does this mean for ColdFusion developers? Nothing is different for those developers still just working with HTML interfaces, but for the rest of us it means changing the way we architect our ColdFusion applications. There's no reason why you can't have both an HTML interface and Flex or AJAX interface to the same application, but in order to do this, especially without replicating effort, means implementing a sound architecture. By moving all business logic, data access, and manipulation functionality into ColdFusion Components, and developing applications using best practices in order to prevent your business logic from being dependent on any one specific client (including itself) for persistence, the same code can be leveraged by AJAX, Flex, Flash, Sparkle, Java, ColdFusion pages that generate HTML interfaces, and any other client on the Web. So you see, smart clients don't just require learning Flex or AJAX, they also require you to change the way you build your ColdFusion applications. Let me rephrase that, they encourage, even require, developers to encapsulate and modularize their ColdFusion application building blocks…and this is a great thing.

In the months ahead, keep an eye out for news on the Adobe front as well as more articles about the changing Web. Both of these changes in our culture are for the better, and at ColdFusion Developer's Journal our aim is to help developers take advantage of these useful new resources.