Best Served Cold

Why do you use CFCs?

Wed, 11 Apr 2007 14:11:00 -0700

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.

cfcUnit Site Unavailable

Tue, 13 Mar 2007 11:36:00 -0700

So, it seems that there was a problem with DNS for the cfcuit.org domain, and the cfcUnit website is currently down. Go ahead and try it, I swear it doesn't work. I checked. Anyhow, I fixed the problem with the registrar, but as with anything involving DNS registars, its just a matter of propagation (read lots of waiting around). Give it a day or so and it should be back up. [1:45pm - Follow up] Well, it seems to be back up. Much more quickly than I expected.

Lots of great ideas

Sat, 10 Mar 2007 23:12:00 -0700

I would like to thank everyone that offered suggestions for what they would like to see in the next version of cfcUnit. Many of these are great ideas, and some will certainly be added to the core framework. They have given me something to focus on and a bit more future food for thought. Something else that is made much clearer is that more documentation, tutorials and examples are needed to get people started more quickly. I will be addressing that. I would also like to remind folks that there is a cfcUnit mailing list (link below). If you have any ideas or questions about how things work, it is a good way of getting some help.

Your thoughts on unit testing

Fri, 02 Mar 2007 01:15:00 -0700

I have spent these last few months working on the next release of cfcUnit 1.2, so it has been on my mind quite a bit. While I add important functionality to the framework like a remote service for Flash Remoting and a rather robust Ant task and fix some long-standing issues, I can't help wonder if there is something else I need to add. So I pose this question to you: What do you want to see in the next release of cfcUnit? If you already using cfcUnit for your unit testing needs, what would could be done to make your experience that much better? If you are not writing unit tests right now, what would it take to change your mind?

You want it, you got it!

Fri, 02 Feb 2007 01:34:47 -0700

Ok, so I have finally gone and done it. A number of people have been giving me a bit of grief over this, and while the cfcUnit site hasn't yet been updated, I have gone ahead and made available for download cfcUnit's next release, 1.2 Beta 1.

The major enhancement brought forth in this release is the inclusion of a rather versatile Ant task, so now tests can be run from within Eclipse without much trouble or as part of any build/deployment process that employs Ant.

I will post more about this and update the cfcUnit site later on today, but the link below will take you to the download page:

http://sourceforge.net/project/showfiles.php?group_id=100854&package_id=126568&release_id=483297

Let me know how it goes. I look forward to any feedback.

All this talk of cfcUnit is making me nervous...

Mon, 31 Jul 2006 19:58:00 -0700

There are a number of people writing of the improvements in the latest version of cfcUnit, and I have not been one of them. So, you might be wondering why. Well, this last month since CFUnited, I have been busy making cfcUnit 1.1 ready for full release. That means fixing some bugs, adding some new assertions, and most importantly making sure that there is some better documentation available. On top of all that, though, I have been very busy making sure that you can run cfcUnit from everyone's favorite build tool, Ant.

Apparently, the absence of a cfcUnit Ant task and the existence of one for CFUnit has been a critical distinction between the two CF testing frameworks, giving people a reason not to use cfcUnit. Well, at CFUnited John Paul Ashenfelter took the initial stab at this elusive feature to show that it could be done without too much effort using the existing test runner that produces its results in WDDX.

There were a couple of problems with the first implementation, first among them that JDOM was used to process the XML document. This meant that when using the cfcUnit Ant task, you had to first download and install the JDOM libaray (and any of its subsequent dependencies) somewhere in the Ant classpath. A number of people discovered just how difficult (and not to say tedious) this process was for them just to get going.

Another problem was that the data format produced by the test runner was WDDX, a format that isn't very friendly to someone trying to read using XPath expressions since it really conveys no meaning at all to anything besides another WDDX parser.

So, what did I do about this?

Well, the first thing I did was come up with a new XML grammar that better describes the test results in a much more concise way. Once the format was in nailed down, I wrote a test runner to produce that XML. Once that was done, I needed to fix the problem posed by JDOM and its numerous dependencies.

One thing that is nice about Ant is that it is configured using XML. In fact, it uses Xerces and Xalan to process build configuration files, and I figured the cfcUnit task could take advantage of the fact that by running inside Ant it already has access to these libraries. So, after a bit of work, the cfcUnit Ant task is now a lot easier to install without any external libraries.

Now, some people might be wondering why I have gone to all this trouble of producing XML in the test runner and parsing it in the Ant task. Why not just format the text in ColdFusion and just display it in the console? Well, there is a good reason for this, and its pretty simple really. By sending raw data to the client, I can give the cfcUnit task a lot of options in how it handles errors and failures in both the individual tests and in the test runner itself. It can be configured to halt a build when something fails or to keep going, or show a full formatted stacktrace generated by an error inside a test.

