Emmanuel Bourg
Oliver Heger wrote:
I have been experimenting with a more hierarchical design for configuration classes and would like to bring in my results for discussion. You can download a zip under
http://www.oliver-heger.privat.t-online.de/hierarchicalconfig.zip
What I have done so far is to extract the internal Node class from HierarchicalConfiguration. There is a new interface ConfigurationNode and an implementation called DefaultConfigurationNode. Also the evaluation of property keys was extracted from the configuration class. A new component, an expression engine, is now responsible for this task. This makes it possible to plug in different expression languages. I have created an implementation, which can evaluate the expressions supported by HierarchicalConfiguration so far.
The Configuration interface was extended by methods for setting and getting such an expression engine and a root node of a hierarchical configuration. If we deal mostly with hierarchical configuration sources, then maybe in the future HierarchicalConfiguration should replace BaseConfiguration as the one for all configuration base class, but this is open to discussion.
In this approach SubsetConfiguration can not simply be implemented by transforming property keys because interpretation of keys lies in the responsibility of the expression engine (and I doubt that such a transformation is always possible when complex expression languages like XPath are involved). So I came up with the concept of view configurations. As the name implies a view configuration provides a logic view to another configuration or set of configurations. To keep the view life I implemented a simple event notification system: the views register themselves at the original configuration and thus receive notifications whenever changes occur. A change causes a view to be rebuilt when it is accessed the next time. As the unit tests demonstrate, this works in both directions and also with multiple views involved.
The zip contains all classes and some unit tests. Note that I put all the stuff in a new hierarchy sub package, but that is only to have an independent code base and not to mess up some other classes before the release.
Please have a look at the code and give me some feedback. If there is consensus that this approach should be followed, I can go ahead and re-implement CompositeConfiguration as a view configuration in both flavours: as overload and as union configuration. I think this would significantly reduce code in ConfigurationFactory and would make the planned refactorings much easier.
Regards Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
