I am very curious to see how Fusebox is going to evolve with CFCs. Because, right now, I am not convinced that Fusebox is very well adapted to CFMX applications... As I am not a heavy user of the latest Fusebox versions, please correct me if you think I am wrong ; ).
Fusebox was originally designed with CF4.0 limitations in mind. It has been designed for scripting languages (CFML and then PHP and JSP). It was one of the only way to have a very well organized CF application with a standard and proven design pattern (at that time, the only way to reuse CF code was the custom tag mecanism and cfinclude/cfmodule...). It has quickly become a very mature and proven framework for building high-end CF applications. Now, with MX, ColdFusion has entered into the J2EE universe and native component-based architectures. So from now on, I think it would be more logical to use standard J2EE design patterns and similar coding syntax (for example, taglib with prefixes). It will be more practical to "talk" with Java people (because they use similar approach and syntax). Fusebox and its "circuit" philosophy is not a J2EE design pattern, MVC is the "de facto" J2EE design pattern. Thanks to CFCs, the new Taglib mecanism (<cfimport>) and the improved UDF lib, you can pretty easily apply MVC with CFMX : - CF Pages + Taglib for the View layer (or Flash MX), - CF scripts for the Controller layer, - CFCs for the Model layer. In my opinion, it is more intuitive, simple and elegant than the "circuit-based" design pattern of Fusebox. Some people have tried to add MVC to Fusebox. But, if an application follows correctly the MVC pattern, it should be already correctly structured (at least the minimum required...). So what is the advantage of using Fusebox on top of it? The previous main advantage of Fusebox (the ability to structure and organize script code) is not valid anymore. Fusebox is still an excellent framework but I don't think it the best suited to CFMX... perhaps Fusebox4.0 will be? I made an attempt to find a better approach with the MVCF methodology. It is certainly not perfect, but at least, it is closest to the way J2EE applications are usually built (OO components, taglibs, .properties i18n files, XML config file...), it uses the latest CFMX capabilites and is based on a MVC approach. Any feedbacks are welcome... ;) Benoit Hediard www.benorama.com -----Message d'origine----- De : Hal Helms [mailto:[EMAIL PROTECTED]] Envoy� : mercredi 21 ao�t 2002 04:05 � : CF-Talk Objet : RE: Any Fusebox and CFMX issues? I agree with you, Sean, and that's where I'm headed. I want to leverage the power of CFCs and open up the power of working with objects to CFers. As such, I'm starting with a blank slate. Hal Helms Preorder "Discovering ColdFusion Components (CFCs)" at www.techspedition.com -----Original Message----- From: Sean A Corfield [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 20, 2002 6:24 PM To: CF-Talk Subject: Re: Any Fusebox and CFMX issues? On Tuesday, August 20, 2002, at 01:56 , Patrick McElhaney wrote: > No, not at all. If Fusebox was ported to CFCs, it would all be > behind-the-scenes stuff. The main reason to port to CFCs is that it > would give us a pretty good performance boost. The two books out now > would still be applicable and current Fusebox apps would work just > fine with Hal's CFC implementation. But the *real* benefits will come from Fusebox 4(?) which fully embraces CFCs for user code... Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ______________________________________________________________________ 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 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