Anyhow, after working with Ant for a little bit and seeing how Eclipse can automatically run cfcUnit whenever a file is changed, I can see why some people have gotten all bent out of shape because cfcUnit did not have an Ant task, but I'm sure that will all change soon.

Anyhow, here are some of the things others have been saying about cfcUnit lately:

cfcUnit at CFUnited

Thu, 29 Jun 2006 13:50:00 -0700

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.

Are you a nerd?

Fri, 14 Apr 2006 20:31:07 -0700

Its not as high as others, but I've got more time to make up the difference!

How To Write Unmaintainable Code

Wed, 23 Nov 2005 10:24:44 -0700

Do you write maintainable code? I'll bet you think so, but some might not agree...

How to Write Unmaintainable Code

Tartan 1.0.5 Preview coming soon

Mon, 21 Nov 2005 01:00:50 -0700

For those who are interested, the next version of Tartan (1.0.5) is coming soon. In the last couple of months I have gone ahead and made a number of changes, and I figured this would be a good time to introduce them.

Property Manager - tartan.core.PropertyManager

This has been added to address the need to have access to service-level properties from the LocalService class and any Command defined for that service. This enables command handlers to access service data without having to explicitly pass it around through command arguments. Before, if two or more commands needed to access the same model, it was the responsiblity of the calling service class to make sure it passed it in. Now properties can be declared in the configuration XML, set by service methods, and inside commands. The PropertyManager class has a number of methods that give it the general behavior of a struct/map. These include methods such as getProperty(), setProperty(), getProperties().

Here is an idea of how it looks in the XML configuration:

<service name="SERVICENAME" class="CLASSNAME">
   <properties>
      <property name="prop1" value="value1"/>
      <property name="prop2" value="value2"/>
   </properties>
   ...
</service>

ServiceContext - tartan.context.ServiceContext

This class was created to consolidate the management of the various factories that are used with a service and made available to command handlers. The CommandContext used to be initialized with the factories themselves, and the it accessed them directly. Now the CommandContext is initialized with the ServiceContext and all access to the factories is done through it. Additionaly, the PropertyManager is also accessible only through the ServiceContext.

There is a one-to-one relationship between service objects and ServiceContext objects. It is planned for the near future that all access to a service object will be through its ServiceContext. This includes remote calls, local proxies and even between individual services. This will enable finer-grained control over the lifecycle of the service, including how it is called.

User-defined Factories - tartan.core.Factory (abstract base class)

One of the limitations placed upon Tartan users was that all objects/factories had to be those provided by the framework. Existing classes did not fit cleanly into the services since it was up to the LocalService class itself to create and manage the creation of those classes/objects. With the addition of user-defined factories, a user of the framework can create a simple wrapper for their own factory classes and declare it for the service. One example of this is the wrapper for a ColdSpring bean factory which can be found at "tartan.contrib.ColdSpringBeanFactory".

The only requirement is that the wrapper class extends the class "tartan.core.Factory" and it implements the "getObject()" and "getObjectNames()" methods. It can create any type of object that ColdFusion can work with. The factory is available via the ServiceContext object's "getObject()" method.

Here is an idea of how it looks in the XML configuration:

<service name="SERVICENAME" class="CLASSNAME">
   ...
   <factory name="FACTORYNAME" class="CLASSNAME">
      <parameters>
         <parameter name="param1" value="value1"/>
         <parameter name="param2" value="value2"/>
      </parameters>
   </factory>
   ...
</service>

A number of changes have also been made to some of the existing classes as well, a couple of which have been renamed for greater clarity. First, the class "tartan.command.Event" was renamed to "tartan.context.Command", and the class "tartan.command.Command" was renamed to "tartan.command.CommandHandler". Basically, a Command is a logical name with a set of named values, and a CommandHandler is responsible for processing that command object. For me, the Event class never really fit since in the context of commands. For backwards compatibility the old classes will work the same as before, however, any new code should use the new classes.

configure() method

Additionally, the method "configure()" has been added to the following classes:

tartan.service.LocalService
tartan.command.CommandHandler
tartan.data.DAO
tartan.vo.ValueObject
tartan.exception.ExceptionHandler
tartan.core.Factory

This method is a place for user-defined initialization. Before, the only place for this was in the "init()" method and then it was up to the user to call "super.init()" which is less ideal and places an unneeded dependence on the implementation of the underlying abstract class.

Flash Remoting

There have also been some fixes for Flash Remoting as well. It seems that before service method arguments were not being properly converted from ASObjects to CFCs. Additionaly, arrays of CFCs/ASObjects are now properly handled in the conversion process.

XmlReaders/Builders

