> 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.
Well, it's certainly possible that I don't know enough about it. I don't write Fusebox applications from scratch, although I do work on other people's Fusebox applications very often. I suspect that a lot of my distaste for Fusebox stems from that. The problem that I run into, simply stated, is that Fusebox developers spend too much time organizing their CF code, and not enough time figuring out what should be in CF and what shouldn't, or what should be done at runtime and what shouldn't. For example, I can't count the times that I've seen code like this in Fusebox (and non-Fusebox) applications: <cfquery name="foo" ...> SELECT a bunch of records </cfquery> <cfloop query="foo" ...> ... do a bunch of calculations, and/or execute other queries </cfloop> When I see something like that, I'm inclined to think that the developers should spend less time learning Fusebox, and more time learning SQL. > 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. I think you've done a very good job with this response, for what that's worth. > 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 submit that this bump is inconsequential, and that the bump in moving to Fusebox may be greater. But I don't think it makes much difference either way. My experience has been that the CF code itself tends to be easy to figure out. > The framework also provides a very raw form of documentation > for the application. > ... > 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? That strikes me as something that could be a compelling argument, at least if you don't already have some documentation process for this already. Do you find yourself going beyond this "raw form of documentation" anyway, though? 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
