Viewing By Entry / Main
April 15, 2007
Recently I've been getting an increasing number of requests for my thoughts on the ColdBox application framework by Luis Majano. I've really only given it a cursory glance because, well, I've already spent a lot of time evaluating and using lots of other frameworks and I just didn't have space and time to start in on a brand new framework.

I was impressed by the amount and depth of documentation that Luis has created - there is also a good roadmap for folks new to the framework, listing articles to read and tutorials to follow.

Since I have not actually tried the framework, I'd like to hear from any of you who have tried it. Did you switch to ColdBox from another framework? Did you try ColdBox and decide not to use it? What do you like? What don't you like?

Comments

i quite like the xml-less nature of coldbox and that's it's more tightly coupled to CFMX than MG

i've been using model-glue and i find the MVCX (meaning Model, Views, Controller AND XML) somewhat frustrating as it's not really DRY.

I like the approach of using CFML to define the application, CFML is just a lot more powerful. I don't want to being using XML as a programming language.

a lot of the XML vocabs for CFMX frameworks are just a subset of CFML, without all the functionality of CFML.

When google guice was released i saw a comment saying how great it was to not have to keep switching back to the struts xml file, which rang true with me.

being able to set values in the requestcontext directly feels a bit like old school CF

using eh (eventHandler) as a prefix for controllers looks ugly, but that's just a personal preference

just starting to try it today...


@zac: I too appreciate the absence of xml files in ColdBox. And, with the latest release of ColdBox, you are not required to use the "eh" prefix for controllers; its now merely a best-practice.

Most of my development in the past couple of years has been in Model-Glue and Fusebox, in the years before that, and switching to ColdBox has been an easy transition. Its integration with ColdSpring is clean and simple to use, the documentation is LENGTHY and helpful with numerous examples, and its performance and debugging output push it clear of the other frameworks.


I'm impressed by what I've seen so far with Coldbox. It's certainly helps getting started with that huge huge amount of information. I found it to be a lot more than ModelGlue, Reactor or Coldspring when I was learning them. Part of that is probably because there are like 10 sample aps that come with the framework.

As for the framework itself it's strangely simple in how it just works. One layout, one view, actions automatically call a specific method in a controller -- and that's pretty much it? Far more complexity when you dig into things of course, but for the basics it's easy to grasp. Think it lowers the barrier to entry too. I really like the idea of just writing the controllers and having which is called based on the URL though. Since most logic in a service layer already, it makes it easy to try to keep it clean, rather than trying to make small events. So far I'm impressed with it.


While I've not used it, it does seem like a very good, cleaned up and somewhat simplified evolution of the MG/MachII design.


I have evaluated Fusebox, Mach II and Model Glue in the past but never felt comfortable enough with them to build a site/app with. I just started getting familiar with ColdBox and plan on porting a production website I run to it.

What I like about ColdBox: - Very simple to understand Controllers and Event Handlers. - Event Handlers defined in a CFC instead of XML. I don't like the way other frameworks make use of XML. - Very good documentation. - Built in logging. - The view rendering is easy to understand. - Good support for internationalization.

There is a lot more to the framework but I haven't had the need to explore past the basics at this point.


I recently started learning Coldbox 2.0.0, so still have much to learn. I have primarily been using Fusebox 4+ for all of my apps and find that Coldbox has been a relatively easy transition. Reasons for trying Coldbox: - I wanted to try a new framework, simply for my own education - Wanted a framework to force me into the OOP world. I put that on the back burner for far too long and decided it was time to jump.

I, too, am extremely impressed with the documentation and example code/snippets. What I can't find in the docs, I have found in the numerous, well commented sample apps. I read all the docs prior to starting any code and found them to be clear and flowed well. It's obvious that Luis has put major time into the documentation. While one of the newest frameworks, it probably has the most complete documentation.

I really like the CFC based controller, leaving XML for the application configuration.

I like the view rendering mechanism, which feels similar to Fusebox. (I need more time on this for more complex layouts)

No parsed files to worry about is nice.

