At 09:31 PM 9/29/2004, you wrote:
-----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!
My understanding..
You were referring to putting a UDF in the request scope that you can reference it inside a component w/o having to pass it as a parameter. Is that incorrect?
>>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.
I was under the impression it was considered a good practice. It is not inefficient because after the "first load" it is generally already compiled (and your function library template will have already been compiled into byte code and cached). I know I'm not making this up, so I must have read it somewhere.
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.
Can you elaborate? How do you "include" something in the "request scope"? The request scope does not persist between requests, so how is loading the UDF into it different than including a cfm file on every page?
3. Use the logging UDFs
...
4. Update the library as needed to manage the centralized UDF function code reuse in ongoing updates.
--
Jeffry Houser, Web Developer, Writer, Songwriter, Recording Engineer
<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>
--
When did Reality Become TV
----------------------------------------------------------
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]
