commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver.He...@t-online.de (Oliver Heger)
Subject Re: [configuration]Hierarchical design
Date Tue, 13 Apr 2004 09:38:15 GMT
 From my POV there is a difference between a ConfigurationNode and a 
Configuration: a node is just a simple piece of data while a 
Configuration is comprised by the whole hierarchy of nodes. It lies in 
the Configuration's responsibility to maintain its nodes and to provide 
methods for querying or manipulating them.

If you do not have such a superior instance, working on the nodes will 
be quite difficult. I think you could compare this with the difference 
between a DOM4jConfiguration and the corresponding DOM tree. Of course 
the DOM contains the whole data and is a true hierarchical structure. 
But convenient access becomes possible through the configuration object.

Oliver

Emmanuel Bourg wrote:

> 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
>
>



---------------------------------------------------------------------
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