CFC-Only Version of Fusebox
I just gave a presentation to the Maryland ColdFusion user group about an experimental framework i’ve been goofing around with. In a nutshell it looks and feels just like MVC-Fusebox, but has no XML and has no core files. It simply uses CFML and CFCs. It doesn’t require any special include files or any extended components.
Don’t get me wrong, i still love Fusebox, but with the introduction of the <INVOKE> tag I started to wonder if Fusebox was actually mixing two frameworks in one. There appears to be a one to one correlation between many of the Fusebox tags and CFML tags. It was as if the mothership was finally giving us what we’d been asking for… for 8 years! …but no one has noticed.
For the last year or so, in my spare time, I’ve been playing around with creating the same MVC organization in Fusebox, but without any XML, or any ‘core’ files. I presented these ideas to the Maryland CFUG just to see if I am completely nuts or not. Besides some laptop/projector issues, it went well.
I’m going to post more about my ideas in the next couple weeks along with presenting this topic at the 2007 Frameworks conference.
Did they record the presentation Steve? I would really like to see it.
Comment by Kevin Roche — November 17, 2006 @ 12:00 am
No, it wasn’t recorded. But i have created some viewlets that i’ll publish shortly. They’ll walk through how it all works.
Comment by Steve Nelson — November 17, 2006 @ 12:00 am
I would love to hear more about your framework. Frameworks / Methodologies without core files are very intriguing.
Comment by Kris Brixon — November 19, 2006 @ 12:00 am
This is great to read Steve and it’s funny I recall discussing these sorts of things with Pat Quinn some time ago. I felt that using CFC’s in Fusebox sort of felt awkward and jumped us out of the FuseBox framework. I realize this is probably a different take on what you are meaning here and like others I will be really interested in what you post further.
I did have a quick question, do you feel that FuseBox 5 integrates better with the CFC paradigm?
Comment by Mike Brunt — November 19, 2006 @ 12:00 am
Kris, i’m going to post a whole bunch more about this as i free up some time from real work. Of course the concepts are pretty simple, so i hope i don’t become too repentitive.
Comment by Steve Nelson — November 19, 2006 @ 12:00 am
Mike, i’d be willing to bet a shiny nickel that your ideas and mine aren’t too far off. I agree completely that CFCs in Fusebox feel awkward.
I think a framework should ultimately provide a map of how an application works for the next developer(s). Fusebox does that quite well by itself. Although by introducing CFCs, it in effect creates two sets of maps. If you put all of your model code in CFCs, then you have one set of maps for the Model code in CFCs and two sets of maps for the Controller and View in Fusebox XML. So the next programmer needs to be proficient in both FB XML and CFCs.
Why not cut out the middle man and put it all in CFCs?
Comment by Steve Nelson — November 19, 2006 @ 12:00 am
Steve you captured my view of application development so well.
"I think a framework should ultimately provide a map of how an application works for the next developer(s)."
Someone once asked me what I think about as I approach a development project and my answer was "what happens after I leave!".
Comment by Mike Brunt — November 20, 2006 @ 12:00 am
… would love to learn more about your framework, do you have any materials available?
Comment by Rich Leach — January 11, 2007 @ 12:00 am
Yes, more more!
Comment by MF — January 24, 2007 @ 12:00 am
Can anyone speak to how this framework might integrate with ORM like Reactor? I would think it would be "cake" since Reactor is all CFCs too…
Comment by MF — January 24, 2007 @ 12:00 am
I am very interested in learning more too! I cannot make it to the conference, but will stay tuned to your blog Steve to hear (and hopefully see) more about the framework. This sounds very interesting!
Comment by Jason — January 25, 2007 @ 12:00 am
I’ll post the codebase i’m going to demonstrate at the conference so you can see it. Of course i need to give the presentation first.
Comment by Steve Nelson — January 25, 2007 @ 12:00 am
"I hope you all don’t think i’m against any of the current frameworks. I think they’re great. At the same time I think healthy arguments about how we write applications is a good thing. So please bring a healthy dose of skepticism and find holes in my ideas."
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!
Comment by MF — January 25, 2007 @ 12:00 am
I still make use of dsp files even with this approach because otherwise the CFCs just become outrageously long. I mean imagine having 10 HTML pages inside of a single CFC. You could do it, it just becomes a really big file.
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.
Comment by Steve Nelson — January 25, 2007 @ 12:00 am
@MF,
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.
Comment by Josh Nathanson — January 29, 2007 @ 12:00 am
MF — or ObjectBreeze, my personal favorite (no bean setter/getter quasi-Java OOP to fool with)
Comment by Ron — February 13, 2007 @ 12:00 am
Steve, are you in a position to do an update on this proposition (CFC-only MVC)?
Comment by Peter Robertson — June 1, 2008 @ 12:00 am