That makes a lot of sense and is consistent with my takeover Fusebox experiences so far. Thanks for the insight.
Frameworks and authoring tools definitely walk a fine line trying to find a balance between enforcing better/best practices while allowing expressive and preferential freedom. I love strictly typed languages because they take no prisoners. I also love in-client spell checking because it points out a potential mistake without taking away my ability to use non-standard words (slang) and purposeful phonetic spelling. I guess we can't really BLAME Fusebox for the borderline ridiculous products that people produce with it anymore than we can blame Photoshop for the catastrophes people design with it. Derogatory comment officially retracted. On Sun, Oct 19, 2008 at 2:36 PM, Barney Boisvert <[EMAIL PROTECTED]>wrote: > > One thing to consider about the history of Fusebox is that there are a > huge number of applications out there that use it for "checklist > compliance", without any real understanding on the part of the > developers about what problems front controller frameworks are > designed to solve, or why one should be used at all. Since Fusebox > was the only front controller framework available for a long time, > most applications that fall into this category are built with Fusebox. > This persists through today, largely because Fusebox does not require > CFCs, and the simple fact of the matter is that there are a LOT of CF > developers out there that don't use CFCs for anything, preferring to > stick to the CFINCLUDE based procedural mindset. > > The bottom line is that it's really easy (and fairly common) to build > horrible apps using Fusebox. It's harder to build a horrible > Model-Glue or Mach-II app, simply because you have to know more about > OO architecture in order to make something functional, and that > additional knowledge typically brings with it a more in-depth > understanding of what the goals of the framework are and how best to > leverage it. Which isn't to say there are no bad MG/MII apps, but > they make up a smaller subset of all MG/MII apps compared to Fusebox > because of the height of the learning curve. > > So don't judge a framework by the apps that use it. Anyone can misuse > a tool; doing so doesn't decrease the utility of that tool to others. > > I happen to think that Fusebox is a good solution for most > applications. Certain classes of apps were better served by the > Model-Glue framework until Fusebox 5.5 added some of the dynamic > functionality that Fusebox was missing to that point. But all things > considered, any of the big 4 front controller frameworks are fairly > heavy. If you're embracing the ideal of a very thin UI layer > (especially if you have a multi-UI app - desktop html, mobile html, > flex, etc.) the required functionality of the front controller > framework becomes pretty minimal, with most of your effort focused on > the service layer and below. As such, the ease of Fusebox is a big > boon to me, though I'll admit that I find even it overly heavy for a > lot of apps and use a hugely stripped down version for most projects. > > cheers, > barneyb > > On Sun, Oct 19, 2008 at 8:18 AM, David McGuigan <[EMAIL PROTECTED]> > wrote: > > In my opinion Fusebox is a good choice if you are a masochist. When I > > inherited my first Fusebox app, I then also promised myself and all of my > > future children that it would also be my last. (Oh, snap). > > > > > > On Sat, Oct 18, 2008 at 8:53 PM, Mark Ireland <[EMAIL PROTECTED]> > > wrote: > >> > >> There is a nice clue to be found in all this good advice. > >> > >> "Fusebox can be easily used to develop something as simple as a 2-page > >> application or as complex as an entire corporate platform". > >> > >> Yes it can be used for something simple, but I say it definitely should > >> not be. I have inherited dozens of old fusebox apps where fusebox was > just > >> the wrong choice because the apps are all simple. > >> > >> In my opinion Fusebox is a good choice if your app has complex > navigation. > >> Otherwise consider something else. > >> > >> ________________________________ > >> From: [EMAIL PROTECTED] > >> Subject: [CFCDEV] Re: Coldbox. What do people think? > >> Date: Sat, 18 Oct 2008 16:36:48 -0500 > >> To: [email protected] > >> > >> Hmmmmm... I think I disagree with that statement. > >> Honestly, I think that title is due to Fusebox... ColdBox is well-done > >> without a doubt, but Fusebox has been around for 1000 years, is on it's > 5th > >> version, has a variant that follows ColdBox's lead in convention-based > >> configuration, and the XML-using variant can be used in the classic > model > >> with modular cfm templates or in the OO/MVC model with CFCs and > services, > >> etc. So as far as the most robust, most widely used ColdFusion > framework, > >> Fusebox wins that contest hands-down. Considering that at least 5 books > have > >> been published about Fusebox, that it's been around since 1997 as a > >> methodology and 2001 as a complete framework... let's just say it has an > >> impressive resume. > >> It's definitely the most-used and longest-lived of all the ColdFusion > >> front-end frameworks, and it's undergone the most development since it's > >> original release as a framework in 2001. As for robustness, it leaves > almost > >> the entire architecture up to the devleoper and, it can be MVC or not, > etc. > >> The net effect of this is that Fusebox can be easily used to develop > >> something as simple as a 2-page application or as complex as an entire > >> corporate platform. And, since it compiles it's pages down to inline > CFML > >> that are simply grabbed from cache after being run once, it's also > arguably > >> the most performant... > >> > >> As for the frameworks out there that mandate CFCs and an MVC > architecture, > >> ColdBox is an excellent choice... but there are things that are > surprisingly > >> incomplete, like the IoC plugin (which really only matters if you're > using > >> ColdSpring or Light Wire). Since ColdBox keeps your ColdSpring bean > factory > >> captive, using things like parent bean factories is challenging... and > as > >> for the concept of no XML, that only works if you want to build a simple > >> site using componentName.methodName as your events. If you want to do > >> anything much fancier than that (like implicit invocation) you have to > get > >> fancy, build your own interceptors, and configure them using XML. So > while > >> it definitely has less XML than ModelGlue or Mach-II, it's certaily not > a > >> ero-XML proposition for anything it's straight-up core functionality. > >> Actually even for the core functionality it's not a zero-XML > framework... > >> you still have an XML config file that's very similar to fusebox.xml. > >> Honestly, there's really nothing you can do in ColdBox that you can't do > >> in any of the others, especially if you look at MG 3 (aka MG:Gesture). > >> Mach-II may be there also, but my Mach-II is rusty and I haven't kept up > >> that well. > >> The only thing that ColdBox has going for it beyond the others is the > >> documentation, and Fusebox gives it a run for its money at that. > Although I > >> have found the ColdBox doco hard to use and harder to find... that's got > to > >> be just me, because everyone else seems to think it's beyond cool. > >> So yeah, I like ColdBox. It's a nice framework. They're all nice > >> frameworks, and they all do pretty much the same thing in different > ways. > >> The most developed and most robust, however, is unquestionably > Fusebox... > >> it's got a 5-year headstart on ColdBox. > >> Just my $2... > >> Laterz, > >> J > >> On Oct 18, 2008, at 12:35 PM, David McGuigan wrote: > >> > >> In my CF frameworks research ColdBox stood out far and away as the > >> most-developed, robust and advanced MVC choice on the market by far. > >> > >> > >> ________________________________ > >> > > > > > > > > > > > > > -- > Barney Boisvert > [EMAIL PROTECTED] > http://www.barneyb.com/ > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