Coldspring integration appears nice, although I am a Coldspring fledgling. (I'm using Coldspring and Transfer in my first app)

Speed seems quite fast when in full development mode.

Miss the URL reload plugin for Firefox!

Still a little confused on caching. (I believe the docs were updated this weekend) The caching gets even deeper when you throw in Coldspring and Transfer and their caching abilities.

The previously mentioned "eh" prefix is not required in 2.0.0, so you can use your own naming convention for the CFCs.

Two thumbs-up so far!

Terry


As the previous posts have mentioned, one of the greatest strengths of this framework is the vast amount of documentation it has. I had the privilege of working with Luis in the past and I know of his inclination of being thorough in every project he undertakes, and ColdBox is no exception.

However, what I think is by far the greatest strength of Coldbox is the simplicity by which it implements the MVC approach. The current version of Coldbox contains lots of great bells and whistles, but the real power relies on the overall breakdown of how the application works:

- A single and generic front controller that can be reused as-is between applications,

- Cleanly defined event handlers for application-specific logic, in which every application action is clearly defined as a method on an event handler's cfc.

- Separation of the application's visual output between page layouts and views.

Having all these parts of an application clearly defined and structured makes the application a lot clearer to understand and follow, even when there is no prior knowledge of Coldbox. Furthermore, this kind of separation and the minimal reliance on XML dialects and obscure framework-specific constructs allow for (God forbid!) porting a Coldbox application away into some other MVC environment if the need arises.

Now, add on top of that: event handler caching, autoupdates, integrated logging, a dashboard, an extensive plugins library, coldspring and Transfer integration and you definitely have a killer "framework" in your hands.


Oscar: good points. However, one thing you point out that personally frustrates the heck out of me is that there's a huge array of separate pieces needed with all (?) CF frameworks to cover all of the bases, as compared to the newer generation of frameworks on PHP, Ruby, etc, which have all of the pieces needed built-in. This is a similar complaint with most of the Java frameworks - there's interoperability between different components but no simplified, unified approach that doesn't require tonnes of configuration. Coldbox is a great step towards the simplification that other frameworks bring, but it IMHO needs more tangible functionality added, like an ORM, UI & AJAX framework, etc.


ColdBox is reall great development kit; I am also inspired by the documentation of coldbox. I have not come across any other framework with this level of simplicity and power. Most importantly road-map of coldbox, soon there will be more things which none of other frameworks holds at one time.

ColdBox built-in cache module, extremely informative debuging, plugins->javaloader,messaging system, session, client management,bean factory, i18n, webservices, stringbuffer and many more cool plugins.

and coming transfer plugin, event based system, event raise, ses Friendly URLs, event caching and more.

coldbox does not require any prior knowledge of using any framework and this is really positive aspect of coldbox.


Hmm, it'll be interesting to see how people react to Fusebox 6 since that will allow XML-free development (and will almost certainly have an ORM-based scaffolding engine available as an add-on).

Fusebox already has lexicons for Reactor and Transfer and ColdSpring, support for SES URLs, fairly descriptive debugging output and lots of plugin points.

With Fusebox's new website in development and an all-new set of documentation also in the works, there's a lot on the Fusebox roadmap!


I am a jack of all trade master of none. Have worked with coldfusion for 6 or 7 years and really never thought about frameworks. A few month back decided I needed to get on framework band wagon and make my job easier. I looked at fusebox, mach-II, mode-glue and was dumb founded. I could no figure out where to start or how I was going to uses these frameworks. Then I stumbled upon Coldbox. After spend about 2 hours with the docs and asking Luis a question or two, which he also answers promptly. I had my first app up and running. It might not be much but it works. I am know in the planning stages of taking the web application I was handed 5 years ago and streamline it with Coldbox. To me there is no other framework to use. Kudos to Luis.


I messed around with it for two night.

I'm addicted.


I had never looked at till the interview with Luis for cfframeworks.com but I was impressed by the level of documentation - it's high on my 'to look at list'


I have been reading up on the popular frameworks but have not got to the point of committing myself to one. Got close with CFWheels.

But now, for all the reasons stated above, I am going to dive into ColdBox. It feels (smells) right.

Well done Luis.


I'm experienced in Mach II, Model-Glue, Cairngorm(flex), and Gaia(flash) frameworks. And now I'm a Coldbox fan. I've dropped MG in favor of CB 100% and converting all my production sites to it. It kicks the Dalai Lama's ass! Working with CB is like going to heaven (if it existed) and coming back alive!


Post Your Comments
Name:
Email Address:
Comments
*** Please note that all comments require moderation so it may be some time before your comment posts to this blog! ***
Remember My Information:
 



Hosting provided by