Beating the Flying Spaghetti Code Monster with CFWheels - Part 1

Background

I started writing web application using Coldfusion in 2000 with version 4.5. Like probably most of us back in those early days, we had one hand on the keyboard and a copy of Ben Forta’s Web Application Contrution Kit (WACK) in the other. My development of applications consisted of creating a single autonomous file, with both database queries and conditional display code. This of course was tied to yet another autonomous which did the same, etc, etc, etc. Thus the “Flying Spaghetti Code Monster” Even after I started to use the Application.cfm “framework” within ColdFusion, I still had all of these autonomous files that would often break if I changed a variable or parameter that should be passed into the next.
After developing a few applications like this I realized there had to be a better way. Somehow I came across the Fusebox 2 framework and started to look into it. This framework encouraged you to break the application up into separate files, query file, action file, display file, and then “chain” these together like fuses in an electrical circuit.
Shortly after Fusebox version 3 was released and I begin using this framework to develop my applications. I especially loved the formurl2attributes function that put all of your url and form variables into a single scope. I started to convert small pieces of my existing applications from my spaghetti code to organized code following the Fusebox methodology, however I ended up sticking more with the file naming then actually using the framework after a while. When Fusebox version 4 was released I found it difficult to grasp, as well as the CFC concept that was brand new. My two and a half years of part-time web application programming was coming to a close though as I left to work full-time as a systems administrator.
Over the next 7 years the largest of the web applications I wrote, a Laboratory Information System (LIS), continued to work for the University lab I wrote it for with minimal adjustments to it.

Back to Developing

At the end of those 7 years I was hired back, part-time, for this same lab, and part-time for another lab (so it’s a full-time position) on campus. When I looked at this old source code I saw the “Flying Spaghetti Code Monster” glaring back at me. I had well over 350 individual files and the folder size was near 80MB, not to mention no source control software to help manage it. I knew there had to be a better way to handle this, I didn’t want to continue to develop this way.
The first thing I did was get the software into a source control system. Subversion was the choice as it was the easiest for me to grasp initially. I went back to look at the Fusebox framework and saw it was still around, but it didn’t seem like many were using it any longer. There was the Mach-II framework, but I couldn’t seem to understand that either. In the meantime I continued to serve the hard master known as the “Flying Spaghetti Code Monster” and maintain the code as it was, even adding new features, without much difference in my development pattern.
After five months of developing this way I came across the ColdFusion on Wheels framework website, not sure how (probably Twitter). After greedily consuming all of the available screencasts I knew this was the way I needed to develop the application. The question was, how do I learn the CFWheels framework and use it to power this application? I saw two choices:

1. start from scratch in a parallel environment using CFWheels and recreate all of the functionality
2. slowly, one “tenticle” at a time, battle the “Flying Spaghetti Code Monster” by converting a section to the CFWheels framework

After considering it I decided choice 2 was for me, to slowly convert the application. In the following post I’ll explain how I’m doing this.