Is there any reasoning / logic behind having your configuration information stored in a bean vs. some other method? I have seen some applications design using a collection of configuration beans and other applications designed using an xml file that is just read and parsed into a 'config' structure. If your configuration information is not really changing (maybe this is a bad assumption), is there any reason for having the extra overhead of the beans and their instantiation instead of just a static structure of key = value pairs?
Thanks -- Jeff From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Bell Sent: Thursday, June 07, 2007 3:44 PM To: cfcdev@cfczone.org Subject: Re: [CFCDEV] Application.cfc: where to set DSN +1. Only thing I put into application.cfc (in terms of a config property) is application.name which I need to include the framework that calls the application specific config bean that contains all of the other app specific config info. Encapsulating it in a config bean gives you a bunch more flexibility to change how it is created or stored without breaking the API you expose to the rest of your app. Best Wishes, Peter You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
