A configuration CFC could be considered simpler than having another syntax to know about in your application. From a performance perspective I doubt it makes much difference:
Example 1: Instantiating a config bean: 1. Instantiate config bean and place it in a shared scope. Example 2: Loading configuration from a file: 1. Instantiate XML parsing object. 2. XML parser reads the configuration file from disk and places it into a shared scope. Either way you're creating some object and sticking some artifact into a shared scope. I guess if you have numerous configuration beans this could become burdensome, but I can't see a reason to create a whole lot of 'em. Just my 2 cents. Eric On 6/7/07, Jeff Chastain <[EMAIL PROTECTED]> wrote:
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
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
