I’ve been a long-time Fusebox coder (since version 2) and have always asserted that for most small scale web applications, a procedural approach is 100% fine. I could never be bothered with the overhead that object-oriented code takes, considering the size and simplicity of the projects I typically did.

That is what I still believe. However, of late I’ve been working with other people’s code that is more OO in approach, and I can see the benefits, especially for larger and more complex projects. I’ve been getting more and more ColdFusion projects recently and it’s a lot of fun. I had two projects about to start, and although neither of them were huge, I decided to try and go the whole OO hog, and maybe learn some new stuff in the process.

Part of the reason I thought I’d give it a try was Illudium PU-36 Code Generator, which is actually a crazy name for a pretty cool tool that generates all the factory, service, DAO and bean CFCs directly from your database tables – in other words, saving you a ton of typing, cutting and pasting and then more wasted time tracking down errors caused by typos (cool screencast here). I happened to be talking to Andrew Mercer, CFUGWA’s OO Guru, and as well as answering some of my noobish questions he pointed me towards Russ Johnson’s Fusebox 5 templates for Illudium PU-36. They generate Controller and View circuit.xml files plus listing and form pages in Fusebox 5 friendly format, giving you a massive head start on creating administration applications. What impressed me most, however, was that the forms and tables that are generated are nice, semantic, valid HTML. Although I changed the forms a bit – I’m hopping on the latest trend which is putting each label and input pair into an ordered list item – they were so close to what I’d normally create myself that I was literally rubbing my hands together with glee.

However, there was another hurdle. Russ’s Fusebox 5 templates are designed to be used with ColdSpring. So I had to get a handle on that too. After reading about ColdSpring I can see the benefits of that too, and at the simple level it’s not hard to integrate. All in all, I can see what I probably should be doing, framework-wise.

However, timelines and scopes started to creep, as they do, and some atypical staffing issues meant that in the end, I didn’t have the time I would have liked to work on those projects. The crunch started and it started to look tight. I came across some conceptual hurdles – which was not surprising, really – so I went back to doing what I know: procedural Fusebox 5.

So is that bad? It’s clean, understandable, framework-compliant code. It works, it’s easy to debug, and it was easy for me to write. So no, I don’t think it’s bad at all.

The next project I have with more time, I will have another crack at an OO approach. In the meantime, thank your deity of choice for good ole’ dependable Fusebox!