| Re: [higgins-dev] configuration component requirements |
|
In regards to #3, I would rather we find a common place to hold these "handlers". If it's up to each component, or each consuming application, there will be at least a few (I'm thinking of Mike's at least) that get duplicated across different projects. That doesn't require any component or application to use the common handlers, but it allows them to if they want.
Jim
>>> Greg Byrd <gbyrd@xxxxxxxx> 5/16/07 9:09 AM >>> 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 |