The way I understand it, the object is a standard holder of
configuration settings. The other components can use it how and when
they want -- they'll need to have a configure method that takes in an
IConfiguration object. So I think this would work either way. If an
already-initialized component has its configure method called, it could
say "No, I'm already configured," or it could accept the new
information and reconfigure dynamically.
What we're standardizing is the way to pass such information in, so
that (a) it's programmatic, rather than file-based, and (b) each
component does not need to define its own data structure for doing this.
(Again, this is what I thought I heard -- others can correct me, if I'm
wrong.)
...Greg
Anthony Nadalin wrote:
So I have not looked at code but is this also for runtime config
or just initialization configuration ?
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
 Greg Byrd <gbyrd@xxxxxxxx>
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
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
|
