Porting Fusebox 5 Apps to Coldbox : Controllers

I started poking around Coldbox a couple months ago but only had enough time to see how it operates from a 10,000 foot view. So I decided that I wanted to take another crack at it and really see what it was all about. I figured the best way to do that was to port one of my existing Fusebox 5 apps over to Coldbox so I could get a good comparison. After creating a new application via the Coldbox dashboard and importing it into CFEclipse, I was on my way to porting bliss.

In my opinion, the two frameworks aren’t really all that different. Of course I develop all of my Fusebox applications using MVC so that helps quite a bit. One of the biggest differences that I noticed right away is that Fusebox 5 uses XML based controllers where Coldbox uses CFC based controllers. I have to admit after writing literally thousands of XML fuseaction’s over the last couple years, I am finding myself smiling every time I write a new method in one of my event handlers for Coldbox. This has been the one single feature of Fusebox that has bugged the crap out of me since it was introduced. And to be fair, I know that Sean Corfield and Team Fusebox are working hard on the new Fusebox 5.5 release which will allow you to use CFC based controllers.

Going into a full feature comparison is beyond the scope of this post so lets look at a couple examples of what I did when porting my application over to Coldbox.Heres an example of a fuseaction in my Fusebox application followed by the new method in the Coldbox event handler.

Fusebox Fuseaction:








Coldbox Event Handler Method:













Lets break those down shall we? First off, both Fusebox and Coldbox give you the ability to run functions at the beginning of every call to that Circuit/Handler. In Fusebox it looks like this:

..and in Coldbox we do this:





As you can see, there's not that much difference. They both basically just make a call to another fuseaction/method to run at the beginning of the request.

Next, in our actual fuseaction/method, you'll see that both also have there own way of identifying possible exits of that request. In Fusebox, we use XFA's or Exit Fuseaction's:






...and in Coldbox we set XEH's or Exit Event Handlers:





Now, lets compare how both frameworks handle working with Coldspring. Since every application I write these days uses Coldspring, it was pretty important to me that Coldbox have the ability to seamlessly work with it. Fusebox uses its own lexicons to provide a set of XML tags to allow you to work with Coldspring. This is one of the things that actually made it bearable for me to work with XML controllers. It takes all of the work out of it and makes it very easy. In order to get a bean from our Coldspring Factory, we use the following code:


Thats pretty darn easy! In Coldbox, working with Coldspring is really just as easy. There is an IOC plugin that is shipped with Coldspring that allows you to call beans from the Factory with a single line of code just as in Fusebox:


And to call a method of that bean, its again, a single line of code for both frameworks:




At the end of each request, I call my view. Now here is where things are just a tad bit different. In Fusebox, I call another fuseaction from the Views circuit to render my view like this:



So I have to setup more circuits and fuseaction's for my views. But in Coldbox, I don't have to setup another event handler for my views. I simply call in the view using the Event.setView() method like this:


This simply points to a folder and a file under my "views" directory.

Another difference to note is that Fusebox uses the "attributes" scope to store all of its form and url variables and Coldbox stores everything in the "event". So instead of just calling attributes.variableName like in Fusebox, you have to use a method of the Event object to get your variable out such as event.getValue("variableName"). Another method of dealing with this can be seen in my Coldbox method where I follow Luis Majano's pattern of copying the event object into a local variable scope called "rc" which stands for "request collection". This just makes it a little easier to get at the variables without having to call the methods everywhere you want to access one.

So, if your still with me this far, you can see that there's not a lot of differences at this point. Porting my circuit.xml files from Fusebox to Coldbox Event Handlers went very smoothly and wasn't very time consuming at all. Since this post is so long already, Im going to wait until my next post to show you the changes that I had to make in my views during this porting process.

8 thoughts on “Porting Fusebox 5 Apps to Coldbox : Controllers”

  1. Sounds pretty interesting so far! I look forward to what will probably be a collection of Coldbox articles. I’d be interested in the performance of Coldbox vs. Fusebox, so I hope you’ll be covering that as well.

  2. I will certainly be covering that Brian! Thats one of the greatest things about Fusebox, its speed! Im still running Coldbox in development mode on this application but once I switch it over and have a few days to play with it, I will be posting my observations. But first, I have to find the time to write the rest of the porting posts 😉

  3. Great post, Russ. I also look forward to more posts on the topic. I have just begun taking a serious look at ColdBox myself, and am -very- pleased with the ease of porting apps over to it. Based on what I’ve seen so far, I’m not expecting any speed issues, but I look forward to learning the experiences of other developers as well!

  4. If you like the event object style of dealing with URL and form scope, that is available in Fusebox 5.1 as the event object with a getValue() method – just like Model-Glue (and ColdBox, it seems).

    The Fusebox 5.5 Alpha was released to the fusebox5 mailing list a while back – the Public Beta is coming soon – and that will allow circuits to be written as CFCs instead of XML (and the fusebox.xml file can be omitted as well). I’ll start blogging about it soon – I have a couple of rough edges to nail down first.

  5. Russ really great stuff, seems to be that a FB5 App can easily be port to ColdBox. I think speed of coldbox is far better than any other framework. plus many really cool tools.

    @ Sean is FB5.5 will be mimic of coldbox!!!! 🙂

  6. @Sean
    Thanks for the update. I was playing with the FB5.5 alpha a little and I like the direction that you guys are taking with it for sure. Im glad to see the introduction of CFC based controllers.

    I saw the event capabilities in 5.1, I just hadnt had a chance to use them yet. Im not sure that Im fan of that or not. I really like just having direct access to the variables in the attributes scope without having to use a method to get to them. Although I know thats probably not proper OO it does make it quite a bit easier. I think thats why I grab the event collection in Coldbox and stick it in the rc scope so I can access them.

  7. It’s somewhat misleading to say that you had to create extra fuseactions for your views in FuseBox. As far as I know, there was never any requirement to design a fusebox app that way — it wasn’t even intended from the perspective of the original architects that I know of. It became popular, yes, but unnecessary.

    What you describe as being "different" about ColdBox is actually the original conception of the way FuseBox 4+ was supposed to work. Instead of creating a view fuseaction and using "do" the intent was to just call the view templates in the current fuseaction with "include".

    It wasn’t until after the fact that it became popular to separate fuseactions into "model", "controller" and "view" circuits, which to me reflects that the people who started that trend had a poor understanding of the concept of MVC.

    A more solid understanding of MVC I think would have resulted in a context-based circuit ("client" for example) with each fuseaction (controller) containing references to the model using "set" or "include" tags to gain access to cfc’s, followed by "include" tags to reference whatever views it needed. This would have been functionally the same as your ColdBox example.

    I actually don’t care for FuseBox, I’m just saying…

Leave a Reply

Your email address will not be published. Required fields are marked *


*