Porting Fusebox 5 Apps to Coldbox : Views

In my previous post of this series I showed you how I ported my Fusebox 5 controllers over to Coldbox event handlers. It was quite an easy task and didn’t take much time at all. In this post I want to show you a few changes that I made to my views when porting this particular application. Now I will mostly be focusing on CRUD type views from the admin system since this is where most of the work was involved.

Before we talk about views though, let me take a few minutes and talk about some of the things that I do in my Fusebox apps that have made porting to Coldbox VERY easy.

First, I always use MVC patterns. That is, I separate my business logic from my views and I use controllers to handle tying them together. This has always been a strong point in Fusebox and one of the things that has kept me using it for so long. By doing this, its much easier to port components of your application to other frameworks. If you have queries intermingled in your views its going to be much harder and more time consuming to port.Secondly, and this is closely related to the first item, I use Coldspring to manage my business model. All of my CFC’s that make up the model portion of my applications are managed by Coldspring. Until I started porting this application, I never really understood the importance of Coldspring, I only knew that it made working with my model MUCH easier. The model in this particular application needed no modification at all when porting to Coldbox. I was able to port this application to a completely different framework and I didn’t have to touch one line of code in my model. Thats right, the most code intensive piece of the application that contained all of the business logic and queries never had to be touched. To me, that is just amazing and speaks volumes for how great Coldspring is.

Another great thing about using Coldspring is that all of the major frameworks for ColdFusion have some sort of built-in mechanism that makes working with your Coldspring model very simple.

Ok, thats enough tooting the horn for Coldspring and MVC. I just thought that they were such a big part of why this port was so easy that it was worth mentioning here. Now, onto the changes in my views.

One of the biggest changes that I had to make was changing the links and XFA’s (Exit FuseActions) over to support ColdBox’s link style and XEH’s (eXit EventHandlers).

FuseBox links in my views look something like this:


Edit User

Now after porting them to ColdBox, they look like this:


Edit User

Basically, we just replace the myself variable with ?event=, and this could be avoided if you didn’t want to have to make the changes in your views. You could just set a local variable called “myself” to “?event=” and be done with it. Notice we also prefixed our XEH and our UserBean reference with the “rc” scope. That goes back to our last article when I mentioned that everything in ColdBox is put into the “Event” object and I usually copy the Event object to the “rc” scope once to make it easier to access the variables. Well, with the release of ColdBox 2.0.3, their is no longer a need to explicitly copy this to the “rc” scope, Luis made the “rc” scope implicitly available in the views which removed a little of the work needed to port my app! Nice!

Really the only other change that I had to make was to change the way that all of my other views referenced my objects. Like I mentioned about the UserBean object in the above link, every reference to a query object or a Bean had to be modified. Nothing at all hard about it, but it is just a bit time consuming. There are two ways you can handle this and its really personal preference. Im not sure if there are performance hits on one method over the other yet, but I plan to look into this a little more.

The first method is just to prefix every reference with the “rc” scope like this:


#UserBean.getUserName()#


… becomes


#rc.UserBean.getUserName()#


The drawback to this approach is that its very time consuming hunting down all of the references and modifying them. The next approach is the method that I chose in the interest of time. This method seems like it would come with a bit of a performance hit but how much remains to be seen.

All I did was at the top of the view that referenced a query or a bean object, I just set it to a local variable like this:




Now, Im not sure if doing this actually creates a true copy of the object or if it just assigns a reference to it. If its the latter, this method is really no big deal. If its the former, this probably wouldn’t be the way that you would want to go for performance reasons. I know that in the real world, making a copy of a single bean object in my view for this admin that has about 3 users isn’t going to make much difference. But in an application where you may be making a copy of 100 objects in a single request, this could get expensive. Again, Im not really sure which it does, hopefully someone who is more knowledgeable about the inner workings of objects in ColdFusion can clarify this for us.

OK, thats about enough for now.

6 thoughts on “Porting Fusebox 5 Apps to Coldbox : Views”

  1. Russ, great post… how would you like if the rc was injected directly into the view’s variable scope instead? I personally always felt that if you set any values in the event handler is probably because you would need them in the view later, so it only makes sense to make them directly available…

    The way you’re assigning variables is not making a full copy, but just making a reference to the original one. The way it works is the following:
    cfset var = simpleVar <— copy
    cfset var = complexVar <— reference

    so you’re really not adding more memory.

    HTH

  2. Thanks Rob!

    Yes, directly injecting them into the views local scope would be even better in my opinion. Well, maybe not better but at least more convenient! 😉

    Thanks for the clarification on the copying! That makes me feel better about the way I was doing it!

  3. Hey Russ,

    Curious as to why you are porting from Fusebox to Coldbox? What about Coldbox do you like more than Fusebox if anything?

  4. Whoops never mind, just saw the previous blog post about not having to use xml controllers. I have never liked that style either so I’ve always stuck with FB3. I’ll have to take a look at the ColdBox/Coldspring combo, sounds pretty sweet.

  5. @Josh, make sure to check out the new CCTApp inside the ColdBox Samples folder… it’s a quick start with ColdBox, ColdSpring, and Transfer… the version with the distribution is alpha, but it’s already an excellent starting point. Final will come with ColdBox 2.1, so keep an eye on that.

Leave a Reply

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


*