I agree on option 0...a no go. Option 3 I think would limit possible inheritance needs in the future (but I might be wrong?). Option 2 seems to still defeat the idea of encapsulation (from a completely academic perspective) because the cfcs would still be dependant on this configuration object referenced internally? I have chosen 1 for my applications.
You could always build an configStruct that could grow or shrink as other variables are added, then in all the obj.init() you could pass in the struct via obj.init(environment=configStruct) that kind of keeps is a bit more organized. Also, that configStruct could then be set up in the application (refer to B. Ohara's artilce in last month's cfd). That is the course of action I would pursue. Take care, Justin -----Original Message----- From: Matthew Walker [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 4: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). ---------------------------------------------------------- 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).
