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-Objectcfc
--
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:307834
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
