Hey Ryan, Why the additional getUtils() function rather than just referring to the functions as variables.myUDF()? That method wouldn't be used outside the CFC would it?
Baz Suggestions so far: 1. Pass the function library to each CFC that needs it. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Guill Sent: Sunday, October 30, 2005 7:38 PM To: [email protected] Subject: Re: [CFCDev] Global Function Libraries One way I have done it before is to create a genFunction.cfc or util.cfc, store it in the application scope on application startup, and then if I need those functions inside of a cfc, pass the cfc into the function in the init(). Then, inside the cfc, store the genFunctions.cfc in like variables.genFunctions or variables.properties.genFunctions, write a method called getGenFunctions() or getUtils() to just return it ( <cfreturn variables.properties.genFunctions /> ) and then you can just use them in your cfcs like getUtils().myUDF(). It works for the most part, but best practices I would say depends on the types of functions you are working with and your specific situation. and yes, I consider it a no-no for a cfc to reference or modify outside scopes. On 10/30/05, Scratch <[EMAIL PROTECTED]> wrote: > > I know this has been talked about and written about a lot but I still can't > seem to find a consensus on the matter: What is the best way to share global > functions throughout your entire application, including being available in > custom tags and ESPECIALLY CFCs? > > Here's what I've run into: > > 1. Put your functions in a Utils CFC and create it in the Application scope > or Request scope. > > 2. Put your functions in a cfm file and name each function application.xxxx > (or request.xxxx) and include that file in application.cfc > > 3. There are many more ways that I've run into which I can't seem to > remember right now :) > > Basic Questions > > - What's better, application scope or request scope? > - Is it not horribly bad to refer to outside scopes form CFCs? > > Cheers, > > Baz > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). > > An archive of the CFCDev list is available at www.mail-archive.com/[email protected] > > > -- Ryan Guill BlueEyesDevelopment [EMAIL PROTECTED] www.ryanguill.com (270) 217.2399 got google talk? Chat me at [EMAIL PROTECTED] The Coldfusion Open Application Library - COAL - http://coal.ryanguill.com www.ryanguill.com/ The Roman Empire: www.ryanguill.com/blog/ ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.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' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
