I would have to agree with Nando with ColdSpring. The most common features of DI or IoC are just to create a repository of preinitialized object that you can reference easier and more quickly than creating the objects yourself.
MG:U provides a great little helper function int the controller called getBean(), which refers to the name of the object in the ColdSpring repository. Plus, it really is nice that you can have the choice or argument construction and setter injection. A lot of non-OO CS users have argument construction as it is similar to just calling an object that has constructors inside of an init() method. The AoP, circle dependencies and the remote proxy will be your challenge to leverage them correctly. Teddy On 3/13/07, Nando <[EMAIL PROTECTED]> wrote:
I don't know of any really good CFC resources off the top of my head. But i do know that there's a gap here. On one side are the people who've been trained as programmers. For them, the words instantiation, inheritance, composition, service layer, factory, DAO, gateway, ORM, and all the rest of these terms we see used on the lists are as clear and understandable as car, dog, and cat are for the rest of us. I would think that most people would be too embarrassed to ask "What do you mean by instantiation"? in the middle of a very heated discussion about whether or not ColdSpring should be used to instantiate transients. And then the next question would be "What's a transient?" So perhaps they head on over to coldspringframework.org and start to read the documentation ... ColdSpring is a inversion-of-control framework/container for CFCs (ColdFusion Components). Inversion of Control, or IoC, is synonymous with Dependency Injection, or DI. Dependency Injection is an easier term to understand because it's a more accurate description of what ColdSpring does. And think ... "Ummm, this is way over my head. I'm not ready for this yet." ... because they're confronted with a bunch of terms they've never used. "And it says there that Dependency Injection is an easier term to understand ... " But the simple truth is you don't need to conceptually understand a thing about IoC or DI or whatever else is written there to use ColdSpring, any more than you need to understand exactly how the engine of your car works in order to drive it, or how to design and build a car engine for that matter. On 3/13/07, Josen Ruiseco < [EMAIL PROTECTED]> wrote: > Nando, > > I am bugging you... write a series of blog posts called "Rediscovering > CFCs"... =) > > There are others on this list hiding in the corners of the room that > will echo my bugging request... > > In the meantime, perhaps you can point us to the best couple of CFC > references out there? > > Josen > > ------------------------------ > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of * > Nando > *Sent:* Tuesday, March 13, 2007 1:06 PM > *To:* [email protected] > *Subject:* Re: [CFCDEV] "Light" framework? > > Joe, > > I know Model-Glue doesn't look "light" - but if you use the quick start > guide and just try to actually build something, you might find it a lot > lighter than it looks at first. > > And you don't really need to know much OO to use it. In fact you don't > need to know *any*. You just need to try it out, work through the quick > start guide and actually build something simple, and ask a few questions to > the list and you'll know how to use MG. It takes an evening or two to get > started, and most of the work is just figuring out how to install everything > and what IDE to use for the XML part. > > The reason i'm suggesting this is because with the integration of > Transfer and ColdSpring, MG makes it *very* easy to build applications. > Some very smart people have done a lot of work and a lot of thinking for > you. You may find yourself doing a lot more work and a lot more thinking > with a "Light" framework ... especially if you build it yourself! (I'm > speaking from experience here!) > > I actually think MG is a little easier than Fusebox to learn. Many > people may be used to the Fusebox concepts of circuits and fuseactions and > plugins and plugin points, etc so perhaps it seems easier in the CF > community. I think MG is simpler in the sense that there is just a simple > XML language to learn and you just glue your model and view together there. > > If you're not familiar at all with using CFC's, well that's a > prerequisite for MG. But if you are, you'll find that you won't have to do > much if any OO design or thinking to build an application. If you use > Transfer and ColdSpring with it (both are very easy to pick up if you just > *try* them out) just about the only thing you *may* need to figure out > in an OO sense is to add a service layer to your application rather than > doing everything in the controller. And that's easy too, once you get past > the lingo and see what it means.* > > *(It means instead of the controller doing the actual work, it asks > another CFC to do it. The advantage this gives you, if and when you need it, > is another application can ALSO ask the service layer to do the same things. > In other words, separating out the service layer gives you the freedom to > have different "bosses" asking the "workers" - service components - to do > their jobs.) > > That's pretty much the only OO you'll need to know to build some pretty > robust applications using MG. But if you don't know how to use CFC's ... > ummm, i was going to say then Fusebox is your only choice, but i changed my > mind ... bug me and i'll write a series a blog posts called Rediscovering > CFC's, and then you'll know how! > > :-) Nando > > > > Joe Lakey wrote: > > Is there a "light" CF framework--something that we novice coders with > little or no OO background could use to transition to the more elegant, > > > comprehensive frameworks? > > If not, I'd like to know if there's any interest in creating one. I > would work on it myself, but seeing as I'm only barely familiar with the > existing frameworks, I'm not very well qualified to build any kind of > > > bridge to them. > > Thanks, > Joe > > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions at > > http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock!www.katapultmedia.com > > An archive of the CFCDev list is available at www.mail-archive.com/[email protected] > > > > > -- > > <http://aria-media.com/> > Aria Media Sagl > CP 234 > 6934 Bioggio > Switzerland > www.aria-media.com <http://aria-media.com/> > > > > You are subscribed to cfcdev. To unsubscribe, please follow the > instructions at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > You are subscribed to cfcdev. To unsubscribe, please follow the > instructions at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at www.mail-archive.com/[email protected] > > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
-- Teddy R. Payne Adobe Certified ColdFusion MX 7 Developer Google Talk - [EMAIL PROTECTED] Atlanta ColdFusion User Group - http://www.acfug.org Atlanta Flash & Flex User Group - http://www.affug.org You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
