Ahhh Nando, I was with you all the way until the last paragraph:
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 That I¹m not so sure about at all. We¹re not driving cars we¹re building them and if you don¹t get that you only need to create one of some of your cfc¹s for your whole application and that other objects need to be created for each page request that needs them, or if you don¹t get the design decisions that¹d drive what should or shouldn¹t be a singleton, you¹re gonna have a hard time writing good OO apps. Heck I have trouble designing good apps because I don¹t really have a real comfort with the power of AOP and I¹m not very versed in closures and macros. If you want to be a software engineer, there¹s a lot of continuing ed required :-< I do agree, however, that there is a gap and a big learning curve to go from getting your db online to architecting a good OO app. Brian Rinaldi put together a great list of OO resources: http://www.remotesynthesis.com/blog/index.cfm/2006/7/18/Objects-and-Framewor ks--the-Big-Resource-List Doug Boude also put together a list of OO definitions (some aren¹t perfect, but it is the best list I¹ve seen anywhere). http://www.dougboude.com/documents/dougboudeslexicon.cfm Best Wishes, Peter On 3/13/07 4:46 PM, "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 > <http://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 <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]
