Derek Perez has a bit of a dilemma, and its one I am rather familiar with. His problem is that he likes to use CFCs, and has been using them for quite a while now. Actually, that's not really the problem. Really, his dilemma is trying to convince other experienced ColdFusion developers that they are not simply an over-complicated alternative to things such as custom tags and includes, and actually present any opportunities not really visible when using these more primitive forms of encapsulation. Things work just fine the way they are, so why ruin a good thing, right?

I have also been faced with this very problem in the past, and it can be incredibly frustrating. Generally, there can be all sorts of reasons not to use any new functionality, but usually there is one you can always rely on to deliver: "It ain't broke, so why fix it?"

But I digress.

When entering these sorts of discussions, I want to talk about things like encapsulation, extensibility, polymorphism, inheritance, and separation of concerns. You know, object oriented programming, concepts that many other modern languages have seemed to embrace with relish. However, while I hold these values close to my little programmer's heart, it is not the same for the others who have not acquainted them selves with OOP. These words do not hold the same (if any) meaning to them, and simply make the whole endeavor seem like a lot of work for nothing but something that sounds bloated and academic.

I know this happens quite a bit, and many times everyone just agrees to disagree and move on without ever really resolving it. However, I also know a lot of people have also been able to bridge this great divide and moved their development team forward into the modern age.

If you use CFCs as a matter of course, do you know why you use them? Can you articulate those reasons?

Go give Derek a hand.

There has been a lot more attention paid to testing CFCs this year at CFUnited, and cfcUnit is right there at the front when discussing unit testing one's CFML. Perhaps the biggest proponent of unit testing has been John Paul Ashenfelter and his talks on Agile Development and Testing ColdFusion. Additionally, I have seen demos of unit testing by Chris Scott when showing off different functionality of the ColdSpring framework.

A side effect of this attention has been that there will soon be a new Ant task written by John Paul that will allow cfcUnit to be run as a part of an automated build, but it could also be run from within Eclipse just as other unit testing frameworks do now.

Frameworks are a lot of fun to build. Over the last month I have been working on a framework for building ColdFusion service layers. I built it with the intension of making it available locally and remotely using Flash Remoting and web services. I have decided to call this framework Tartan.

Tartan is a command-driven service framework for ColdFusion. It was built to help produce the service layer within a larger application architecture which relies on strict separation or layering of functionality.

All access to the underlying business logic is controlled by public services which are available locally as CFCs and remotly via Flash Remoting and SOAP web services. A service can be composed of any number of commands, each of which implements a discreet operation within the application. These contain the core logic for the application. Commands can communicate with databases via DAOs, manipulate values received from the client, execute other commands and even communicate with services available on other remote servers.

At the center of Tartan are 6 core classes: RemoteService, LocalService, Command, DAO, ValueObject and ExceptionHandler. They provide most of the functionality of the framework, and must be extended by the application developer.

Although I am still working on proper documentation, there is some already, and tartan is now available for download as a part of the OpenXCF project on SourceForge via CVS. I will make it available as a single download really soon.