I always felt that Fusebox was foremost a methodology and a secondarily a frame work.
I believe that the Fusebox methodology advocates brokering all requests to access application functionality through a single controller while separating display logic, data access logic and functional routines. These have been salient points in convincing clients that ColdFusion has a scalable methodology that will allow their applications grow with them and therefore winning me jobs. These core values have changed less through out the development of Fusebox than the different frameworks have. I believe I would have a difficult sell to my clients approaching them and saying "By the way you need to fork over more dough if you want the application I built you last year to be a legitimate 'Fusebox x.y' application congruent with the latest framework". I wonder if my clients wouldn't ask what kind of a methodology did I sell them that after a year their application is no longer compliant with Fusebox's core theories. I believe the developing framework(s) for Fusebox are excellent and they do create a more standardized landscape for developers to work from, however for me while I continue to adapt to the new and ever changing frameworks Fusebox is first and foremost a methodology. JME -----Original Message----- From: John Jonathan Kopanas [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 7:37 PM To: [EMAIL PROTECTED] Subject: Re: A suggestion for FuseBox viability. . . - The fusebox community and Hal Helms recognized one very important thing. Most Software Engineers don't innovate but just use solutions that have already been proven to work. Only a few software engineers are innovators. For those who are innovators they take the specification and build on it. They create there own implementation of the busebox methodology while improving the standard. Then there are the majority of people who will just use the core files to do there job. - So the way it is now allows people from both camps to do what they do best. Innovate or solve problems with existing solutions. - Let's us not argue between framework, methodoly, design pattern and gods gift to web programmers. Fusebox is many things. It is a methodoloy. From this methodology came a framework that consists of the core files, fusedocs and whatever else that I might not know exists. The framework are for people who want the tools that help you use the methodology. Those are my 3 cents. Now back to trying to get CF MX working and learn how to use actionscript and flash. ----- Original Message ----- From: "Nate Nielsen" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 10, 2002 7:14 PM Subject: Re: A suggestion for FuseBox viability. . . Well, to be fair, the first paragraph of the website is . . . "Fusebox is a FREE web application standard in use by 7521 people from around the world. Fusebox is attempting to reduce the 70% software failure rate by creating a standard methodology for writing web applications. This development methodology works with ANY web application small and large. Join us and have your ideas be heard by thousands of professionals around the world." Perhaps the confusion comes from the fact that in just this one paragraph, 2 of the 4 sentances directly state FuseBox as a methodology. Macromedia's description next to Hal Helms pic is . . . "Hal Helms teaches, writes, speaks, and consults on Web development using the Fusebox methodology." And I remember reading an article by Hal about different common methodologies, such as the "No Methodology Methodology", "Proprietary Methodology", etc. This article was evangalizing the use of the "FuseBox Methodology" - My point being, is that FuseBox IS billed out as a methodology, by its highest members and even the primary website. My simple request is that : (A) Abandon the thought of FuseBox as a methodology. Especially with FB3 - We could possibly stretch the meaning of "methodology" a bit for previous versions, but FB3 is far from a methodology, we all know and understand this. (B) Clearly define FuseBox as a framework, and post it as such. My personal feeling is that the term "methodology" states a form of developing against a set of standards and best practices. The existing "methodology" concept for the product creates a better stance for exposure and acceptance for it's inherent meaning to the over-lords that manage development groups - however it is mis-leading. I still truly think if you define FB as a framework, and release a second product as a straight methodology - and refrain from making direct references to each other in both. These two as separate entities should be able to exist without one another - as they address different needs. -Lets face it, there is a clear and strict distinction in the development community over FB, you love it or hate it - normally there not being a third choice. I think by taking a few simple steps to clear up the confusion, FB would much more popular, and bring the FB Haters Club and FB Lovers Club together. Nate Nielsen [EMAIL PROTECTED] [EMAIL PROTECTED] ----- Original Message ----- From: Lee Borkman To: [EMAIL PROTECTED] Sent: Friday, May 10, 2002 5:14 PM Subject: Re: A suggestion for FuseBox viability. . . Hi Nate, Fusebox was never a methodology. An architecture or possibly even a framework these days, but not a methodology. For some historical reasons that I do not claim to understand, Fusebox has often been referred to as "The Fusebox Methodology", but that was and is a simple misnomer. IMHO. ;-) Of course, along the way, many FB users have adopted methodologies that work well with the FB architecture, and much of this useful practice is now being crystalised into what is called "FLiP", the Fusebox Lifecycle Process. You can choose FB architecture. You can choose FLiP methodology. You can choose both, or one, or neither. The architecture is portable, and has been ported to several different languages/platforms. The soon-to-be-convened Standards Committee wil no doubt be documenting in language-independent terms exactly what is and what is not FB3, so that it can be implemented for many more languages. Even the FLiP methodology is portable, in that you can use it for doing things other than developing web applications. In the very near future, you can expect at least one book to be published about the FB3 framework. It has nothing to say about methodology. No doubt there will be other books to follow that document the FLiP methodology, and that will say nothing about FB3. And yes, there is another book about to pop up that talks about both. In short, I hope and believe that your concerns are already being addressed. Watch this space. See ya, Lee Borkman The Fusebox Steering Committee ----- Original Message ----- From: Nate Nielsen A suggestion for FuseBox. Seperate it - Official FuseBox Methodology - Methodologies can be contained in a document and require no files. They explore best practices for approaching common development tasks. Official FuseBox Framework - This is basically what FB3 is. It can require files, and take care of issues on a coding level. You can add the handling of errors and exceptions and other widgets. Most importantly, it can cater to specific languages. I think many people are turned off by the fact that the FuseBox methodology is now a framework. This also makes it impossible to actually port FB as a methodology over to other languages like ASP and JSP. I think if the "FB Steer" folks got back to the basics of developing FuseBox as a methodology, and framework for those interested in it, -seperately- you would see many doors open to expanding FB concept on a much larger scale. And no, I don't think this post belongs in community, and therefore - I will not take it there. =) Everyone's thoughts on this? ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
