commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <heg...@med.uni-marburg.de>
Subject Re: [configuration]Hierarchical design
Date Fri, 16 Apr 2004 06:01:55 GMT
I have been thinking about this subject for a while. How about the 
following scenario:

ConfigurationNode and Configuration are still separated, but it is 
possible to open a sub configuration anywhere in the hierarchy. I would 
therefor add a subConfiguration() method to the Configuration interface. 
The difference between subset() and subConfiguration() is that the 
latter expects an expression that yields in exactly one node (otherwise 
a runtime exception will be thrown). The key passed to subset() in 
opposite may result in an arbitrary number of nodes.

The subset() method returns a ViewConfiguration, which is more complex 
because it needs to be notified about changes in the hierarchical node 
structure; then it has to rebuild itself. A sub configuration on the 
other hand by being part of the hierarchy is automatically aware of changes.

I think this approach would be quite flexible. It allows the clients 
full access to each part of the hierarchy. The ConfigurationNode 
interface will be used internally by the expression engine (for 
traversal and selection), access to configuration data is done through 
the Configuration interface.

Any comments?

Oliver

Emmanuel Bourg schrieb:
> imho Configuration and ConfigurationNode should be merged into a single 
> class, because a Configuration is basically a node in a hierarchical 
> design.
> 
> 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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 


-- 
Dipl.-Inform. Oliver Heger
Zentrale Informationsverarbeitung (ZIV) / Bereich Anwenderverfahren
Klinikum der Philipps-Universit├Ąt Marburg
Bunsenstra├če 3,
D-35037 Marburg
Tel: +49 6421 28-66592
mailto:oliver.heger@med.uni-marburg.de

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message