Hi Matt, I really don't understand how you can be so "affirmative".
- "J2EE design patterns do not apply to CFMX." Why? Can't you apply MVC to CFMX? Good design patterns are usually not link to technologies. (the MVC pattern has its roots in Smalltalk, isn't it?) - "CFMX is not J2EE and it never will be." Matt Liotta (?) "... I would not hesitate to say that ColdFusion MX is now the fastest way to build and deploy J2EE applications..." Jeremy Allaire (Chief Technology Officer, Macromedia) in http://www.macromedia.com/desdev/mx/blueprint/articles/server_side_4.html Sorry, but I prefer to trust Jeremy Allaire... ;) - "I suggest creating new design patterns that make sense for CFMX and not try to adapt J2EE." Sure. We are waiting for your suggestions. In my case, this exactly what I am trying to do with MVCF (and again, MVC is not necessarily J2EE...). Sincerely, Benoit -----Message d'origine----- De : Matt Liotta [mailto:[EMAIL PROTECTED]] Envoy� : mercredi 21 ao�t 2002 17:16 � : CF-Talk Objet : RE: Any Fusebox and CFMX issues? > 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. > Maybe one of the only ways you have seen. However, there have been many organizations that have had proven architectures and application frameworks for years using CF that had nothing to do with Fusebox. In fact, some would argue -- myself included -- that most of the good examples of high-end CF applications don't use Fusebox. A quick informal survey was done on the CFGURU list asking about Fusebox and few responded that they did in fact use it. > Now, with MX, ColdFusion has entered into the J2EE universe and native > component-based architectures. > CFMX does not have a component-based architecture. Just because Macromedia chose to call its new encapsulation feature a ColdFusion Component doesn't mean it fits the definition of a component-based architecture. For all intensive purposes, CFCs really are just ColdFusion classes, not components. > 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). > J2EE design patterns do not apply to CFMX. CFMX is not J2EE and it never will be. I suggest creating new design patterns that make sense for CFMX and not try to adapt J2EE. -Matt ______________________________________________________________________ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.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
