| Re: [higgins-dev] configuration component requirements |
|
On (3) I thing we should provide implementations for various forms, supporting things like xml file, dom, stream and others are not STS specific.
Duane
>>>
I'm trying to nail down requirements for the Configuration component. I've looked at Mike's configuration code for the STS, and I think I understand it fairly well. I'm not quite sure what should be carried over into the cross-cutting component, and what should be generalized. What I'm thinking so far (and most of this comes verbatim from Mike's code): (1) An ISetting interface that encapsulates a name, a type, and a value (all strings) for a configuration setting. (2) An IConfiguration interface, so that objects of this type can be passed in to component-specific configuration methods. As it is now, IConfiguration only has get methods -- to get a single ISetting, or the Map (where ISettings are indexed by name), or an iterator over the Map. (3) Should we then provide a set of implementations that convert data from various forms to the map described above? For example, Mike's ConfigurationHandler and the other various SettingHandler types allow an XML file/stream to be parsed. Should this be in the Configuration component, or is it specific to STS? Should we create other components, such as a property file reader, or should this be done on an as-needed basis by different component owners? ...Greg |