To answer your 3 questions: 1) what practices do you think fusebox encourages in coders?
It encourages standardization and code re-use, which are good things. What it doesn't encourage is developers learning how to handle complex variables and make proper use of scping, and more than anything, how to actually architect an app. Developers using FB think of everything in terms of "fuseactions" and fuseerrors (or whatever it's error format is called) and "fuse this" and "fuse that", etc. Tag galleries are great, but developers who have never done anything outside of fusebox, when working outside of fusebox, don't know where to begin. Obviously, there are fusebox developers who do know how to code outside of FB - they either knew how to develop before using FB, have used it so long that they've learned this through osmosis, or are one of the select few who took it upon themselves to really dig deeper into development than fusebox requires. If you begin your career building apps from scratch, 6 months later you're able to do some decent stuff without FB ad could learn FB in a heartbeat. If you begin your career using FB, 6 months later you're going to be able to do some great stuff with FB but will be relatively clueless where to begin without it when architecting an app. Obviously, these are blanket generralizations and there are exceptions to the rule, but I've seen it time and time again. 2) what is the basic structure of one of your applications? Ha! Now if I told you that, I'd be out of a job, wouldn't I? Seriously, though, I don't have a single basic structure I always use... it really depends on the app. I can tell you that I always develop the database first, the data abstraction layer and business logic second, and the display layer is integrated third. I can also tell you I use a directory structure suited to the needs of the app., but I always granularly seperate out my code and put things in a directory structure that makes sense just by looking at it and that can be copied from one box to another and the app. just works. I can also state that I follow coding best practices in my CFML that I've developed over the past 7 years of CFML development and code-reviews. My apps are always as modularized and Object Oriented as they can be, often times I write APIs for them to mmake them very easy to maintain and the functionality very easy to use, and I comment the hell out of everything. 3) how is this structure easily explained to a person with no experience of your application structure? If you mean explaining an application I've built to someone, the structure of my apps generally doesn't need explaining. If you know what the app does and you look at the directories, file names, and file types, you immediately know what files to modify to change this behavior or that. Like I said, I'm also very big on commenting. If you mean my methodology, there is no doc that explains this... it's all in my head. After as much development as I;ve done and code as I've seen, I find consistencies in the way I develop from app. to app. that weren't pre-meditated at all - just instinct. That said, I am working on a whitepaper to explain this process to developers. It's going to be a while before I'm done with it, as I've got a lot of development work and conference/CFUG preperation work on my plate in the next 2 or 3 months. When I am done with it, I'll let you know ;) ~Simon Simon Horwith CTO, Etrilogy Ltd. Member of Team Macromedia Macromedia Certified Instructor Certified Advanced ColdFusion MX Developer Certified Flash MX Developer CFDJList - List Administrator http://www.how2cf.com/ -----Original Message----- From: Paul Johnston [mailto:[EMAIL PROTECTED] Sent: 21 August 2003 00:21 To: [EMAIL PROTECTED] Subject: RE: [ cf-dev ] Fusebox Goodies It being late, and on my way to bed... (why I'm checking my email I don't know)... Simon, as an instructor: 1) what practices do you think fusebox encourages in coders? 2) what is the basic structure of one of your applications? 3) how is this structure easily explained to a person with no experience of your application structure? I ask these questions purely on the basis of interest. I have used FB in the past, but have no real desire to go beyond FB3, as it appears FB seems to have turned into an American money-making fest for a certain few (here, I duck just to make sure nothing hits me). On the Fusebox front Ashley, it's worth learning or at least understanding as it helps you code in a very procedural way. The problem comes when you don't reuse code properly and don't comment properly (although this is a problem with ALL code), or write applications correctly. This last bit, unfortunately, you can only learn from either writing code and learning from mistakes, OR from asking people (as you have done) what is good/bad/ugly about writing code. As with every structure/methodology/application if you don't understand WHY it does it a certain way, you can be sure it'll bite you in the end. Learn why FB was written that way, what MVC is all about, and why both have their place as good methodologies, but also learn that neither are perfect for every situation. Paul > -----Original Message----- > From: Simon Horwith [mailto:[EMAIL PROTECTED] > Sent: 20 August 2003 19:11 > To: [EMAIL PROTECTED] > Subject: RE: [ cf-dev ] Fusebox Goodies > > > Stephen, > All due respect to you as well, but as an instructor, I've > seen SO MANY students who had used fusebox for months, who > didn't understand the first thing about how to properly build > an application from scratch - not the first thing. All they > understood were fuseactions and some of the basics of CFML. > The framework does not encourage developers to learn, nor > does it reinforce, development best practices. I've also > been called on-site as a consultant to troubleshoot and "fix" > performance issues on many sites that were built with > fusebox. I'm not implying that fusebox was the reason there > were problems with the site, but I can tell you that when I > looked at the code for the site and the way fusebox was > handling some things under the hood, I could have achieved > the same functionality in a much more optimal manner. That's > the point of fusebox: not just to reinforce consistency and > speed development by re-using pre-written code, but also to > make it easier to achieve results. Some of the things that > the framework does to achieve this simplicity and > consistency, are not really recommended practices. This has > been my personal experience with fusebox. > > ~Simon > > Simon Horwith > CTO, Etrilogy Ltd. > Member of Team Macromedia > Macromedia Certified Instructor > Certified Advanced ColdFusion MX Developer > Certified Flash MX Developer > CFDJList - List Administrator > http://www.how2cf.com/ > > > -----Original Message----- > From: Stephen Moretti [mailto:[EMAIL PROTECTED] > Sent: 20 August 2003 17:51 > To: [EMAIL PROTECTED] > Subject: Re: [ cf-dev ] Fusebox Goodies > > > Simon > > > I'm not a fusebox fan - never have been. This is > primarilly because > > I've found that it ties your hands as well as discouraging you from > > learning > the > > language properly. Most applications can be built better > if you know > > how > to > > build an app. from scratch. > > > > With great respect.... Thats a load of bollox. > > I'm no fan of FB3 and have yet to look at Mach12 or whatever > FB4 is being called. (I dislike the over use of files to > determine OS etc.etc.etc. and the overly complex switching > that creates spaghetti if your not a conscientious developer > blah blah blah...) > > However, in no way shape or form does it prevent you from > learning coldfusion properly. That is an element of the > programmer. No method for structuring applications is going > to discourage a developer from learning the language. All FB > (any version) does is provide a hub/spoke structure within > which you right your application and a few functions that can > assist in ease of development. It can't help you learn to > write good code nor does it prevent you from writing good code. > > In terms of tieing your hands; never had any issue with > finding FB restricting how I writing a well structured > application. Frankly, developers who aren't using MVC (now > that we have a real approximation to an OO language) or a > hub/spoke method (procedural) should all be taken out and > shot. These are the developers who just litter files with > queries,displays, actions with no defined flow through the > application and create applications that cannot be maintained. > > In no way does or has FB ever attempted to write an > application for a developer, so your statement that an > application can generally be written better from scratch has > no relevance to the dicussion. > > I'm not happy about all the "political" and "commercial" BS > that FB has become since FB3, but these kind of statements > are pure ignorance of what FuseBox is. Sorry Simon. > > Regards > > Stephen > > > > -- > ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] For human help, e-mail: > [EMAIL PROTECTED] > > > > > > > -- > ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] For human help, e-mail: > [EMAIL PROTECTED] > -- ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED] -- ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED]
