Probably not a good idea - I'd store the DSN etc. in a separate CFC, and pass it to the DAO CFCs in their constructor.
If the DAO's job is to provide data access and the Config CFC's job is to store configuration information, the answer to the question "Is-a DAO cfc a Config cfc?" is "No" - that's a good indicator that inheritance is the wrong way to go. I'd also in turn initialize the config CFC with a file (probably XML) that actually contains the configuration information, so that you don't change any code, just config files, when you deploy your app. -Joe On 8/25/05, Scratch <[EMAIL PROTECTED]> wrote: > > > Is it bad practice to have all your DAO CFCs extend a main DAO CFC that > stores the DSN, UN, PW? > > > > ---------------------------------------------------------- > 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). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > -- Get Glued! The Model-Glue ColdFusion Framework http://www.model-glue.com ---------------------------------------------------------- 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
