I am writing a global config object and I wanted to get some thoughts from others on the list about structuring the components. I have three components- a singleton, a factory, and a config component. T
The config object is a per-app object that sets global configuration information. Per-app, but not per application (in the cfapplication sense). It is intended to allow you to load (and reload) separate configuration objects per sub-application in a larger app.
The singleton is just that - a lightweight component that just sets/gets the factory in the application scope, ensuring there is only one factory object.
The factory creates, holds, and returns config objects by appName. The question I have is about dividing functionality between the factory and the config components. At first I designed the config component to do everything, so I would pass in a path to an XML file, load the config from there, then return the object.
I would like to be able to reset the config on demand without re-creating the object, so the way I see it I have two choices. I could make the setConfig() method in the config component public and access it directly, or I could limit it to package access and force config changes to run through the factory. I see advantages and disadvantages on both sides, mainly coupling v. control over access. Anyone have thoughts on what they would do?
As a twist, the config component is currently written in CF, but I might re-write it in Java to be able to re-use it elsewhere.
TIA,
Rob
--
---------------
Robert Munn
www.funkymojo.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).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
