> what about data manip function libraries, re-usable > validation routines, etc? we convert (almost) all of our > queries to arrays'o'structs. It would be madness to have the > same util functions within every CFC.
Of course don't do this, you have a utility CFC with these methods, and then call it in whatever code (CFC or otherwise) needs the methods. Remember, lots of little objects that do a very specific task. This would NOT be good candidate for a singleton in the application scope, because if it were, then all your CFCs would have to break encapsulation to reference it. There are certainly cases where this is acceptable and desirable, but in general, CFCs shouldn't depend on their environment for anything. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Barry L Beattie > Sent: Thursday, July 08, 2004 1:34 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] using cfinclude within components (was > Serialization of CFCs) > > three points: > > 1) > Jay Gibb >> under what conditions do you find yourself using UDFs? > Barney Boisvert >>Very rarely. > > what about data manip function libraries, re-usable > validation routines, etc? we convert (almost) all of our > queries to arrays'o'structs. It would be madness to have the > same util functions within every CFC. We use 3) below to do > this. See if you can track down Robin Hilliards "autobean" > framework that does this in (IMHO) quite a cute way. > > 2) mind the difference between cfimport (aka "cftaglib") and > cfinclude. The way the variable scopes interact is a factor > to consider between them. Not always relavent but it can bite > you in the bum... > > To show that cfinclude within a CFC's method is do-able, > check out this data access method in the fourQ framework > within FarCry CMS. > > <cffunction name="getData" access="public" output="false" > returntype="struct" > hint="Get data for a specific objectid and return as a structure, > including array properties and typename."> > <cfargument name="objectid" type="uuid" required="true"> > <cfargument name="dsn" type="string" required="false" > default="#application.dsn#"> > <cfargument name="dbowner" type="string" required="false" > default="#ucase(application.dbowner)#"> > <cfset var stObj = structNew()> > <cfset var qgetData = ""> > <cfset var tablename = ""> > <cfset var aProps = ""> > <cfset var key = ""> > > <cfinclude template="_fourq/getData.cfm"> > > <cfset this.bgetData = 1> > <cfreturn stObj> > </cffunction> > > > 3) more and more people are creating persistant (app or > server scope) central or "kernel" CFC's (singletons - only > one instanciated) that have their utils available at all > times. You could also "decorate" your CFC's with the util > ones (a "has a" relationship) > > just a thought or two > cheers > barry.b > > > -- > _______________________________________________ > Talk More, Pay Less with Net2Phone Direct(R), up to 1500 > minutes free! > http://www.net2phone.com/cgi-bin/link.cgi?143 > > > > > ---------------------------------------------------------- > 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] > ---------------------------------------------------------- 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]
