>I actually think you and I are in agreement on many points here. Very likely :)
>I didn't exactly drop MG because of these optional components. I did drop >Reactor because of some of the things I mentioned below... OK, thanx for the clarification. >The decision to include Reactor caused me to consider the direction MG was Yeah, I actually think including a Reactor distro in the MG:U beta was a mistake and gave the wrong signals - especially since the MG:U distro did *not* include ColdSpring! Nowadays, folks are pulling both Reactor and MG:U separately from the SVN repos - one of the pros or cons of pre-release software with a public SVN repo (pro or con, depending on your point of view). What I do with my team is to pull updated releases, re-test everything and then merge the latest builds into our own repo (under Perforce) because we have some fixes there which haven't made it to the trunks under SVN yet. It's a complex process and not recommended for anyone who isn't familiar with source code control and working with open source projects! To be honest, if someone is relatively new to all this stuff then they need to stick to official downloads and that means: - Fusebox 5 (or Fusebox 4.1 or 4.0 or 3 - all are available as official downloads) - Mach II 1.1.0 (1.1.1 is not official yet - FYI, adobe.com is running 1.0.10 as far as I know but have 1.1.0 in the lab for testing) - Model-Glue 1.1 - ColdSpring 1.0 As for stable ORMs, objectBreeze is the only one to reach a 1.0 milestone so far (and I have some pretty strong reservations about its APIs). I don't know if Nic Tunney is on the list and wants to comment on how widely downloaded objectBreeze is? My sense is that Reactor is far and away the most popular ORM, followed by Transfer and then objectBreeze. >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? Oh, I completely agree! Learning OO is pretty hard because it's really a way of thinking rather than just some fixed set of steps to follow. Getting really good at OO takes years and it's only when it becomes second-nature that you can expect to blithely switch frameworks and components with relatively little impact. The payback is worth the effort but don't be discouraged by how hard it seems and how often you fail or paint yourself into a corner while you're learning! >However, the praise heaped on it has a lot to do with the Reactor >integration and scaffolds and such. It's definitely a double-edged sword... >MG 1.1 is not for building blog >applications in 9 minutes. Just to clarify for those who don't get the reference: Ruby on Rails became famous (notorious?) for having an "application in 11 minutes" demo video - MG:U did the same thing with a "blog in 9 minutes" demo video. And, yes, it relied very heavily on scaffolding and the underlying ActiveRecord-based ORM power of Reactor. Right now, MG:U is the only framework that can support this workflow. As Brian points out, that should not be your single yardstick for measuring the applicability of a framework. I only use scaffolding for prototyping, not for production, for example. >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. Agreed. >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. Yup, without any OO comfort level, even MG can be a pretty scary beast. >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. Ouch! Yes, but a good learning experience nonetheless, eh Brian? ;) >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 Reminds me of the comment about C and C++: with C it's easy to shoot yourself in the foot but it also lets you get the job done quickly; with C++ you can get the job done more quickly but it's also easy to blow your entire leg off. A powerful knife can be a great tool but it's all too easy to cut yourself - badly - if you don't know how to handle it properly... >CF is deceptively easy to do simple things which >tends to hide the complexity of the language as a whole. Yup. It's terribly easy to build something terrible :) Sean ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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:253062 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
