Jeffry:
I'll assume
the other posts answered your first question about why init() is good -- I'll
just add that it's other benefit is that it makes use of CFC "objects" more
closely mirror use of other objects (i.e.: java objects) in
CFML.
As to why
OUTPUT="false" is a good thing -- the main reason is that you don't want to
break encapsulation. By outputting directly to the output stream you
assume knowledge of the external environment of the CFC, whereas if you return a
string you get the exact same behavior when you do simply
#myCFC.someHTMLGeneratingMethod()# but you gain the advantage of not assuming
that's how your method will be used (for instance, what if the method that
returns the string is used inside of a big CFSCRIPT block where someone is
building a string via concatenation?). The other reason is that if you are
not even trying to output text you'll end up with unwanted white space if you
don't use OUTPUT="false".
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Jeffry Houser
Sent: Tuesday, March 16, 2004 1:58 AM
To: [EMAIL PROTECTED]
Subject: Re: [CFCDev] RFC, CFC Best Practices
Why are 5 and 6 considered a best practice?
5. Always have an init() method that acts as your constructor and returns "this" (unless you are building a web services/flash remoting
facade.)
I understand that using this approach you can call the init() method and create your instance w/ one cfinvoke tag. Why is this better than using the "psuedo-constructor" which will operationally do the same thing. ( Or even the BD cfconstructor tag )
6. Always (with rare exceptions) use OUTPUT="false" in your CFFUNCTION and CFCOMPONENT tags. Do not output directly to the buffer inside a CFC method -- instead return a string.
Why? Are there known performance issues?
As with in regular CFML pages, I consider a best practice to be to scope all your variables. With that said, would your optional / well worn best practice better be stated as "variables.instance.xx"?
At 11:38 PM 3/15/2004, you wrote:
I've noticed that many of the best practices talked about on this list are
not as widely known as I would have thought. What's worse, most of the
basic best practices related to CFCs are not well documented or are
documented in disparate places.
I'm trying to capture a concise list of CFC best practices that everyone
coding CFCs should be aware of (if not follow).
Perhaps some of y'all have comments/additions/criticisms, which I'd welcome:
http://www.dintenfass.com/cfcbestpractices/
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]--
Jeffry Houser, Web Developer <mailto:[EMAIL PROTECTED]>
Aaron Skye, Guitarist / Songwriter <mailto:[EMAIL PROTECTED]>
--
AIM: Reboog711 | Phone: 1-203-379-0773
--
My Books: <http://www.instantcoldfusion.com>
Recording Music: <http://www.fcfstudios.com>
Original Energetic Acoustic Rock: <http://www.farcryfly.com>
