Products

Matt Riley, one of our Sr. Engineers at Amkor has just released his first open source project, dubbed the Deployment Server. It's a ColdFusion application (Mach-II 1.5, ColdSpring, EXT 2.0, Java SE 6, Ant 1.7.0, SVN, SQL Server) that's designed to make deploying applications to various server environments simple, auditable, and secure.

We have a very rigorous SDLC at Amkor, and an even more rigorous internal and external audit. As part of that, it's important that we have a clear segregation of duties between developers, QA, approvers, and those that can promote code. In order to make our lives easier, Matt's created an application that provides a security layer around SVN and ANT that allows our operations group (or anyone else defined in the security policies) to specify which builds/tags are to be deployed, and to which server(s).

The application is highly configurable, but because of that, it's not just something you can download and run out of the box - it has to be customized/configured to meet the needs of your particular environment and process. For more information, or to download, check it out on the RIAForge website.

Any and all feedback is welcome.

I'm sitting in Steve Rittler's CFAjax session right now. Steve's giving some background on Ajax as well as showing the process flow. Basically, "how it works". (x)HTML uses JavaScript to talk to an Ajax object. Ajax object makes an http request to a back end system, in this case ColdFusion. ColdFusion returns xml to the ajax object, which again uses JavaScript to deal with the returned data on the client.

Besides CFAJax, there's also ajaxCFC (by Rob Gonda). It uses a slightly different approach. There are also several non-CF specific Ajax frameworks which can be used.

CFAjax works with CF 6.0 and above. Requires JavaScript. The client must also support the XMLHttp object. CFAjax can return Structs, Query's and Arrays in addition to XML.

Steve's moving into some simple examples now. It's a speaker search where you start typing a last name in a form field and Ajax is used to send the info as you type, updating the form field with possible matches. This is basically the way Google Suggest works.

Cross browser support in Ajax can be really difficult. One of the big issues Steve faced is the way most Ajax libraries require you to embed all sorts of HTML within your JavaScript. It's verbose at best. It requires DOM manipulation, which is also a huge pain for cross browser support. His solution is to use "templates". He cautions this isn't for everyone, but in their case, it works well and has a lot of real world deployments.

Pros of the templating system include returning HTML - there's no hard coded DOM work. It's also, in Steve's words "very, very, very easy". The cons are that it feels a bit dirty, and may rub purists the wrong way. Again, there's a cost benefits analysis to be done. He shows the simple example again, this time using the templating system.

Steve's mentioning upcoming Ajax trends include Ajax/Flex integration (they actually complement each other) as well as mobile Ajax.

Lots and lots of "how do I do..." questions coming from the audience. There's obviously a lot of interest in this topic. Steve's doing a good job of answering them. This presentation could definitely span multiple sessions.

Steve looks to be wrapping up with an example of how to integrate CFAjax within the Mach-II framework. It's very similar in ModelGlue as well. He's showing the demonstration from within an application his company created called RecruitWeb. It's a pretty slick application for use by athletic recruiting departments. The application is completely written in ColdFusion using Mach-II as the framework and AjaxCFC. If you are interested in the mechanics of the integration, I believe Steve is making the techniques available on his company's website, I'm sure he'd be glad to give a fuller explanation.

There's a new ColdFusion resource in town. Today marked the official launch of cfPetMarket, a site based on the CF Petmarket reference application. The site's purpose is to showcase various methodologies and frameworks for building ColdFusion applications, and it does an excellent job to be sure.

What's really cool about the site is that it's already populated with versions of the reference application built in most of the major ColdFusion frameworks/methodologies. This is useful as both a comparison and a learning tool.

The site was developed by Simon Horwith and launched in conjunction with a special focus edition of the ColdFusion Developers Journal focused on frameworks and methodologies.

I didn't notice much chatter around the CF community concerning Matt Woodward's announcement, so I thought I'd mention it here as well. It appears as though the Mach-II 1.1.0 codebase has been frozen. As per Matt's announcement, updated documentation and sample applications are still in the works. Getting the codebase frozen is a big step in getting the 1.1.0 release out the door.

Sean Corfield has a timely post on his blog discussing several posts around the ColdFusion blogosphere related to when an application might be to small to bother with a framework.

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.

Adam Crump, one of the guys on my team has released a Dreamweaver MX extension he created called CFC Bean:

"CFC Bean is a command extension to generate a java style Bean implemented as a ColdFusion MX Component. You simply add the properties required for your bean, and CFC Bean will generate an init method, get and set methods for each property, and if selected getInstance, and setInstance methods. CFC Bean is very useful for creating beans for use with the MachII framework and bean work in general."

We've been using CFC Bean here for a few months now, and it's saved us a ton of time in the creation of our Mach-II beans.

If you don't use Dreamweaver, there is also a web based bean generator with similar functionality:

Jonathan Block's JavaScript bean generator

And a Homesite version by Christopher Bradford here:

Christopher Bradford's Bean VTM

Adam Crump and I are heading to San Diego next Tuesday (5/4) to visit the SDCFUG. Sean Corfield, Macromedia's Director of Architecture is giving a presentation on the use of Mach-II at Macromedia. We're particularly interested in what Sean has to say as we've recently adopted the Mach-II framework for CF Development within our company.