Dave, the argument that Fusebox "doesn't solve any real problems" is a very interesting perspective, and one I haven't really heard before. I can't say I agree with it, but I certainly see it's validity. In fact, it's probably one of the more valid arguments "against" Fusebox that I've heard, and certainly one that can't be relegated to the "he/she just doesn't know enough about Fusebox" category.
This is a long email, and I've taken way more time than I should have to carefully craft a cohesive response. I've attempted to keep my pro-Fusebox bias out of the picture, with purely objective references to it. I suspect that both "sides" could use this effectively as an argument for themselves, but hopefully intelligence will overcome petty differences, and this will provide a solid description of Fusebox from one who intimately understands it's inner workings, but isn't trying to push it on the world. ------------------------------------------------------------------------ In my mind, Fusebox isn't trying to solve an explicit problem. I see Fusebox as two different things that are bound together to some degree. First is a set of conventions, and second is the framework code itself. The conventions are rather arbitrary, as conventions tend to be. However, while the widespread use of Fusebox doesn't make those conventions any more valid that another set, it does make them more meaningful, since conventions are only useful if a significant population uses them (not much of a convention otherwise). If developer X understands and uses Fusebox conventions for development, he'll a bit of trouble going to a new company that uses different conventions. However, the odds of that new company also using Fusebox conventions is far greater than if he'd been using conventions unique to him or his old company. In any Fusebox app, if you see a file that starts with "dsp_" you instantly know that it has very little logic, if any, and outputs something to the client, usually HTML. You might use "d_" prefixes, maybe it's a directory for display template, I don't know, so I'd have to learn them if I took over your app. If we're both using Fusebox, that bump, however inconsequential it is, would not exist. I group XFAs in the conventions section, because you can certainly write an app that makes full use of the Fusebox framework without using a single XFA. That's a blunder, but absolutely doable. As the list has shown today, there are a bunch of different options, and if Fusebox didn't have the concept of XFAs built into it, I'd find another way to do the same thing. Eventually though, enough Fusebox users would probably start doing it the same way that it'd get incorporated into the Fusebox conventions, which is how we got to where we are now anyway. In my opinion, these shared conventions are probably the more valuable. They have existed across versions of Fusebox, and I find I use them even when I'm not doing Fusebox work (on existing, non-FB sites, for example). They make my job easier, because I never have to think about how to do certain tasks, I just do them the same way I always do. Yes, any conventions would fit this bill, but I have a better chance of someone else understanding Fusebox conventions than something I've created for my own use. Fusedocs are also a convention, although one that probably is less prevalent than the others. Documentation exists in many formats, and everyone can pretty much read every format. However, Fusedocs are reasonably unique in that they are also machine readable, because they are entirely XML. That allows an enormous number of tools to be written to help the developer. Steve Nelson has written several, I wrote something akin to the javadoc utility (generates HTML documentation), and there are others out there. Secondly, the framework. Like the conventions, the framework enforces discipline on the coder, except at an organizational level. Simply using conventions at this level would certainly work, but it helps (at least for me) to have something there to ensure I'm following the right path. Maintaining that discipline without any checks would be a daunting task. Keeping those conventions in place, especially over the course of an application's lifecycle, is difficult, because there are no large jumps, it's a series of small changes, which may slowly and imperceptibly gravitate from the original conventions. The framework also provides a very raw form of documentation for the application. I can look at the circuit list of an Fusebox app (a single file), and get a reasonable idea about what the app does, and how it's structured. That's nothing that properly maintained external documentation can't accomplish, but if the code itself gives you the road map, there's nothing to get out of sync. If I need a finer grained look at the app, I can start opening circuit definition files (fbx_Switch or circuit.xml) and see exactly how the different modules flow within and between themselves. This is still a very small set of files from the app, and I have a very complete picture of how the entire app is laid out, and how the pieces fit together to form a consistent whole. If that's still not enough detail, I can start opening up single code files (fuses) and see how they work. Each one has comments explaining what it does, what variables it depends on, and what variables it generates, so I don't have to look through code, I can read prose. When I go back to old apps I haven't touched in a while, having that roadmap is infinitely valuable. I can easily get to exactly the code I need, and make my changes without having to remember how the rest of the app works. Now, you can certainly say that the "roadmap" aspect of Fusebox could easily be duplicated with a non-Fusebox framework, or no framework at all. But if there is already a tool that takes care of all the administrative bookkeeping in dealing with making that roadmap also the functional driver for your app, why not use it? I don't think that it's a coincidence that Struts is the definitive JSP/Servlets framework and that it uses an XML configuration file that declaratively controls the application's flow. I don't see it as a coincidence that FB4 has gone down this same road. It's fantastic, once you start using it, because it abstracts application flow from application processing. In other words the flow of the application is statically dictated by an architect, rather than being controlled by programming that is indistinguishable from, and perhaps even intermixed with, the application itself. ------------------------------------------------------------------------ cheers, barneyb --- Barney Boisvert, Senior Development Engineer AudienceCentral [EMAIL PROTECTED] voice : 360.756.8080 x12 fax : 360.647.5351 www.audiencecentral.com > -----Original Message----- > From: Dave Watts [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 17, 2003 4:34 PM > To: CF-Talk > Subject: RE: Cons to Fusebox > > > > I'm right with you Michael. I've heard from plenty of folks > > just itching for a chance to rip on Fusebox (or any topic at > > all, actually). But when it comes to actually delivering a > > superior solution, folks tend to fall suspiciously silent... > > > > I would switch from Fusebox to something else in 5 seconds if > > someone could present a truly superior alternative. Thus far > > (and I've been looking for years), no one's actually delivered. > > Perhaps you're looking for the wrong thing. What is the problem that is > solved by Fusebox? My complaint with it, my argument against it > if you will, > is that it doesn't solve any real problems that I've seen with web > application development. If there's no problem, how can anyone present a > solution to that problem? > > My solution, such as it is, simply requires a judicious application of > common sense. The reason that I like CF better than any other web > application development language I've seen - Java, ASP.NET, whatever - is > that it is strikingly simple. It allows me to do the typical > tasks in a web > application without even having to think about syntax or complexity. I've > worked with CF applications large and small, and still, as long as I can > understand the data model and the intent of the application from an > end-user's perspective, I can easily read the CFML code and figure out > what's going on. That's the least of my problems. > > Now, I won't go so far as to say "Fusebox is bad", because > honestly, I don't > really think it's bad. I just don't think that it makes any difference, in > the vast majority of applications in which it's used. I don't > think it makes > it easier for developers to move to new projects, any more than say, > variable naming conventions do. As with variable naming conventions, it's > hard to make an argument that it's bad, but it's just as hard to make the > counterargument that it's good - conventions are just that, nothing more. > > 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
