Nando, "So what you're saying in effect is that if in a web application you don't use any framework, and each "page", i guess built as it's own separate template, creates and calls any needed CFC's, and each CFC would create and call any CFC's it needed ... that this would be considered Normal Control?"
Exactly. Wouldn't that be a mess to maintain and work with? Isn't that were the term "spaghetti code" comes from? Not really. It can be very neat. The presumption is that the lower layers are shared. For example, right at the bottom you might only have one Cold Fusion app server. You'd have common libraries, etc. We're not talking about duplication of code, quite the opposite. And all the calls go from top to bottom. This kind of code, if done well, can be easier to understand at a glance than "inverted" code. "Spaghetti code" (thanks for the graphic metaphor) arises when you have no layering, or you work around it at your whim. Google "Big Ball of Mud" for an amusing description of this. Where the strict top-down approach falls down is in how you define variability in the behaviour of the lower layers. Every single piece of variation has to be defined at the top level and then passed down as a parameter. Therefore the top-down approach works OK where you have a lot of standard behaviour and a little bit of variation. For example, a function that opens a file does a whole lot of messing around with path parsing and IO subsystem interaction. That's the standard part. The only thing that varies is the file name, so it feels OK to just pass in the file name at let it do it's thing. Another example: every <cfset> tag works in exactly the same way - CF never needs to ask you which variation of cfset you want in a particular case, so there's no need for inversion at that layer. However, where you've got a little bit of standard behaviour and a lot of variation, your parameter lists can become so complex they start to turn into a mini language in themselves. Even worse, to maintain strict top-down flow you have to pass parameters through layers that have nothing to do with that layer, which can introduce a lot of unnecessary coupling. So instead, the top layer just keeps its variation specific knowledge to itself, and just says to the lower layers "Call me when you need something special done, otherwise just get on with the standard stuff". In the case of Coldspring the "something special" is the details of initializing each object that is encapsulated in the init() method. Obviously there's a *lot* of variation here - every class is different. The standard stuff is parsing and acting on the sequence of object dependencies defined in the config file. Jaime -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nando Sent: Saturday, 17 March 2007 3:23 AM To: [email protected] Subject: Re: [CFCDEV] "Light" framework? Jaime, Thanks for the explanation. It makes "sense" in a way, but i can't imagine at this point working in a "non-inverted way", if i can be a little loose with the terminology. So what you're saying in effect is that if in a web application you don't use any framework, and each "page", i guess built as it's own separate template, creates and calls any needed CFC's, and each CFC would create and call any CFC's it needed ... that this would be considered Normal Control? Wouldn't that be a mess to maintain and work with? Isn't that were the term "spaghetti code" comes from? Nando As an aside ... spaghetti is indeed difficult to control, as any Swiss German wearing a very large white napkin on their chest and wielding a big spoon in conjunction with their fork can attest to! On 3/16/07, Jaime Metcher <[EMAIL PROTECTED]> wrote: 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] 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]
