Thanks Sean, this is a great insight.
"This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540. It contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910. The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com -----Original Message----- From: Sean Corfield To: CF-Talk Sent: Thu May 03 02:08:48 2007 Subject: Re: Which Framework do you use... (if any) On 5/2/07, Robertson-Ravo, Neil (RX) <[EMAIL PROTECTED]> wrote: > Ok, let's hear the explanation of why and your experiences, I think this > should be in the public domain by whatever means. (blogged, list/off-list) Sure, here's excerpts of a long email exchange I had with someone about choosing between Mach II and Model-Glue (in response to questions about my "switch" - it's just my side of the conversion so it may seem a bit disjointed in places): ... . . I've changed frameworks in the past for one of two reasons: 1. Educational - so I can learn about other frameworks. 2. My current framework is causing me pain. The first reason is fine for individual developers to experiment and learn but is not a good reason to change existing production applications. The second reason is key for commercial / production applications. If you need to make certain changes / enhancements / whatever, and your current framework is making that hard, then you might consider changing frameworks. Bear in mind that changing frameworks is a pretty major decision and is often accompanied by a lot of tedious work just to get back to where you are. And lots - and LOTS - of QA / testing to ensure you didn't break anything. I've changed frameworks for reason two just once. I went from Mach II to Model-Glue, primarily because I wanted a bean factory to help me manage configuration data. If I was in the same position today - with a Mach II application that needed better configuration control, the path I'd take would be different: I'd simply add ColdSpring to my Mach II application and be done with it. Even deciding to just do new application development using a different framework - and continue maintaining old applications in the old framework - is not a step to be taken lightly. One of the great benefits of using the same framework for all applications that a single team maintains is that plugins / filters / whatever can be reused easily across all applications. Another benefit is that developers can move back and forth between maintenance and new code without having to "change gears". ... . . About the only time Mach II's architecture wins in my view is if you have an extremely complex, dynamic state-based model. Those are pretty rare in web applications (otherwise every framework would probably address dynamic flows). Mach II pays quite a performance penalty for that ability - which is a waste of CPU cycles if you don't need it. Another downside of Mach II, compared to Model-Glue, is that Mach II lets you intermingle model calls and view calls which can lead to a messy control file: <notify ../> <view-page ../> <notify ../> <notify ../> <view-page ../> <view-page ../> Model-Glue provides a bit more structure here since you do all your broadcasts first, then all your related views, then if necessary any additional events. Furthermore, Mach II's filter mechanism - whilst very powerful - leads to a control file where it is impossible to tell what the actual application flow might be: <filter ../> <notify ../> <filter ../> <view-page ../> <notify ../> <filter ../> <filter ../> <notify ../> <view-page ../> <view-page ../> Without looking inside the code of each filter, it's pretty much impossible to tell what actually gets executed under what conditions. By contrast, Model-Glue's <results> mechanism explicitly lists the possible event flows and, unless an explicit redirect is declared, you know all the broadcasts and views will be handled before moving to the result event. ... . . Model-Glue provides a set of built in messages that let you perform basic persistence operations without writing any code - just using XML. Look in the local Model-Glue documentation under How To's > How To Use Generic Database Messages. Here's an example from the docs: <message name="modelglue.GenericList"> <argument name="object" value="Contact" /> <argument name="queryName" value="aListOfContacts" /> </message> This will populate the event argument "aListOfContacts" with a query (record set) that is the result of selecting all records from the Contact table (or whatever that is aliased to in Reactor). For a lot of simple persistence operations, you don't need to write DAOs and Gateways because the GDMs (as they are known) will do the work for you. Very handy for prototyping. ... . . Because the Model-Glue core is managed by ColdSpring, you can easily override and replace any of the core components with your own version - without touching the core files. For example, you want to handle SES URLs? Write your own "state builder" object and tell Model-Glue to use that (by specifying your version in your local ColdSpring.xml file). Want to load database objects from multiple Reactor XML files? Not a problem, download my modified Reactor configuration object and specify that as the "reactorConfiguration" bean in ColdSpring.xml. You can't do that kind of thing with Mach II (at least, not without seriously abusing plugins and the in-memory Mach II data structures). ... . . So, there you go, for everyone to read: my reasons behind switching from Mach II to Model-Glue. This does not cover many of the caveats I added in the original thread about the downsides to *switching* from one framework to another (as opposed to simply *choosing* one in the first place). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| ColdFusion MX7 and Flex 2 Build sales & marketing dashboard RIAâs for your business. Upgrade now http://www.adobe.com/products/coldfusion/flex2?sdid=RVJT Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:276879 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
