Of the options you outline #1 and #2 are probably your best bets. Keep in mind for #1 it need not be so ugly -- particularly if you cache these CFC instances you can pass in the "global variables" only once when you init. You could also pass in a struct using ArgumentCollection (or just as a single argument) there, so it could really be quite elegant in your code that uses the CFC. If you have a single instance of your components in the Application (or Server) scope you can code a few lines in Application.cfm and then go on your merry way without thinking about such things ever again.
Option #3 is a bad idea because it breaks the (good) advice of making extends used only for an "is a" relationship -- which it doesn't sound like you'd have here. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Matthew Walker > Sent: Thursday, July 31, 2003 3:50 PM > To: [EMAIL PROTECTED] > Subject: [CFCDev] envronment variables and CFCs > > > Hiya, > > We have a bunch of fairly amateurishly written CFCs (yes guilty) > that access > a few global environment variables in the request scope (say for example > datasource name and a few similar). Now I'm trying to address this and > finding I have a few options.... > > 0) Access environment variables in the request scope directly from the CFC > method. This is the technique I'm undoing, hence option 0. > > 1) pass each environment variable into each CFC method as > required. I think > this is an ugly inelegant solution although conceptually the simplest. > > 2) Create an object containing all the environment variables with accessor > and mutator methods as appropriate and pass in this object when > initializing > any CFC. This is the option I'm in favour of. > > 3) Have each CFC extend a CFC that can access these environment > variables. I > am uncomfortable with this as it seems like the name space of the CFC is > going to be rather crowded with methods -- there'd be > getSomethingVerySpecificToThisObject() alongside getSomeAppSetting() which > seems disorganized. > > Other options? No doubt. This must be a very common, very fundamental > problem. What do other folks do? > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
