All, I've been reading the Fusebox debate in here for the past few days. I am always amused at how passionate people are about their own opinions, including myself. Let me just give you my opinion and experiences and you can judge for yourselves. a.. I started fusebox and it took a while to learn. Part of the problem is that most methodologies DO NOT have enough documentation, Fusebox 3 among them. A lot of people do not like the learning curve, and thus abandon fusebox before reaping the benefits. Also, some people do not like being told how to build their app. Any methodology is going to make application building more time consuming while you are still learning. The question is, does it get any faster after that. For me, it did. b.. Fusebox SHOULD speed up your app building, not slow it down. After I got used to the methodology, I found that reusing query files alone helped in speeding up development and maintenence later on. I remember working on sites where the same queries were copied and pasted over and over into varous .CFM files and that just seems silly to me now. If that query needed to be changed, you had to change all of the copies individually and it took longer. That's what CFINCLUDES are for and fusebox is based on heavy CFINCLUDES. Also, a lot of developers miss out on re-using fuseactions by using <CFMODULE template="index.cfm" fuseaction="SomeFuseaction"> Being able to reuse whole fuseactions and not just individual files is what fusebox and all those attribute scoping stuff is about. c.. But this brings up another issue. A lot of the time, building an application that can easily be expanded maintained and is well documented, takes longer than one that can not. Its a pay now, or pay later situation. I prefer to pay now. I always rather build a really solid application slowly, so that when it comes time for upgrades and new features, it is easily and rapidly extendable and there are no bugs. d.. Another thing that fusebox solves is having endless CFINCLUDES including other CFINCLUDES. This becomes a real problem on large sites. Fusebox SUGGESTS having all cfincludes in the index file so you can see where everything is being called from. e.. I have made crappy fusebox sites. I can think of two off hand and they were both fairly large with a lot of business logic and rules. They were also rushed. Its like clients think that ANY application, no matter how large and complex, can and needs to be built in one month. Almost every deadline I get is one month unless its a really small site. These crappy fusebox apps both did not make use of the CFMODULE technique that fusebox aims for, there were lots of individual files borrowed from directories that should have been combined somehow (although I only make folders for individual logical app structures, not a folder for dsp_, act_, css_ etc) and there were a lot of misunderstandings between myself and the client. Fusebox gets choppy when you start CFINCLUDEing or CFMODULEing from one directory to another. That's when you start needing object libraries of some sort. f.. The Fusebox book: I learned a lot from this book, but there were a few typos and inconsistencies and it was basically Fusebox 1 or 2. Also, I wasn't a complete newbie, i had been doing some fusebox for about a year. Again, developers don't document their strategies and methodologies enough. Also, whoever said developers were necessarily great writers? g.. Fusebox is NOT object-oriented like Java or C++. It is component based (kind of like C functions, I guess). Components do really help though. It is much easier to find a dsp_userform.cfm file with the user's form in it than looking in one HUGE user.cfm file for the part with the logic to display the user form. Fusebox does however attempt some Object Oriented techniques like encapsulation and information hiding using the custom tag/cfmodule techniques I mentioned above. Fusebox 3 is supposed to have inheritence but I haven't figured out how to do that. I am looking into SmartObjects for Object Oriented CFML (http://www.smart-objects.com/) and seriously considering making that my methdology with some fusebox-like naming conventions. I feel anytime you move away from just components and more into objects, you will get cleaner and more easily maintainable code. h.. A lot of people say you should use JSP or .NET if you want OO in a web language but I'm not sure that solves the problem. I am also not sure that JSP is currently or CF6/Neo will be heavily OO. Most web languages just aren't completely OO. Maybe JSP people could help us out here? Can one JSP page inherit methods that display data and raw HTML from another JSP page? Can you create methods that contain JSP code without writing a straight servlet? (JSP makes it easier to plop in HTML than a servlet does.) Can you call a whole smattering of JSP pages as an encapsulated object and/or method of an object? For example, if I declare a method in a JSP page that displays a list of users from a query (using 2 or more other JSP pages), can I create an instance of that class and call that "display user" method on another page? Can ASP do any of this? Is NEO/CF6 supposed to have classes and methods built into the CF language or just through java? I don't think that CFML will ever be completely OOP but any attempts in that direction I think will improve development time and maintenence. This way you combine the ease of CFML's display capabilities with the elegance of Object Oriented Programming. i.. I think looking at many methodologies will help you even if you don't use any of them. There are techniques provided by the community that solve problems you may just now be struggling with, just like this mailing list. j.. Is Fusebox "self documenting?' Well somewhat. Fusedocs help if you use them. Also the file naming conventions and having everything CFINCLUDED from the index file makes it easy to understand and find things. If you look in the user directory, find the "Add User" fuseaction, you should be able to figure out that the dsp_userform has the form to add/edit users and the qry_user has the query to pull a user from thd DB, without ever reading a line of comments. But there is always going to be complicated logic that NEEDS DOCUMENTATION. I am really curious about Ben Forta's opinion of Fusebox? Has anyone been able to corner him into saying anything one way or the other?
And so the debate rages on. If anyone feels I am talking out of my ass, feel free to flame me. I'm somewhat fire proof and will try not to cry. -Craig ----- Original Message ----- From: "Zac Belado" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, November 19, 2001 1:31 PM Subject: RE: Fusebox - opinions? > > Look. Ben Forta is the guru of gurus in CF, and he didn't exactly give it > > an endoresement when he came to Vancouver last week. That's enough for me > > to sweep that idea under the rug. He didn't exactly slag it either, but > > anyways, he can probably fill you in more than I can. As him for more > > information. > > Ben quite explicitly said that he wasn't going to give an opinion about any > methodology. Given that statement its not really fair to try to extrapolate > from his comments. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
