Brian, you are starting to come across as being aggresively opposed to this conversation.
As for your message: I work pretty much in the same fashion Dave has indicated. However, I have absolutely no data layer logic on my display page. Any data layer logic is accessed via a function call to a business rule object, and the business rule object accesses whatever data layer objects it needs. I then have my basic data that I place into the page as needed. So, by simply applying OOP principles, I achieve the abstraction and encapsulation you and other FB proponents seem to be offering as what makes FB so good. Seing as all actions start from a page request, why not let the page determine what needs to be done? FB does the same thing, using a different method (index.cfm switch case). In both cases (FB vs OOP), the end result is a page that is rendered correctly and using some kind of architecture. I have had to occasionally use a dynamic destination for my forms - using a variable made sense in these cases. However, I didn't need to use FB to do this, and using the OOP principles, this is very simple to implement to what ever degree of complexity the page in question requires. I think we can all agree that abstraction is a good thing. But, there are times when it simply isn't needed. Do I need a complete framework and abstraction layer to know that 2+2=4? Or do the work? (maybe a little too simplistic for an example, but I think it makes the point). You and others make references to Java, java struts, javadocs, and other similar features. But I've yet to see anyone mention that Java is NOT a file based programming language. By this I mean that I can write a complete application with one java class, or that once the application is compiled, I don't have to request a file to see the next window. In theory I could do that with CF as well, but that would just be stupid. Web applications need web pages. Web pages are files (and may have some dynamic parts to them). Files are stored in directories. The same can be said about Java applications, but the compiled java app doesn't really care what directory the source files were stored in - whereas a web application does. Documenting the functions, classes, and logic of a java application is a little tougher because you are not forced to create a single file for every class or function, or display page/window. So, java struts, and javadocs, (and the equivalents for .Net and other languages) provide useful features for a non-file based language. On the other hand, a simple good naming standard (and some reasonable thought beforehand) with regards to the directory structure of a web application, can also prove as a Guide. I can look at the directory structure and know the basic layout of the application. Does this mean that FB isn't needed? No. Does this mean that FB is the only method? No. Does this mean that my method (using OOP principles) is better? No. Does it really matter in the long run? No - as long as there is SOME documentation, and some thought in the structure of the application, and the application does the intended job. Now, that all said, I've previously stated that my experience with FB is limited to the FB2 days, and even that isn't very extensive. The point I would really like to make is that FB does provide a method for people to structure their applications in a useful manner. However, and I think this is the point that Dave was trying to get to, not all of us need this method. A large number of us have previous programming experience (specifically meaning non-web based) and think of structure before we write code, because we know this must be done, or suffer the consequences. Someone new to web development may feel the need to start coding right away (how many of us DIDN't do this at one point). For these people especially, FB is a great idea, because it forces the structure a good application should have. Whether the structure is based on FB, OOP, or some other framework/methodology doesn't really matter in my eyes, as long as there IS a decent structure. And FB is excellent for those who simply like what it provides. But for those who prefer a bit more independance, and have the ability/experience to understand the importance of a program structure and proper planning, FB doesn't really offer anything we don't already do. For the record, I'm going to check out FB4 as a result of this thread, just to see what's changed since FB2, and see if it applies to any of the work I'm doing at the moment or in the near future. Thanks to all for the discussion - it's been a good one I think. Shawn -----Original Message----- From: Brian Kotek [mailto:[EMAIL PROTECTED] Sent: Thursday, July 17, 2003 6:58 PM To: CF-Talk Subject: Cons to Fusebox Dave Watts wrote: >I don't like controller structures, or "hub-and-spoke" frameworks, or >whatever you want to call them. I think they add needless complexity to most >CF applications. I like being able to see a URL and know which file to edit, >without having to read some other file. 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. >I don't like unnecessary use of variables at runtime. When you have >something like "<form action="#foo#">", how often does #foo# change that you >need to store it in a variable? The vast majority of HTML forms are only >going to post data to one place. 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. >I don't like unnecessary abstraction in general. You may argue that the >abstraction provided by Fusebox is a better alternative than a lack of >abstraction, but I haven't found that to be the case personally. If you prefer to build rigid and brittle code, I agree that abstraction is a very bad idea. >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. >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. >> 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. It's very easy to find flaws in other people's ideas. 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 have never said that Fusebox will solve all development problems. Why must you make such sweeping generalities like that? 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. 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. So to others out there reading these messages, I invite you to take a look at Fusebox beyond the lens of my opinion, Dave's, or anyone elses. It's free. It's wide open, sitting there and waiting for you to give it consideration, which is something very few other ColdFusion methodologies can say. Is it perfect? No. Does it solve everyone's entire set of development challenges? No. But does it openly reveal itself to anyone who wants to consider it? Yes. Is it a useful approach? Thousands of people believe it is. Does it try to incorporate the best-practice advice of many highly respected developers and software engineers, such as abstraction, encapsulation, decoupling, and orthogonality? It certainly does. Is it the approach you should take to building a web application? I strongly believe it is worthy of serious consideration, but it remains up to the individual to decide for themselves. I'll leave it at that. Regards, Brian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
