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
On Sat, Jun 21, 2008 at 1:10 AM, Rick Faircloth
<[EMAIL PROTECTED]> wrote:
> Thanks for the info, Matt.
>
> I think I've got a handle on those methods.
>
> One thing I still haven't been able to get to work
> is setting up an "init" function for my db in a cfc.
>
> 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?
>
> I'm just lacking in my understanding, I think, of what the CFC
> is providing for the calling page with this type of code.
>
> Perhaps it's time to get the CF8 version of CFWACK.
> (Last one I got was for CF4.5... :o)
>
> Rick
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
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:307893
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
