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 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
