Clogging up the Web

I’ve flirted with a lot of technologies over the years. More recently I have been working with Java - Struts with Spring, and even more recently .NET/C#/ASP.NET. They are fine architectures in their own right, and in high-end commercial systems they have a lot to offer. However, there is still something just too heavy duty about them for me. You just don’t really hit the ground running with them.

I’ve always liked Coldfusion. I started with CF 4.5 and am currently getting to grips with CF 8. In the beginning, like most people, my code was purely procedural and lacked an architecture. Sure, ColdFusion provided a lot of standardised ways of doing things, but you still ended up with real ugly code. Then I adopted a methodolgy called Fusebox - before it was a framework. It was just a good way to structure applications and tidied up the code considerably because the applications all started in the same place with an index.cfm control box including its fuses.

I never adopted the Fusebox framework (version 4+). Mostly this was because I had drifted into Java and then .NET. Here I began to discover frameworks and even did some research in the area for a CIT project. I knew about MVC going back over the years, but my first introduction to an MVC framework was with Struts. I must admit I hate Struts. It’s far too heavy-weight. I also became familiar with the light-weight Spring framework, which made a lot of sense, even if it took a long time for me to get my head around it. Spring just makes it so easy to inject objects and configuration settings into your application from the get-go. As for .NET, I can’t say I know an awful lot about it from a framework perspective… Visual Studio tends to remove you from the nuts and bolts a bit.

Which brings me back to ColdFusion. I have been trying to develop a recruitment system, mostly for my own education, but it could turn into something commercial. From past experience, I knew a framework was essential. I chose Model-Glue because it was light-weight, integrated with ColdSpring, and integrated with an Object Relation Mapper (ORM) - choice of Transfer and Reactor. I chose Reactor for the ORM because the integration seems better with Model-Glue and because Reactor seems a lot easier to setup. I did try Transfer, but found the configuration a bit overwhelming - though I do acknowledge Transfer has a lot of additional benefits like caching.

However, I’ll step back a bit. Initially I tried to start sans framework and develop my model… the usual beans and DAOs. This worked fine and I was pumping the DSN, etc, into the DAOs via the init method from a REQUEST scope variable. It’s not a terrrible way to do it, but as I continued on and looked at frameworks, I realised I was doing too much work. I had a look at Mach-II with ColdSpring and nearly got it to work with my DAOs - I was using CFCGenerator. Then I tried Transfer and found the configuration very tricky - probably because I messed up the one-to-many and many-to-one relationships. Finally when I was getting a tad frustrated I decided to give one last framework a try, so I downloaded Model-Glue. This was when I discovered scaffolds… again. You see, a couple of years ago I flirted with Ruby on Rails (I guess a lot of people did). So, the word scaffold flashed a light in my head.

So, I followed the sparse documentation on Model Glue and Reactor, not really reading up too much on ColdSpring, and started to get real results. The beauty is, you don’t need to know a whole lot about ColdSpring or Reactor with Model-Glue. You need to know a bit about the ColdSpring.xml file and you need to know how to add your tables and relationships to Reactor.xml, but that’s mostly it. The scaffold functionality allows you to generate the xml and the views. Rather than just leave the scaffolds, I copy the event handlers from Scaffolds.xml into ModelGlue.xml and copy the views from the generated folder to the main views folder. Then I customise.

I will post more about my development with these frameworks.

Technorati Tags: ColdFusion, coldspring, frameworks, fusebox, mach-ii, model-glue, modelglue, mvc, orm, reactor, scaffolds, spring framework