Sean, I actually think you and I are in agreement on many points here.
> I think it's a bit short-sighted to drop MG just because it has added some optional components you don't like... I didn't exactly drop MG because of these optional components. I did drop Reactor because of some of the things I mentioned below...and yes, I know its still beta, but it is packaged with MG:U which itself is still in beta and which was being recommended in the prior posts...so while I am not criticizing the errors per se, I do think is fair to warn someone considering adopting MG:U with Reactor. The decision to include Reactor caused me to consider the direction MG was headed and to consider other frameworks (which isn't bad anyway). In the end I chose Mach-ii because I was more comfortable with the way it worked and not because of anything else. This is not to say it is better or worse than any other framework...as you know, I advocate people choosing a framework, any framework...as you say, if you do it right, you can generally change without too much difficulty. That being said, maintaining the level of abstraction that you have set up to remove the dependency on the active record pattern that Reactor uses isn't an easy task for a framework and OO noob is it? I want to emphasize, I am not asking anyone to abandon MG:U because of Reactor. However, the praise heaped on it has a lot to do with the Reactor integration and scaffolds and such. MG 1.1 is not for building blog applications in 9 minutes. I would agree that Model-Glue is easier to learn that Mach ii, which is probably why I chose to go the MG route first. However, before I was able ot properly do MG even, I had to take a step back and learn how to code OO - by hand. I actually tried the MG/Reactor/CodlSpring route before it was all integrated and before I understood OO. Big mistake. It led me into a lot of problems that were not the fault of any of the frameworks but more the fault of my own misunderstanding and ignorance about the problems they are intended to solve. > 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. I am also not saying that Reactor is not succeeding. I have just chosen, for the moment, not to use it. I also think the general hype over Reactor glosses over the complexity of an ORM that you yourself mention. Its being sold like a Ginsu knife that can cut through tin cans. People are buying it without asking why they need a knife that can cut through tin cans or whether having one will make life any easier. I think the level of activity on the list shows this too - that you use this knife when it is appropriate or risk cutting yourself (to expand on my useless analogy). By this I mean, you can get yourself totally in bed with Reactor before you realize it isn't always that easy to use and has a steep learning curve. In many ways it resembles CF as a whole. CF is deceptively easy to do simple things which tends to hide the complexity of the language as a whole. -- - Brian Rinaldi blog - http://www.remotesynthesis.com/blog CF Open Source List - http://www.remotesynthesis.com/cfopensourcelist Boston CFUG - http://www.bostoncfug.org ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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:253050 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
