Wow, Mike! Thanks for the great intro primer! I'd be happy to look at your CFC's. Perhaps they would clarify my understanding.
I really just need to see an example from start to finish of a situation where there's a db, say "myDatabase", see how that is initialized with the "init" function, see how createObject is used in relation to functions within a CFC, and how the data is output. Some of that I'm grasping. But I haven't been able to put together functioning, start-to-finish, code yet. I'm using CFC's, but so far I can only make them work with <cfinvoke>... I seem to understand the code more intuitively. But the idea of putting objects into memory using createObject is fascinating and I hope I can get that working. I'm having to do this "on-the-fly" however...trying to learn this on a current, "should-have-been-done-yesterday" project, so I have little time for trial and error. (A frustrating way to work and, especially, to learn!) Anyway, whatever you care to share is appreciated! And thanks again for taking the time to type up the primer! Rick > -----Original Message----- > From: Mike Kear [mailto:[EMAIL PROTECTED] > Sent: Friday, June 20, 2008 10:49 PM > To: CF-Talk > Subject: Re: Waaahhhh! Why won't my CFC work! > > Rick, you're showing the signs of the frustration I felt when i was > starting to learn this stuff. Dont worry - it all comes clear in > the end. > > There is a problem for the newbie into OO coldfusion in that there is > a whole host of other OO languages around that are supplying concepts > and terminology to this. As soon as you learn what one word means, > another pops up. As soon as you think you're getting the hang of > it, someone uses a new term you havent heard before, and you get all > depressed because there's yet another concept to learn about. Often, > there are concepts in one technology that also exist in other > techologies but they have different names. Or there's these things > called design patterns. (which simply means the style of structuring > you code components to do the job) and when someone develops a design > pattern they often invent terminology to describe the concepts behind > it. > > But dont let it steer you off. I struggled to understand all these > new terms at first, then i suddenly realised - i dont need to care > about all those terms, as long as i get the basic concepts and > techniques right. I can learn the terminology later. Once i got > that, everything went simpler. I didnt have to know what > 'encapsulation' was or what a facade was, or why the init function > had to have all the values in the 'variable' scope, as long as i did > it. And later on, i came to see why i needed to use the variables > scope, and i came to see that i had been encapsulating my code > without knowing what it meant. > > There are some on this list who are immensely helpful. They must > surely be helping us at the cost of their own productivity. There > are others, (who i wont name) who I think go out of their way to strut > their own superior knowledge to impress all the others on this list - > 'look how clever I am' without helping you at all. I guess you'll > figure out who is in which group, pay attention to the advice of the > one group and ignore the other. > > There are some things I suggest you just accept for now, on the > understanding that you'll eventually see the wisdom. > > I suggest you adopt these as rules to follow, for the mean time, > which will help you get things rolling, and you can decide whether to > continue using them or not later on as you get your head around all > the concepts: > > [A] encapsulate - in other words, never require a CFC to know about > anything outside it. If a CFC needs to know something, pass it in > as an argument to the method, or in the init method > > [B] Never put any display code in a CFC. Treat all your CFCs as > though they are new functions in ColdFusion (which they are really) > and call the method, get a result, then use the code on your calling > page to format the result into display. > > [C] any time you catch yourself writing code you've done before, > consider whether thats time to put that code into a cfc where the one > bit of code can be used in both places as a cfc. > > [D] never put a query in your page code. Always put it into a CFC. > Preferably all your queries on a table in the same CFC. (this is > commonly called a gateway or a DAO cfc, but dont let the terminology > bamboozle you). So if you have 5 tables in your app, you would have 5 > CFCs handling database access. If you follow that procedure, you'll > see the benefit when you have to make a change to your database!! > > [E] inside a function, ALWAYS var your variables. (Sorry, there's > some jargon - I was trying to avoid using jargon). In other words, > if you are using a variable inside the function called 'dateadded', > then at the top of the function, the first few lines after the > arguments, put something like the following: > <cfset var dateadded = "" /> > > What that does is make sure that the value of 'dateadded' will only be > available inside this function. IF there is any other variable > called 'dateadded' somewhere else in your app, it wont overwrite the > value of dateadded here. This keeps your cfcs thread safe. > Imagine if you have 30 people all accessing a page at once. Then you > could have one person's value of 'dateadded' overwrite another > 'dateadded', in use by someone else somewhere else in the > application.. > > [F] an init function looks like this: > > <cffunction name="init" access="Public" returntype="componentname" > output="false" hint="Initialises the controller"> > <cfargument name="dsn" required="true" type="string" /> > <cfset variables.dsn = config.getDatasource() /> > <cfreturn this /> > </cffunction> > > (dont 'var' your variables in the init() function or they wont be > available elsewhere in the CFC). > > And when you want to use a dsn name elsewhere in this component, in > other functions, you do it like this; > > <cfquery name="qQueryname" datasource="#variables.dsn#"> > SELECT * from tablename > </cfquery> > > That way, you pass in the datasource name (also other configuration > variables like passwords, usernames, local time, ) when you > instantiate the CFC and any other method in the CFC can use them > without needing them passed in. > > > > For now, just accept those as rules, and you wont have to stress about > why. These are not absolute rules - there are exceptions and > reasons why you might not want to do these things later. But you'll > get up and rolling quicker if you just accept them as rules for now, > and as you get more experience with OO, and come to understand why > they're there, you can break these rules with understanding. > > > IF you wanted, i'd be happy to share one or two of my CFCs with you > off line on a confidential basis, if you think it would help you. > > Cheers > Mike Kear > Windsor, NSW, Australia > Adobe Certified Advanced ColdFusion Developer > AFP Webworks > http://afpwebworks.com > ColdFusion, PHP, ASP, ASP.NET hosting from AUD$15/month ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;203748912;27390454;j Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:307896 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