The various dynamic factory classes have handled the reading and interpretation of the Xml configuration. One of the changes I have made for this release is to separate the Xml configuration from the construction of the factory classes. Now, the reading of XML configuration has been delegated to the classes in the "tartan.xml.readers.*" package, and they produce an intermediate configuration. Also, the creation of the various factories has been moved into the classes in the "tartan.builders.*" package. The configuration generated by the XmlReaders can be fed into the Builder classes to produce the objects needed for each service. One of the benefits of doing this is that the dynamic factories are now simpler since they no longer deal with reading of XML. Additionally, it should make it easier to add different sources for the service configuration.

Sample Applications

There have been a couple of sample applications added to show some of the newer functionality. They are listed below:

Contact Manager (MachII, Flex)
Task Manager (Fusebox)

The other sample apps have also been updated.

Anyhow, these are most of the changes in this release candidate. I am interested to hear what you have to say.

Until I get the code in a single download, you can download the framework from the project's CVS repository. If you are interested in checking it out, you can find it here:

CVSROOT
:pserver:anonymous@cvs.sourceforge.net/cvsroot/openxcf

MODULE
tartan_framework

TAG
Tartan-Framework-1_0_5-RC1

Dave Ross and ColdSpring at the Fusebox Conference

Mon, 15 Aug 2005 16:20:25 -0700

Dave Ross has been asked by numerous people to speak about ColdSpring at the Fusebox Conference this year, but needs interested people to justify attending. If you are interested in learning more about ColdSpring and how it fits with the other frameworks, let him know.

Tartan at Fusebox and Frameworks 2005 Conference

Mon, 15 Aug 2005 16:15:21 -0700

Well, I have been invited to speak at the Fusebox Conference this year on Tartan. I will be giving an overview of the idea of service oriented architecture and how Tartan fits into the landscape of ColdFusion frameworks including Fusebox, MachII and ModelGlue. If you currently use one of these frameworks or you build RIAs with ColdFusion backends and you are planning on attending the conference this year, then I recommend you check it out.

Some time to reflect...

Sun, 03 Jul 2005 18:36:12 -0700

Well, with CFUnited over and done with, there are quite a few things to reflect on. I don't think I am ready to say anything yet, but I think tomorrow I will be able to share my thoughts. Stay tuned...

New Tartan presentation available via Breeze

Wed, 18 May 2005 16:34:12 -0700

A couple of hours ago I gave a presentation introducting Tartan via Breeze. If you weren't able to watch it live, you can watch a recording.

Unit tests to the rescue!

Tue, 17 May 2005 13:49:00 -0700

It's amazing what you discover about your code when you try to write unit tests for it after the fact. When I was developing Tartan some months ago, all the testing I did was manual. I just checked that it acted the way I wanted to under certain configurations, but as I moved forward, some tests would no longer work since the code they were testing no longer existed or worked in a different manner. Really, I was testing the code to validate ideas and ways of doing things.

The biggest problem, though, was that I was not really testing small units of functionality like method calls, but in larger units of general behavior. How then would I know if something broke as I made changes to the core framework code? The simple answer is that it would throw some exception someplace and I might know how to fix it. But really, I wouldn't know since I had nothing in place to do any sort of regression testing. So far, that has worked.

A couple of weeks ago, I decided that this needed to change. As Tartan has moved forward, I have gotten a lot of requests for changes, bug fixes, and enhancements. Many of these changes aren't so simple and require a good idea of how things are put together. Some people have sent me code that makes some of these changes, but it is really difficult to see how these changes affect the rest of the code.

So, I decided that before any important changes were made to the framework, there would be unit tests to verify all of the current code. It was a tough decision since there is so much code to test and there are a lot of things I would like to do with the framework. There are several things that guided my decision. First, I really need to know exactly what the code is doing and how it can break. The only way to do this is through specific and repeatable tests. Second, as more people use the framework and the code evolves backwards-compatibilty becomes more important that ever. The only way to track this is to have tests that guarantee pre-existing interfaces and behavior. Third, I am not the only person that would like to make contributions to the codebase. As I stated earler, several people have expressed interest in improving the code and have submitted code highlighting these changes. Without any formal unit tests in place, it is more difficult for anyone involved (even me) to know if the change interferes with anything else or just doesn't work. Additionally, any new code would be given its own set of tests that run with all the others.

So far, I have written about 45 tests using cfcUnit, and I am not even half way yet. I have however learned quite a bit about some of the current weaknesses that exist in my code, and I have even discovered some rather subtle bugs that I didn't really see in my earlier testing. I have written tests for these and fixed them. I also see a lot of things I really want to change, and that has been the hardest part in a way. Part of me just wants to go ahead and introduce new features and move things forward, but I realize that in order to move forward I have to know where I stand. I can't do that without the tests. So, I make a list and move on to writing more tests.

I have been asked when the next release of Tartan will be coming out, and my answer is after these tests are written. It is an investment in the future of the framework and the community of people use it and want to contribute to it.