Ahhh Peter, Context, context ... some of us are building race cars (perhaps the framework authors), some are building cars (guys like you for instance), some are building those "soap box" things that you can steer and brake as they coast downhill ... i'm somewhere in between a soap box model builder and the next level down, whatever that is! ;-)
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. I first started with CFC's and OO with Hal Helms book "Discovering CFCs". It was a struggle for me to understand how composition worked, and i mean the mechanics of it, because it wasn't explained directly. Same with inheritance. I somehow got it in my head that you instantiated the parent instead of the child component. When it didn't work like i thought it should, (the child's method's weren't visible to the parent) i thought it was a bug, since Hal kept talking about CFC bugs and workarounds in his book. "Oh well, i guess you can't use inheritance with CFC's until they fix that" Then i dug into a bunch of OO books and got completely confused. What i've learned in the meantime is that OO in CF can be much simpler than it seems from all this lingo and pattern literature. And my feeling is that beginners should know that. With just the basics, one can do a lot. On 3/13/07, Peter Bell <[EMAIL PROTECTED]> wrote:
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-Frameworks--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]
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]
