Items of note include: Application.cfc integration with allowImplicitFusebox and the onFuseboxApplicationStart() method, controller circuit written as a CFC (in fact, it's written entirely in <cfscript> just to make a point) with prefuseaction() and postfuseaction() methods, views relying on attributes scope (and that the event object shadows it). The model is unchanged from the classic 'ggcc3' version.

If you don't already have the database tables created, you'll want to download the original frameworks sample code and run the build tables code (in ggcc1 as I recall).

Feedback welcome, as always. One thing I'm not very happy with right now is the view / attributes scope dependence. Fusebox views have always been able to rely on variables scope but setting variables scope values, while possible, is quite ugly in a CFC controller:

I'm toying with the idea of:

which would sort of match how the event object (attributes scope) is handled:

Of course, instead of using a getter, I could just expose that scope directly like this:

which is somewhat more in keeping with the Fusebox idiom.

One question: In 5.1 I'm using multiple XML controller files to separate parts of my application into smaller, manageable modules. Will I be able to do that here as well?

I also like the fact that I won't have to deal with XML files in the model or views folder (if I understand what's going on correctly)

I kind of like the idea of just exposing that scope since that is how it's worked in the past. It's easier to read. However, I understand there are benefits to doing it the other way.

Thanks a lot for the sample app. That really helps me understand the changes to 5.5 more clearly.

It seems that it would cause a fork with the PHP version of Fusebox, although I don't know how popular that is in the first place.

In the end, I like the move to CFCs, I imagine it would offer some additional possibilities and keep you from having to duplicate CF functionality in the XML grammar.

The whole reason for make XML *optional* is feedback from the community that a lot of people do not like XML and feel it's a barrier to entry.

Mike Ritchie is tracking Fusebox 5.5 for his PHP version (he was in progress on Fusebox 5.1 for PHP but will likely jump straight to Fusebox 5.5 for PHP).

Hope that clarifies?

I absolutely LOVE being able to skip the XML, if I so desire. To me, this really opens up FB to many more apps. Also love the all-cfscript controller CFC :)

Looking forward to the official release!

ColdBox actually *does* use XML - to configure layouts and views as well as other application parameters.

Fusebox 5.5 allows you to programmatically configure the application without XML as well as allowing you to write circuits without XML. If you look at the sample code, you'll see the controller circuit is a CFC but the view circuit is just a directory containing .cfm files - and that still behaves like a circuit.

Fusebox 5.5 still allows all the traditional FB4 and FB5 apps to run so it supports several different styles of programming. ColdBox requires controllers (event handlers) to be written as CFCs which is just one possibility with Fusebox.

So, overall, I'd say they're more different than they are similar.

As for benefits, Fusebox has the largest community and the most documentation (including several books) - which is not to diminish the amazing work done by Luis on the ColdBox documentation!

I like the CFC controller. I can actually read it!

I suggest you join the Fusebox 5 mailing list (link on the fusebox.org website) and ask questions there.