Rip's Domain

Who’s using ColdBox?

Posted in ColdFusion by rip747 on October 24, 2006

With all the talk about Model-Glue, MachII and Fusebox being the frameworks of choice for CF development, I’m wondering if anyone is using ColdBox out there. I’ve been watching this framework for sometime now, but I have yet to have the time to really sit down and give it a whirl. The features list is really impressive and thier the backend dashboard is unbelievable. This is one really professionally thought out framework. With the release of 1.1.0, I have to get off my ass and start playing around with this. So back to the original question: Is anyone out there using it yet? If you are, please leave me some comments about what your experience with it is like.


11 Responses

Subscribe to comments with RSS.

  1. Jeff Fleitz said, on October 25, 2006 at 4:37 pm

    Wow, major attention to visual detail there. That is something I feel is really lacking in the other frameworks. Everyone is so interested in the plumming, but the eye candy is important, especially for those of us who are graphically handicapped.

    I had briefly looked it over a couple months ago, but didn’t go anywhere with it. It definately looks like something to spend some more time with. Thanks for pointing this out.

  2. Oscar Arevalo said, on October 26, 2006 at 12:49 am

    I’ve been using coldbox for a while now, and have it already included in a couple of released projects, and although I haven’t really done any major production work in the other big frameworks, after hearing the frameworks conference at MAX about MG, FB and M2, I still prefer ColdBox. For me, CB’s greatest asset is that when you develop for this frameworks, you feel that you are really working in ColdFusion and you are not getting lost in big and complex XML documents to describe the application logic. In Coldbox applications, the role of the framework engine is very transparent and apparently simple (although I know that it does some heavy and robust work in the background) and intuitive. It has a clear and simple way of forcing developers to clearly separate processing logic from presentation code, by using the concepts of event handlers and views.

  3. rip747 said, on October 26, 2006 at 3:37 pm


    That’s one thing that I noticed first, the application itself is beautiful. The author really paid a lot of attention to how it looked. I’m in the same boat you are with not having a chance to play with it yet.


    This is my biggest gripe with all the frameworks out there, I can’t stand the XML crap. Now that I know that ColdBox doesn’t do this, this will definitely be my big priority framework.

  4. Jeff Knooren said, on November 1, 2006 at 10:03 am

    I don’t mind the “XML crap” with Fusebox 5, probably because I’ve been using it since Fusebox 2. Fusebox 2 was crap. The real benefit in the XML structure, is that there are only 4-5 files you actually edit. Navigating a UI for 4-5 files would actually slow you down, and that wouldn’t really be a benefit. Anyway, I’ll give Coldbox a whirl. I’ve already tried Flex, Laszlo, Ruby on Rails… I think an interface could be made for Fusebox like Coldbox has. But, at the same time, I can see why you really don’t need one.

  5. Luis Majano said, on November 2, 2006 at 7:22 pm

    You should definetly take ColdBox for a spin. You won’t be disappointed. The bundle download includes several applications like Raymond Camden’s BlogCFC, Galleon Forums, Brian Rinaldi’s CFC Generator, Paul Hastings i18N gallery, ColdBox Reader (RSS Reader) and more. I also updated all the documentation in the Trac site: So all the guides are extensively documented.

    You will see that one of the main differences between ColdBox and any other framework is its implementation and its software aspects. It can do your logging for you, your bug reports, your development environments, and i18N. So a lot of the tedious tasks that are part of a project can be turned on and off for your convenience. The dashboard is still in development, but its purpose is to manage your framework installation, auto-update it if needed, a documentation library, a tool set for you application development and an auditing tool for bugs via the error logs. The log viewer will be a centralized place where you can register local log files or external log files via RSS (as long as those remote server files are running the coldbox dashboard). One place to see your bug reports and in the future expand on it: filters, rules, actions to take, etc. You also have the application builder, which will help you get started on a new project, even based on a previous project (skeletons),etc.

    You have my contact info, so you can contact me with any questions you like. I can talk to you why I build it, what are its strong points, its weak points, its flexibility, etc. This framework handles really well for high availability applications, just look at

    Well, thanks guys for this post, I hope the ColdBox community keeps growing. Also, the Google groups has been opened:

  6. Jeff Knooren said, on November 12, 2006 at 7:42 pm

    Ok, I’ve checked out Coldbox. It’s a decent “framework”. But here is the problem. If you have to include the core files in every application you build, it isn’t actually a framework. It’s just basic plumming that handles basic site operations.

    There are already many frameworks, and they all do basically the same thing. Fusebox, Model-Glue, Tartan, Coldspring, and there really isn’t a need for yet another framework. A few years ago, Fusebox was an MVC pattern, and Model-Glue used OOP. But, now that both of these frameworks use both patterns. There is no need to start from scratch, and rewrite a new framework from the ground up! The Coldfusion community is kind of small, I don’t see a reason to create yet another framework to compete against what’s already out there.

    Essentially, there isn’t a benefit to using Coldbox. Yes, it has an interface. But, that doesn’t mean you won’t have to edit XML files. But more importantly, there isn’t anything it does, that couldn’t be done with already more established frameworks. The sample applications, such as Ray Camdens blog, that come with Coldbox, were essentially re-written to work in Coldbox. Litmus test, if you have to rewrite the application, you’re not using a framework!! What should have been done, is to extend an existing framework, with an interface.

  7. rip747 said, on November 12, 2006 at 8:02 pm


    Jesus man, be nice 🙂

    -If you have to include the core files in every application you build, it isn’t actually a framework. It’s just basic plumming that handles basic site operations.

    I don’t agree with because that plain fact is, ColdFusion it’s self doesn’t have a framework or any sort of application model whatsoever. I guess this is the reason why CF is so easy to learn. Other languages like .NET have a framework built into it (single form submit with event handling). Some would agrue that this is good and others bad. It’s good because everyone is using the same way code, it’s bad because everyone is using the same way to code 🙂 There really isn’t any way “break out” of the .NET framework an use your own. With CF though, you can and I guess that’s what makes the language so powerful.

    I agree that there are several frameworks now that we can choose from and yes they all do basically the same thing: providing a way to organize and easily extend your application. Most of them are using the MVC approach but their might be a few out there that take a different approach. Personally I’m going to take the exact opposite of your position, I think that we need more frameworks to choose from. I’d reason of a plethora to choose from that being stuck with only one or a few.

    ColdBox does have a benefit. From what I’ve read about it (and again I haven’t had the chance to site there and jerk around with it), it’s suppose to be very fast and enterprise ready. With claims like this it will make the other frameworks improve themselves.

    You’re always going to have to rewrite an application to get it to work with a framework no matter which one you use. I doubt you could take Ray’s blog application and just magically get it to work with FB, MG, or Machii without rewriting it extensively.

    I want to thank you for your comment Jeff, even though I don’t agree with some of the points you made, at least you made them and for that I thank you again.

  8. Jeff Knooren said, on November 12, 2006 at 9:32 pm

    You’re always going to have to rewrite an application to get it to work with a framework no matter which one you use.
    You always will if you create ever more variations of the same thing. Refer to your .NET arguement.

    Personally I’m going to take the exact opposite of your position, I think that we need more frameworks to choose from. I’d reason of a plethora to choose from that being stuck with only one or a few.

    There just aren’t that many differences in how they work, to warrant them. Most developers don’t really care about frameworks anyway. Coldbox may be faster, but how much faster really? Faster than Tartan? If anyone can answer those questions, I think you’ve lost focus on what is really important about the application being built.

    Too many frameworks complicate the semantic differences between them. Just as you mention, Coldfusion doesn’t need a framework to begin with. So, it doesn’t make sense to have a plethora of choices between something you don’t need! That makes development harder, not easier! Framework choice only matters in how you want to organize your code. From that there are limited patterns available to base a framework on.

    I’m sure Luis is a fine engineer. If I had any critical remarks, it would be: What Luis should have done, is extend an existing framework with his Coldbox interface, rather than start from scratch. I would also say the same thing to anyone planning to produce another framework. For example, his XMLParser.cfc could have just as easily read Fusebox files, and the logging plugin could have captured the current fuseaction. So the question I pose, is what does Coldbox do, that can’t be done by another framework?

    I’ve found that often when someone asserts that something doesn’t work, it’s most often caused by improper use. Many websites, like MySpace, run on Fusebox and handle the load just fine. That is because it’s Coldfusion doing the real work, and the framework makes little difference. His reasons for creating a new framework may have been valid. However, they’ve been adressed by Hal Helms, Sean Corefield, Ben Edwards, Jeff Peters… “The Masters” in the Coldfusion community.

  9. Luis Majano said, on November 19, 2006 at 4:17 pm

    Hi Jeff, Here are some observations about your comments, which are direct and to the point. I admire honesty and I truly believe that comments like yours are very constructive because nobody can be in my head or on other ColdBox application users and realize all the work that can be done or what ColdBox can do. So here are my comments:

    “If you have to include the core files in every application you build, it isn’t actually a framework.”

    You are always going to have to do includes to use a framework. It cannot magically be embedded in your code. You have to call it. If you are refering to the pre 1.1.0 installs, then you are right, the system folder had to be embedded in the application. Why? Because ColdBox started not as a full blown open source framework, but a robust object oriented architecture for high availablity applications at my previous employer: Sandals & Beaches Resorts.

    Now you start seeing why I build my own from scratch. None of them fullfilled all my needs for my application, an online reservation system for hotel and airlines, which receives over 500,000 requests per day per server. The only one that I liked was fusebox, but it still did not meet my needs and at the time it was not implemented via CFC’s. I did not start from scratch, I started from basic J2EE design patterns due to my c++ and java background, which are proven solutions, I also reviewed tartan, mach-ii, and model-glue. I like their MVC implementations but not their logic via the config file, no environment specific, no loggin capabilities, no web application aspects where there.

    Config files,in my opinion, are about configuration and setup, not logic. All these frameworks, embedded some logic on their XML files. I believed that I could still go a step further and de-couple the logic in to objects. And that is what I did with the event handlers. This doesn’t mean you don’t have to setup your application via a config.xml file, you still have implicit calls which have to exist somewhere. Jeff, there is no silver bullet for all these frameworks, nor will there ever be. You can use model-glue perfectly for a solution, but maybe it won’t be good enough for another. These frameworks are tools, you must choose your tools depending on your requirements. How do you determine that then? Well, using it, build applications on it, see the benefit,load test them, etc. You cannot say that only because these frameworks exist before, that they could solve a project’s requirements.

    I think that your comment saying that we don’t need another framework does not have basis. I tried to use what was out there and they could not satisfy my requirements. Should I just try to patch them up? or really solve a problem that could be reused.

    ColdBox’s roots are not open source and where not to replace or compete with these frameworks. I started doing proof of concepts back in July of 2005 for my online reservation system. One thing I have to tell you, that framework code has been scrutinized like you won’t believe due to the nature of a mission criticial application that is generating millions of dollars a day and it CANNOT GO DOWN. Another thing I saw is that ColdFusion also has a limit and several bugs where discovered thanks to this code. I can tell you that under extreme heavy load, cfsavecontent will start throwing java.lang.illegalState and null pointer expections. However, ColdBox has become more than a framework, but also a developer toolkit. Which is something that you need to understand. It solves your issues of i18N, resource bundle usage, logging & auditing, web service integrations, and more.

    All those are aspects of a web application that you have reusable componets to use or extend in your own application.

    In your comment about the blog application:
    Ray Camden’s Blog was a mere port, another way of doing things. It does not mean, and I state throught the docs, that an object oriented application following MVC design patterns should be written that way. That application has its own internal framework and logic. I merely decoupled and arranged the code. IT DOES NOT MEAN IT IS A COLDBOX APPLICATION. That would require re-writing the entire thing from the ground up in an object oriented way, and I really did not want to. Even if you port it to mach-ii or model-glue. It would still be the same, a port, not a fully oo design.

    About your comment on re-writing and application:
    “if you have to rewrite the application, you’re not using a framework!! What should have been done, is to extend an existing framework, with an interface.”

    If you are extending an existing framework to write an interface, you are re-writing the application. Mach-ii will make you adhere to their rules, model-glue to theirs. The logic of your application will change, the way to get/set variables will change. If you port an application from one framework to another, you will have to re-write and modify code. I did, for Brian Rinaldi’s Illidium CFC Generator, from mach-ii to coldbox. It is more simple to do this, since the decoupling is done already. The business layer is separate, the views are separete. It is easier to convert from one framework to another, than from procedural code to a framework. No matter what you do Jeff, you have to re-write code. In my over 10 years of software engineering I have not yet seen something that I can plug and play without not re-writing or modifying at least one module.

    I don’t believe a framework is just for organizing code like you say it does. Then why is Struts still going strong and impressive at the Enterprise level. It is an approach, a solution, to a common problem, it is de-coupling your logic from your presentations. This in turn gives you more flexibility and architectural leverage. You can maintain bigger and more complex applications this way. You can embedd a J2EE business logic easily and transparently, trying doing that without a framework. You would have calls everywhere. You can create your business delegates and session facades with ease. I see a huge benefit of using a framework that maybe you have not been exposed too. ColdFusion in its roots was not oo. It can be now. Most major design patterns do apply to Coldfusion and decoupling and object oriented approaches are posible. Yes, they will make your application more complex, harder to grasp, and event WEIRD!! But that is the intent, to take your application to an Enterprise level. You can continue to build procedural code for certain applications, it doesn’t mean its bad. But for high availablity and enterprise applications, I would go with a framework. The flexibiliy and architectural extensibility that it will give you, cannot be found in other approaches. It will be hard to grasp and you might think, why do all this work, all these calls. Object Oriented architecture is not easy and you also have to note, that some complexity on these approaches, will make you sacrifice speed. But the benefits will be tremendous.

    Your comment about extending my XMLParser to read fusebox files? well, I believe it is a genius idea. Maybe someone can help me create a fusebox parser plugin, that can make coldbox and fusebox applications mingle with each other. I am all for that, extensibilty.

    Jeff, please do not get offended by my comments. I really would like more of your feedback and clear anything up with you. You can contact me anytime at I would love to hear your thoughts and ideas. Please do.


  10. Aaron Greenlee said, on April 25, 2009 at 6:14 pm

    ColdBox Rocks!

  11. Patrick Winterton said, on September 24, 2011 at 11:35 am

    Coldbox looks very good. My only worry is that the documentation – massive though it is – is *painfully* badly written. If only somebody could go through it and correct all the spelling and grammatical mistakes so that it’s readable!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: