Nando, Fowler (cited below) makes the point that inversion of control is a characteristic of frameworks in general and isn't a very useful term for understanding what any given framework does. I would tend to agree, but having said that:
Normal control: components in higher layers call components in lower layers. Your pages --> your app components --> your generic components --> framework components --> app server etc etc. (where --> means "calls"). Inversion of control: lower layers call higher layers. Your app initialization --> ColdSpring --> your components. That last relationship is inverted. If there's no inversion, you just have a library, not a framework. Callbacks are a baby version of IOC, but for things like ColdSpring and Model-Glue the inversion is systematic and fundamental to the way they work. Do you need to understand this to use the framework? I would say absolutely yes, at some level. You need to at least have a gut feel for it, even if you don't use the terminology. Otherwise you waste time trying to control the framework - see all the questions about "how do I get Coldspring to do x or y at runtime?" This is even more so in M-G - you write components and then *stuff just happens to them*! That screaming from the little room where you've locked your procedural control-oriented self is the sound of IOC. Jaime > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nando > Sent: Friday, 16 March 2007 7:35 AM > To: [email protected] > Subject: Re: [CFCDEV] "Light" framework? > > > Sammy, > > Ok, i'll bite. > > What's inversion of control, and what purpose does it serve? If you > can, please explain it to me through those terms so i really > understand what control is inverted here and why it's helpful for me > to understand it that way in order to use ColdSpring. Are you up to > that? > > I easily get the concept "wiring my services/CFCs together so they can > work together" and i think that's easy for most people to understand. > I still don't get the inversion of control thing. There's a central > config file, i can manage all the dependencies from there. why is that > considered "inverted"? to be honest, the concept just isn't useful to > me to understand how to use ColdSpring. (i kinda wish i could have > turned the word ColdSpring upsidedown there, made it inverted! ;-) > > ciao, > Nando > > > On 3/15/07, Sammy Larbi <[EMAIL PROTECTED]> wrote: > > Nando, > > > > Very well said. I can certainly see a disconnect now that you put it > > the way you did (and particularly after reading your blog entry at > > http://aria-media.com/blog/index.cfm/2007/3/14/Instantiation). However, > > I still wonder if even given that explanation (though surely a person > > would understand better), would they know they needed it if they didn't > > understand what inversion of control was, and the purpose it served? > > > > Nando wrote, On 3/14/2007 1:16 PM: > > > Sammy, > > > > > > As someone who is self-taught, I'm saying that the language, the > > > pattern lingo that is used, can be a barrier to understanding what > > > ColdSpring can do for you in simple terms. It tends to imply to the > > > learner that they need to study OO patterns before they can use a > > > framework. > > > > > > If instead, one says to an aspiring OO newbie who is self-taught: > > > > > > ColdSpring can instantiate (linked to a clear and simple definition) > > > the objects or CFCs that your whole application needs for you, and > > > wire them together so that they can work with each other. > > > > > > As anyone who has tried to architect an application that uses CFCs can > > > tell you, working out how the CFCs should work together can be one of > > > the most difficult parts of designing and coding your application, > > > especially for a beginner. As you progress, it often involves > > > reworking of your code significantly, and can easily introduce > > > mistakes. This is particularly true if someone is inexperienced with > > > object orientation and hasn't come to the point where they have a > > > preferred way of organizing their objects to work together. It's also > > > certainly true for an experienced programmer, because new requirements > > > or unrecognized aspects of the application can pop up at any time, > > > forcing you to rethink your design. > > > > > > ColdSpring uses a simple XML language in it's configuration file that > > > is easy to pick up. Depending on your level of experience, it can take > > > anywhere from a hour or two to learn the basics, to perhaps a day if > > > you are really new to all this. To reorganize the way your CFC's work > > > together or add another CFC to your app, you can simply and quickly > > > rewire them in the config file (and perhaps add a bit of code to your > > > objects). Here are some examples to get you started: > > > > > > .... > > > > > > .... > > > > > > .... > > > > > > Then show some comprehensive examples, so they can start using it > > > immediately (although certainly not as well as an experienced OO > > > architect). Explain a few cavets along the way. And that opens doors > > > to further learning, as experience is an excellent teacher. > > > > > > At the end, you can say: > > > > > > By the way, ColdSpring is based on the Java framework Spring. In > > > object oriented pattern speak, it's an Inversion of Control container. > > > For further reading and study, > > > http://www.martinfowler.com/articles/injection.html is a good place to > > > start. > > > > > > > > > On 3/14/07, Sammy Larbi <[EMAIL PROTECTED] > > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > Nando wrote, On 3/13/2007 5:02 PM: > > > > > > > > > > > > > > > IF ... someone is new to CFCs and OO and all this lingo, they can > > > > > certainly use ColdSpring without conceptually > understanding Inversion > > > > > of Control. But it probably doesn't at all seem like it to them. > > > > > > > > > > > > > They could, but how would they know they wanted to, or that > it would be > > > > beneficial in particular cases? > > > > > > > > > > > > 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 <http://www.katapultmedia.com> > > > > > > > > An archive of the CFCDev list is available at > > > www.mail-archive.com/[email protected] > > > <http://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] > > > > > > > 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]
