Thanks for the info and code, Matt. I'll try out your example and see what happens.
Rick > -----Original Message----- > From: Matt Williams [mailto:[EMAIL PROTECTED] > Sent: Friday, June 20, 2008 11:32 AM > To: CF-Talk > Subject: Re: Waaahhhh! Why won't my CFC work! > > On Fri, Jun 20, 2008 at 10:10 AM, Rick Faircloth > <[EMAIL PROTECTED]> wrote: > > Can you explain how that work and show me an example > > of the code I need to put in a cfc. > > > > I tried this that someone gave me: > > > > <cffunction name="init"> > > <cfargument name="dsn"> > > <cfset variables.dsn = arguments.dsn /> > > <cfreturn this> > > </cffunction> > > > > But that doesn't make sense to me. My dsn is set > > in application.cfm like so: cfset application.dsn = "myDB". > > So why, "variables.dsn" above? > > > > I just don't understand what the code is doing. > > Why is variables.dsn being set to be the value of > > arguments.dsn? And what exactly does "cfreturn this" do? > > > > The idea here is to keep you cfc separate from the application so it > is more re-usable. It is good practice to not reference application > scope (or form or session, etc.) directly in your cfc (there are > always exceptions to this, as Tom mentioned a facade earlier). But in > keeping it simple, this init function is receiving the dsn as an > argument and putting it in the variables scope so that the cfc does > not have any knowledge of the application scope. > > When you do <cfset myNewInstance = > createObject('component','myObj').init(application.dsn) /> that is > telling the server to create a new instance. This instance will be put > in the server memory. By using <cfreturn this />, the instance is > returned to whatever calls it. In other words, the variable > "myNewInstance" holds a reference to that object. > > If you have the basic setup working, try a cfdump on myObj. > <cfset myObj = createObject('component','myObj').init(application.dsn) /> > <cfdump var="#myObj#" /> > > You'll see what looks like a structure output of all the methods > defined for that object. Some folks like to also add a "dump" method > to their cfcs. > <cffunction name="dump"> > <cfreturn variables /> > </cffunction> > > With that, you can do this: > <cfdump var="#myObj.dump()#" /> > That will show you the values that are held within the variables scope > (doing this you will also see each function definition). > > I just got Ian's post. He explains the different scopes. > > I think one of the main things you'll need to grasp first is that when > you create this object, it exists in memory and holds data and > functions with which you can interact. Because of this, you'll want to > think about what scope an object should exist within. An object that > holds information specific to one user makes sense to be in session > scope. But an object that can be used by many users should probably be > in application scope. This is one of the advantages Object Oriented > programming. Otherwise you are just creating and destroying objects > for every request and may as well do it inline or with cfincluded > files. > > Hope that helps. Keep the questions coming though. There are also many > blog entries on some of these basics. Adrian Moreno's blog comes to > mind first. He did a whole series. > http://www.iknowkungfoo.com/blog/index.cfm/2007/8/22/Object-Oriented-Coldfusion--1--Intro-to-Objectc fc > -- > Matt Williams > "It's the question that drives us." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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:307847 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
