-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffry Houser Sent: Wednesday, September 29, 2004 7:56 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Function Libraries
At 06:28 PM 9/29/2004, you wrote: >>Encapsulation debate rages like a cult blindness. There is good reason for >>encapsulation... but if you follow that using request variables is always >>bad (or functions) > I've often said that use of the request scope is for people who don't >understand parameter passing. In my experience it is often used to avoid >parameter passing. I didn't say passing variable. <Another grin> Your giving me rhetoric, and not thinking about what I said. I was referring to putting the UDF into request scope! >>then you could never use a CGI variable inside a CFC >>either... that would have to be passed it. (HEH!) > I would agree with that. Are you saying using CGI variables inside CFCs >are good? OK... now to your point... I would not pass variables into a CFC via global scopes... this I agree as bad general practice. Yet... with CF, you would load the same UDF over and over in page after page? This is inefficient and poor coding. Or would you opt to not maximize code reuse? I would not put the variables to pass in into request scope and then just address variables directly, I would use a "CFC Library"... and a function for calling the CFC libraries. ============ Example ============ In a framework you may want to "LOG" issues to a logging system that your company is using currently. They want it integrated into this software. 1. Build a UDF Library to do the logging. 2. "Include" the UDF Library using a "request scope standard UDF" on EVERY page and EVERY CFC that uses the library. The code is not run unless the library isn't already included. 3. Use the logging UDFs ... 4. Update the library as needed to manage the centralized UDF function code reuse in ongoing updates. That is what I do. John Farrar SOSensible ---------------------------------------------------------- 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]
