Brian: I appreciate all the effort you've been pouring into this thread. That said, allow *me* to back up a bit 8^).
I am familiar with FB3 and have had opportunities to use it and its various features. I've also spent some (but not enough) time going over FB4 and I'm fairly well aware of what new features it brings to the table. All that said, I was never actually interested in discussing the pros/cons of Fusebox (despite the unfortunate email subject). I was really interested (and still am) in the pros/cons of one aspect of Fusebox... the controller. The central index.cfm file that all requests must pass through. That said, this thread has become interesting to me in its own right. To date, the main and generic points that I've noticed being made in this thread are, in no particular order: 1) Some people love FB, others hate it, still others don't care, and everyone seems to be very passionate about it all (except maybe for those who don't care). 2) Fusebox doesn't offer anything that can't otherwise be accomplished, however, it essentially prepackages it for you so you don't have to worry about it. 3) Fusebox offers its own set of advantages and disadvantages (perceived or actual) and it's up to the individual developer/architect to determine whether or not the tradeoffs make sense for that developer or project. 4) Fusebox does have a learning curve (IMO, a pretty steep one if you want to truly and properly use all that FB offers) but once learned, you're in pretty good company (until the next release and then there usually seems to be another learning curve). 5) While I wouldn't call Fusebox the de facto ColdFusion framework (there are too many people/sites not using it for that) it is certainly the most popular and used ColdFusion framework out there. 6) Fusebox is not a panacea. It's just as easy to write crappy code in FB as it is to write crappy code without FB. >From my own perspective, and arguably for my own personal reasons, Fusebox tends to be too much for me. It doesn't overwhelm me, it just offers too much stuff that I don't feel I need, and doesn't offer other stuff that I do want. It also requires a style of managing/writing code that I don't find beneficial. I'm willing to be flexible and change my coding style and mannerisms when I see benefit in doing so but, again for my own reasons, I don't find FB's way of doing things to be beneficial to what I do. Finally, FB tends to restrict how projects can be organized. I don't know much about FLiP but what I do seems to be impractical for how my own experiences suggest most projects succeed. I recognize that any framework will restrict to some extent how you do what you do, but I find FB's restrictions to be too restrictive/impractical. -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: [EMAIL PROTECTED] WWW: http://www.evoch.com/ > -----Original Message----- > From: Brian Kotek [mailto:[EMAIL PROTECTED] > Sent: Friday, July 18, 2003 10:26 AM > To: CF-Talk > Subject: Cons to Fusebox > > > Mosh, I think we're getting wrapped up too much in specifics. > Let me back up for a moment. First, XFA's are not required, only > suggested. You can write an entire FB app without a single XFA. > They just offer some nice benefits, like: > > keeping decisions about application flow in the realm of the architect. > keeping decisions about application flow out of any individual code file. > allowing you to change at runtime how the application behaves. > allowing for components that respond differently in different situations. > > So, the decision on whether or not to use XFA's is a personal > one. If you think this is not worth the effort (though in reality > the effort required is neglegible), then you aren't required to use it. > > Regarding reuse and the question of building up end content from > smaller pieces, this too is a decision, not a requirement. But > having the ability to do this by adding a single attribute to an > XML element is pretty impressive, at least to me. Let me give a > more realistic example: > > Someone calls the controller to execute the fuseaction > "store.productDetails". The store circuit is targeted, and the > action productDetails is executed. productDetails is a > controller-level action so it doesn't do anything itself. > Instead it invokes a series of actions in the Model and the View > to complete the user's request. In this case, it might call the > model to query for product details, and the view to output those > product details. Simple enough so far. But now... > > We take the resulting formatted output and capture it in a > variable called a content component. So we have the formatted > product details wrapped up in a variable. But why stop there? > The controller can call more fuseactions in the Model and View, > maybe to get recently viewed items, items similar to the current > item being viewed, daily specials, etc. All of these are called > separately, each one is formatted, and the formatted output > captured in a content component variable. So we end up with a > bunch of these "building block" content variables. At the end of > the request, we can call a layout file that positions and outputs > all of the content components, formats it with global header and > footer, navigation, breadcrumb trail, whatever. > > The result is an extremely flexible layout. "Skinning" the site > so that users can customize the layout is now trivial. Altering > the layout is trivial. Altering any single component in the > layout is trivial because each call is encapsulated. And this is > all done in the circuit.xml file like this: > > <fuseaction name="productDetails"> > <set name="xfa.addtocart" value="store.addproducttocart"/> > <set name="xfa.productdetails" value="store.productDetails"/> > <do action="m_products.getProductDetails"/> > <do action="v_pages.productDetails" contentvariable="pageContent"/> > <do action="m_products.getRelatedProducts"/> > <do action="v_sidebarBlocks.relatedProducts" > contentvariable="relatedProducts"/> > <do action="m_products.getRecentlyViewedProducts"/> > <do action="v_sidebarBlocks.recentlyViewedProducts" > contentvariable="recentlyViewedProducts"/> > </fuseaction> > > You have one place to look to see what is happening, or to start > making changes. And this is as complicated as it gets...using an > MVC approach and creating multiple components to be used in the > final output. And this is only one approach...you don't HAVE to > do it like this, but I personally think it's a pretty useful way > to go about building a page for the user. > > Naturally there are ways to do this without Fusebox, but with FB4 > it's all at your fingertips, all you need to do is add the > "contentvariable" attribute to your <do> tag. > > Hopefully this example gets your wheels turning. But on the > other hand, it might seem too complicated if you aren't familiar > with Fusebox. Again, I would invite you to take a look at it for > yourself and make judgements based on that. If you do, please > don't hesitate to ask the Fusebox community any questions you > might come up with. > > Regards, > > Brian > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
