CFUnited 2008:
Calendar
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 |
Recent Entries
ColdFusion SQL Injection
How to make the full path appear in the finder title (OS X)
Recent Comments
Enabling desktop wallpaper on remote desktop terminal services
tstevens said: Worked like a champ for me! This was driving me crazy. Wasn't sure if it was my RDP config, my virtu...
[more]
ColdFusion SQL Injection
Dan G. Switzer, II said: I was having problems with the script doing weird things do to the logic used to find the open CFQUE...
[more]
ColdFusion SQL Injection
Brad Wood said: Duncan, I have already blogged a fix to make it scan .cfm, .cfml, and .cfc files.
http://www.codersr...
[more]
ColdFusion SQL Injection
duncan said: Also doesn't seem to work where a query would have a LIKE in it, e.g.
WHERE name like '#form.name#%...
[more]
ColdFusion SQL Injection
duncan said: What about changing it to also scan .cfc files?
[more]
Archives By Subject
Business of Software (5) [RSS]
ColdFusion (321) [RSS]
Conferences (7) [RSS]
Databases (88) [RSS]
Flex & Flash (109) [RSS]
Fusebox (87) [RSS]
General Development (33) [RSS]
Google (9) [RSS]
Hardware (5) [RSS]
JVM & Java (132) [RSS]
Linux (20) [RSS]
Macintosh (1) [RSS]
Miscellaneous (254) [RSS]
Performance (8) [RSS]
SeeFusion (36) [RSS]
Shan's Simple Examples (7) [RSS]
User Interface (3) [RSS]
Windows (5) [RSS]
Archives By Poster
Daryl Banttari (11)
Nat Papovich (33)
Patrick Quinn (36)
Shannon Hicks (22)
Steve Nelson (22)
Tyson Vanek (3)
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.
I did have a quick question, do you feel that FuseBox 5 integrates better with the CFC paradigm?
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?
"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!".
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.
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.