I’m glad to see that I’m not the only one who questions the FB4/5 "improvements". I too am just as happy working in FB3 as the XML config files just don’t feel right to me. Although I can’t make the Frameworks conference I’m really curious to see more details on Steve’s CFC only approach to FB.

Steve, on the contrary… I am CERTAIN that you are not against any particular frameworks or the direction they are going. I watched as fusebox evolved, and the deliberate approach you took all the time you were involved.

My take on things is simple:

I’ve loved what fusebox did for me long before OO CF was such a big discussion. FB2 gave me footing, FB3 is what all my current sites are on, and when I tried FB5, I was able to deliver, but not as efficiently. I know some of it was learning curve, but even now with a good level of proficiency, my productivity has gone back a couple steps with the FB5 app.

CF attracts so many, first because the simplicity-yet-power of it makes people very productive, very quickly. It’s been like that since CF3.1.

When FB2 arrived, it made developers productive AND organized.

When FB3 arrived, it made developers more productive, more organized, and gave a health dose to some tried-and-true OO concepts.

FB5 offers performance, but for me at least, feels like a step further away from the rapid productivity I experienced when I first became a CF’er, and later when I signed on full-bore with FB3 and churned out 50 apps or sites in a very short period of time… and to this day still enjoy how easy they are to maintain.

Along the way, CF has evolved dramatically, making some convolutions and contortions less necessary. It only makes sense that we take a step back now and look at what is provided by MX, 7, and soon, 8, and really see where we are duplicating efforts in our love-of-frameworks atmosphere, at the expense of simplicity and performance.

Your concept is attractive because it goes back to core simplicity – CFCs for everything. I’ve even wondered why we need dsp_ files, when our "display" CFCs are more than capable of doing the output themselves (which I’m sure makes some folks cringe, but think about it for a minute…).

Using best practices solely with CFCs could render the same results as full-bore fusebox 5, without the learning, coding, and performance overhead of XML, the more-often-than-not overkill of "portability" between CF and PHP and whatever, and heavier and heavier core files that shield the developer more and more from some important parts of their apps.

An eventual comparison chart between what your approach might offer and what fusebox 5, model-glue, or mach ii offers will eventually be in order, and then, the people can decide.

To me, this is an attractive alternative for those who know FB3 and are deciding where to go next to "stay on top" with OO without making a huge dent in their productivity. Especially small or one man shops!

Sorry for the length… guess I’m getting really into this!

Same thing wrt to qry and act files. I like them for the same reason i like dsp files. BUT…Some people don’t. This approach doesn’t care. Use them or don’t. To me, that’s just architectural style as opposed to an absolute end all be all rule.