> Wow, if you can look at the URL and "tell what file to > edit", you must have a gigantic amount of data-layer > logic stuffed into your display file for it all to be > in one place. I prefer the emphasis that Fusebox places > on separating logic from presentation.
Well, first of all, it's not usually my file in the first place. But anyway, no, that needn't be the case. When I write data-access logic, I tend to put it into stored procedures, where it belongs in my opinion. In that event, I don't really see the difference between this: <cfinclude template="qry_whatever.cfm"> ... presentation logic ... and this: <cfstoredproc ...> ... presentation logic ... But thanks for your concern. > Fusebox does not require you to use a variable for this, it's > only a suggestion. And one that my experience has found to > be a very useful one. A suggestion from whom? From you? From Fusebox? If it's not part of Fusebox, then what difference does it make when judging the suitability of Fusebox? > > I don't like (what I perceive to be) the underlying concept > > that web applications are like houses, built brick-by-brick, > > and that each of these "bricks" or modules needs to be as > > loosely coupled as possible to all the others. Not all code > > can be reused, not all modules are better off being as > > loosely coupled as possible, and in any case, such loose > > coupling is often impossible in fact since the data schema > > won't allow it. > > Maybe you should email the the creators of Java, or the folks > who wrote "The Pragmatic Programmer", any of the gang of four > books, or virtually any other widely respected software > engineering book, because they would strongly disagree that > decoupling is a bad thing. Furthermore, I have not had any > problems creating highly encapsulated modules with Fusebox, > regardless of data schema. Maybe you should reread my original statement, because it doesn't state that "decoupling is a bad thing". The fact remains that not everything can be modularized, nor should it be. There's no need to waste Bill Joy's time with this. Furthermore, I suspect that your "highly encapsulated modules" won't always work outside of the larger application in which they're contained, due to their dependencies on the data schema. If that's not the case, then I submit that you're not spending enough time designing data schemas. > > I don't like the way that Fusebox adherents tend to misuse > > common terms, like "methodology", but that's not really a > > complaint against Fusebox. I do suspect that there's > > something to the correlation between Fusebox and its > >users, but I don't know what that would be. > > Methodology: a body of methods, rules, and postulates > employed by a discipline : a particular procedure or set of > procedures. This definition fits Fusebox perfectly. As my philosophy professor told me early on, dictionary definitions are useless for anything beyond basic usage. The fact is, within the programming world, words like "methodology" and "framework" have more specific, narrow meanings. Within that world, I don't think Fusebox is a methodology. While you're chatting with Bill Joy, you might ask him about that. > > > And I can promise you that there are PLENTY of people that > > > don't use Fusebox and are quite ready to attack at any time. > > > I haven't seen much of that in this discussion, which is very > > > refreshing. > > > > Yes, the hordes of Fusebox attackers are unbearable, aren't > > they? It must be terrible, what with everyone constantly > > telling you to stop using it. > > I must admit that sometimes dealing with the naysayers can > be quite exhausting. Your sarcasm detector seems to be having problems. > It's very easy to find flaws in other people's ideas. Yes, but some ideas are more flawed than others. > What is virtually always the case is that someone repeatedly > attacks the idea without ever providing any solution that > is superior (don't read too much into this if you don't > want to). I submit that I have provided a solution that is superior. My solution, again, is the judicious application of common sense. You want to separate presentation logic from business logic from data-access logic? You can do that with all the tools that the language provides, without using Fusebox - we've been doing that since CF 1.5 came out here at Fig Leaf. Custom tags. User-defined functions. CFCs. Java classes. No "secret sauce" necessary, no special framework required. > I have never said that Fusebox will solve all development > problems. Why must you make such sweeping generalities like > that? I think you'll be hard-pressed to find a quote from me that says that. That's the beauty of written conversation, isn't it? What I did say was this: "From my perspective, it looks like there are a lot of people trying to convince other people that Fusebox will solve all of their web application development problems." The value of Fusebox has been debated many, many times on this list among other places, and its proponents often make very high claims for it, to say the least. I dispute those claims. > I didn't come here to convince anyone of anything, but > to answer questions and then, later, to defend Fusebox from > those that say it is "bad" but offer no better solution > themselves. That's patently ridiculous. Of course, you came here to convince people that Fusebox is good. But, of course, there's nothing wrong with that. If you honestly think that it's a good thing, it's only natural to want to convince others of the same thing. You'll notice that I'm not trying as hard to convince people not to use Fusebox. Personally, I don't really care whether people use it or not - it doesn't affect my business one way or another. But, when asked, I'm going to say that I don't care for it too much, myself. > When compared to the alternatives (no structure at all, > someone's personal best guess at something, or some superior > approach that conspicuously manages to never actually be > revealed) it is the best thing I've found so far. And about > 17,000 other people agree. Really? Seventeen thousand other people agree? Well then, I must be completely wrong. > Does it try to incorporate the best-practice advice of many > highly respected developers and software engineers, such as > abstraction, encapsulation, decoupling, and orthogonality? Well, it certainly sounds fully buzzword-compliant. But I doubt you'll find many software engineers who'll just say you should abstract everything that can be abstracted; that you should encapsulate everything that can be encapsulated; decouple everything that should be decoupled. To every thing there is a season, and all that. When I first started doing web stuff, I learned how to write CGI programs in Visual Basic. The way that this was done was similar in some respects to Fusebox, actually - you'd write one actual program, whatever.exe, and that program would contain many subroutines which you'd invoke via URL parameters. ISAPI applications are often similar in that respect. I found it quite annoying for reasons not directly relevant here, and soon ran into CF. To my mind, Fusebox takes something that is very simple - CF, a scripting language - and treats it as if it were far more complex. There's a reason that programmers using languages like Java and C# to build web applications tend to use application frameworks - those languages are comparatively hard, and you're much more likely to screw things up if you're not careful, generally speaking. If I want complexity, I might as well just use Java. 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 Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
