For one, you can write your form once, and skin it a number of ways with pre-built skins that ship with ColdFusion. If you aren't happy with any of those skins, you can create your own using xsl, either from scratch or by extendiny any of the existing styles. This is where the power comes in and what got me thinking...
Well, it looks like we won't have to do that afterall. Because of the design of the XML forms implementation, we can basically write our own xsl transformations to map cfform validation to qForms! We're just starting to look into what's involved in doing this, but so far, it looks promising. Darryl Lyons over at Mossy Blog notes a similar use, using the XML forms to generate DHTML (in this case, a DHTML tree instead of the built-in Flash/Java tree). Very cool indeed. Stay tuned for more on this as we delve deeper into the project.
This is timely for me because my team was just discussing this the other day. In our case, we've standardized all of our new application development (with one minor exception which I'll discuss shortly) on Mach-II. I could go on and on about all of the reasons we've done this, but it boils down to a few that you've probably seen over and over.
I've been working with CF at the same company since version 1.5, and have had the fortunate/unfortunate experience of watching all of our applications grow, mature, refactor, upgrade, migrate, and ocassionally die - all under ColdFusion. Along the way, my coding style has changed as both I as a developer and CFML as a language matured. When I was the sole coder, I coded how I pleased, and was always adapting my coding style to try new ways of doing things. As time went on, and I was able to add developers to the team, it became obvious pretty quickly that the "cowboy coding" mentality was not going to continue to work.
My perspective on all of this may be different than yours. As I've said, I've been with the same company for 9 years, so I've had a chance to experience first-hand what it means to maintain applications written by several different developers over several versions of the language, over long periods of time. Applications that started off fairly elegant (for their time) became nightmares to maintain as each application was architected differently, the original developer moved on, etc.
I made a decision toward the end of 2003 that all new ColdFusion development in the company would be standardized on Mach-II. We have a pretty ecclectic team, with skills ranging from CF to Java to VB to AS with varying experience with OO. The transitionto OO CF development using Mach-II was not overnight. Along the way, we made some pretty basic mistakes. The point is, though, that we learned from those mistakes and we moved forward. We're still doing that today. However, for all of the initial pain we went through, we would never go back. If you ask anyone on our team how small an application needs to be before we don't do it in Mach-II, the answer you'll get back is that there are no applications that are too small.
Earlier in this post, I said that we are using Mach-II for almost all of our CF development. The exception to that is FarCry. We're currently converting our existng Intranet (a combination of a lot of static content and a handfull of applications) to a FarCry site. Why use FarCry and not roll our own CMS? Simple. I have a limited amount of development hours with which to take on projects. Anything I can get off-the-shelf saves me development time that I can better spend elsewhere. Is FarCry perfect? Nope. But it works well, is fairly extensible, has an active user community, and it's open source. This brings me to part of my point. In FarCry, it's possible to integrate external applications into the CMS through a variety of means. One thing my team found a challenge, though, was that any custom development they had to do in FarCry, they found themselves wanting to use Mach-II for! They've gotten so used to Mach-II that they have a hard time getting away from it. As one of the guys put it, "I feel dirty writing code in a .cfm".
That's enough from me for now. I plan to blog a few more thoughts on this and other framework/standardization issues in the near future as this seems to be a topic to a lot of developers at the moment.