I too could never buy into Fusebox, I remember being excited initially of the concepts of independently operating components, however I could see accomplishing many of these elements without the somewhat intense task of running every single request through the index.cfm page, and ditching the eminently useful application.cfm, among other elements I didn't like.
What Fusebox did most for me was to really get me thinking creatively about how to encapsulate processes and objects within CMFL. Somewhat as an aside, one of the real pains for me in when working on a fusebox site is a nifty feature in DW that allows you to open any file from a path in the page... but it is less than effective when the url for that form or href is always going to index.cfm instead of employee_form.cfm... /shrug - Calvin ----- Original Message ----- From: "Brian Kotek" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Thursday, July 17, 2003 6:03 PM Subject: Cons to Fusebox > OK, Dave, you're clearly of the lot who will never be convinced about the benefits of Fusebox. That's fine. But I'll go ahead and end this here so that it doesn't degenerate into a series of tit-for-tat exchanges that won't convince anyone of anything. Obviously, I disagree with virtually all of what you say as well, and we could do this for days, which I don't care to do. Everyone is entitled to their opinion. > > Regards, > > Brian > > >> Dave, I'm not talking about navigation elements. I'm talking > >> about application actions, like clicking on a product to get > >> product details, clicking a breadcrumb link to get to that > >> page, clicking sort in a table of data to order on that > >> column, or any one of an unlimited number of links and forms > >> that make up a web application that are separate from global > >> site navigation. > > > >Again, though, these are navigation elements. They're not "global site > >navigation", but they shouldn't be repeated in too many places. In your > >example of clicking on a product to get product details, I would naturally > >assume that the page which lets you click on a product would be part of the > >same module that lets you see product details, and both pages are likely to > >be in the same directory anyway. The same would hold true for sortable > >tables, and most of the other "unlimited number of links and forms that make > >up a web application". > > > >> There's dozens of ways to do anything in programming. The > >> point of Fusebox is that it brings together lots and lots of > >> these good ideas into a common framework that is easy to > >> learn, use, and maintain. There's a whole lot of benefits to > >> Fusebox beyond just circuits...it just so happens that > >> circuits are what was asked about. > > > >While there are many ways to do almost anything, I'm not convinced that all > >the ideas within the common framework of Fusebox are all that good. And, if > >you're trying to convince us why circuits are useful, it's not helpful to > >say "well, Fusebox has all these other good things too!" > > > >> hmmm...well, that's OK. For me, problems are things like > >> creating a sturdy architecture that consists of well-defined, > >> encapsulated components, and building applications that are > >> easy to maintain while incorporating a great number of > >> best-practices. Fusebox is a great way to confront these > >> problems, but it is not the only way. > > > >Again, I'm not convinced that it's even a great way, of course. I'm not > >convinced that it helps or hinders implementation of best practices. My > >experience with Fusebox is, at this point, pretty extensive. I've analyzed > >many CF applications. A lot of these were in Fusebox. I tend to find the > >same problems in both the Fusebox and non-Fusebox applications. Unnecessary > >abstraction does not count as a best practice. > > > >On the other hand, I haven't found it to be a sign of a poorly-constructed > >application, either. I've seen good Fusebox applications and bad non-Fusebox > >applications. But how well-defined and encapsulated can a component be, when > >it's tightly coupled to your database schema? > > > >> But using a standard like Fusebox makes is very easy to > >> let others maintain the code, because they understand how > >> it works. The danger with custom or "secret" methodologies > >> is always the fact that before anyone can work on it they > >> have to learn the approach used. > > > >As a CF developer, I've yet to see a "secret" methodology, but I hear this a > >lot from Fusebox advocates. Here are some samples from John > >Quarto-von-Tivadar: > > > >"Or if you're a larger shop that has a vested interest in a 'secret' > >methodology -- much like the people of Florence at one time gave > >Michaelangelo's David a FigLeaf, which only serves to create interest in > >what is covered up-- then any open publically known framework, Fusebox or > >otherwise, has to be spun a certain way since the heart of the business > >centers on one's 'secret sauce'" > > > >"... advantages lie ... in Fusebox's adaptability to their local needs > >without having to customize it without creating dependencies on "guruness" > >or "secret sauce". let's face it: if you're a Dinowitz or a Corfield or a > >Liotta, you don't *need* Fusebox, cuz you're bright and you've got a > >million other tricks in your arsenal. But what about the other 199,997 > >CF'ers? The best bet they have to get to the point where they can pick > >and choose the framework that suits them best is to use a known, > >standardized framework that solidifies sound practices." > > > >But within source code, there are no secrets - everything's there for all to > >see. Within a very simple language like CFML, it's even easier. The > >complexity often tends to lie outside of CF, anyway, and Fusebox doesn't > >really tell you anything except how to organize your CF code. The biggest > >problem I run into, when analyzing someone's application, tends to be > >thoroughly understanding the choices made within the data schema. Once I > >understand that, the rest follows pretty easily. > > > >As for "guruness", I think that competence would be a sufficient substitute. > >A competent team of developers will not have any trouble reading and > >understanding a CF application. No "secret sauce" is necessary. > > > >> Again, I don't think Fusebox is all-powerful...just very > >> useful in many situations. > > > >There are places where standardization is especially useful. For example, > >it's useful to have everyone agree to drive on one side of the road. There > >are, however, places where it's less useful, and in my opinion, a lot of the > >places where Fusebox brings standardization are not that useful. > > > >Dave Watts, CTO, Fig Leaf Software > >http://www.figleaf.com/ > >voice: (202) 797-5496 > >fax: (202) 797-5444 > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
