>I know you can use MG without Reactor, but that >doesn't seem to be the focus of it
I think it's a bit short-sighted to drop MG just because it has added some optional components you don't like... If you don't have Reactor installed, MG starts up without it and scaffolding and GDMs (Generic Data Messages) are simply disabled. No big issue. You get Model-Glue 1.1 compatibility with the added option of using ColdSpring for configuration. The only difference is that ColdSpring is required to run MG:U - but you, yourself, don't have to use it. >One is the active record pattern, which Reactor uses. I think the active >record pattern reduces the flexibility of your application I agree to some extent. However, I have built some apps where I have a data tier that hides the Active Record pattern and that works well, decoupling the business model from the persistence tier (which is a good practice anyway). > I always use >the example that if you decide that Reactor is too much of a drag on your >site's performance, you will have a hell of a time ripping it out or trying >to recreate aspects of it. Not if you've designed your application properly. I just switched most of my persistence layer from Reactor to Transfer with very few code changes. My business tier dealt with beans (which Active Records are) and my data tier dealt with persistence so the changes were fairly localized. I even have a prototype TransferAdapter for MG:U so I actually have basic scaffolding and all the GDM machinery working with Transfer (with the exception of the gatewayMethod extension to MG:U that was added recently). >I also am not fond of scaffolds, as I think in >most cases they aren't very useful - however they are totally optional I >suppose so I am not going to make a big fuss about them. I've found them useful for quick'n'dirty prototypes and then I typically fold the Scaffolds.xml file into the main ModelGlue.xml file and copy the generated views into my main view directory and work from there. It saves me writing some otherwise tedious event handling logic and basic display / list / edit form stuff. >Lastly, I just >don't think Reactor is there yet. Since it's only at a beta candidate, I think that's only to be expected. Transfer is a 0.5 version release. MG:U itself is only a beta product. ColdSpring is the only 1.0 portion of it. If using pre-release software is an issue, then definitely MG 1.1 and ColdSpring 1.0 is a great, solid combination. However, since Reactor is totally optional for MG:U, I don't think this should be a reason to abandon Model-Glue. >It is a great concept that Doug has put a >lot of work into, but it seems to me that enormous scope and complexity has >caused it to be error plagued. I am on the list and I often feel inundated >with Reactor issues. ORMs *are* complex. Look at Hibernate. I think the volume of traffic on the Reactor list is a testament to just how many people are using it for real projects. And, for the most part, they are actually *succeeding* with Reactor. >Personally, I have chosen to move to Mach ii. I believe it is a solid >framework and isn't all that different from straight MG (i.e. like the >1.1days) - mostly some verb changes. I think there are some really problematic constructs in Mach II that make it harder for people to learn than MG 1.1 but I will also agree that it is a very solid framework. I introduced it to macromedia.com and it now powers about a quarter of the applications on the site (now adobe.com). I switched to MG 1.x to take advantage of ChiliBeans initially because ColdSpring did not seem approachable. Then I went to MG 1.x + ColdSpring. Whilst I could have then moved to Mach II + ColdSpring via the plugin, I found that I didn't like the complexities of the Mach II architecture (listeners *and* filters *and* plugins) compared to the simplicity and consistency of the Model-Glue architecture. I also no longer like the way that Mach II allows you to intermix calls to the model with view rendering and invocations of filters etc... I think it leads to messy event handlers. I also no longer like the way that listener methods are tied directly into the event handlers - Model-Glue's implicit invocation is much cleaner with multiple listeners registered for a given message broadcast. >Anyway, as this post is full of MG:U fans, I am not ripping on MG:U or >trying to start some framework flame war. I just think that you need to get >past the hype a bit when choosing a framework. This may mean that you still >choose MG:U, but it is worth considering the alternatives (Mach ii, Fusebox >and ColdBox). Again, agreed. I don't know much about ColdBox (reading the initial blurb about it just confused me so I put it down - if I find time, I'll definitely go back and look at it again). Fusebox is a good framework for established CFers who aren't yet familiar with frameworks but may be a bit alien for someone coming to CF from VB.NET (which I seem to recall the original poster was?). Fusebox lets you write procedural code if you want, with or without the MVC pattern. Or you can do full OO development with it if you want. If you're comfortable with OO and used to any sort of event-based programming, jumping into either Mach II or Model-Glue should be pretty straightforward. Mach II's documentation is a bit more Java-centric (Mach II was originally designed and built by a long-time Java developer for whom Mach II was close to his first CF project; Model-Glue was designed and built by a long-time CF developer). Only Fusebox has books available - it's the oldest (and most downloaded?) framework for CF and has a lot of deployed production sites. However, the shift from Fusebox 3 to Fusebox 4 was a big change in some ways (the basic concepts didn't change but the application flow changed from CFML to XML - making FB4 more like the other two frameworks here than its predecessor). Fusebox 5 is backward compatible with Fusebox 4 but adds more support for CFCs and expands the expressive power of the XML grammar (Fusebox's equivalent to the event handler specifications in MG and M2). As a final data point, my new group at Adobe is building ColdFusion applications using ColdSpring primarily (we're building mostly back end systems to support Flex applications) but also Model-Glue: Unity (for administrative consoles) and a mix of Reactor and Transfer (for persistence). And of course we're relying very heavily on cfcUnit for all our unit testing! Sean Corfield (these days a very occasional contributor to cf-talk due to workload!) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:253035 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
