I'll ask Nic about that, Sean. ~Simon
Simon Horwith CIO, AboutWeb - http://www.aboutweb.com Editor-in-Chief, ColdFusion Developers Journal Adobe Community Expert Adobe Certified Master Instructor Blog - http://www.horwith.com Sean Corfield wrote: >> 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:253071 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
