> 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 Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
