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.

At my last work we used FarCry for large portion of the site matrix we had, but for our custom development (ie sort of a mini site within farcry) we simply broke away (totally) and went into our own framework.

That being said you could easily have Mach-II code co-incide with FarCry.

That's pretty much what we did, we took a pseudo Fusebox/Mach-II approach to our applications in Farcry. We included our controller in the included Objects, and then used our tried and true Mach-II coding. It works great, once you figure out how to handle links in Farcry.

Thanks Rob for immortalizing my feeling dirty comment, but it's true. Once you code Mach-II, it's weird to drop CF in a .cfm... it just feels wrong.

I'm sure there'll be some better approaches as our development matures under Farcry, but so far, with the exception of a few gotchas, so good.

I'm curious... how are you able to still code in a Mach-II style while using Farcry as the parent application? Are you writing Mach-II apps and then grabbing them as dmIncludes? Are you still managing the data from within Farcry (using custom types or containers)?

What were bascially doing is creating a fusebox type switch in the included object. From there, we just post back to that template. We adopted a Mach-II approach on our file structure, keeping everything in model/view directories far removed from the FarCry or wroot.

One of the guys on our team has taken it a level beyond that, actually extending the Mach-II framework to his cfcs. He's hoping that he can drop his mini-app (presently in FarCry) directly in Mach-II seamlessly. Whether its geek factor or actually practical, he hasn't decided yet. But we'll keep you posted.

Thanks,

Ray