Ralph Goers schrieb:
On Dec 13, 2008, at 7:28 AM, Oliver Heger wrote:
There are of course configurations like MapConfiguration that are not
hierarchical by nature. The classes in the "flat" package provide a
hierarchical view on these classes. The idea is that when a
hierarchical node structure is needed, it is constructed on the fly
resulting in a root node and all properties stored in the
configuration as child nodes. (So there is only a single layer
hierarchy.)
But this is also experimental. I am not sure whether this is the way
to go or whether these configurations should be transformed into true
hierarchical configurations as is done by the
ConfigurationUtils.convertToHierarchical() method.
The problem I have is with the interface. Forcing applications to use
AbstractHierarchicalConfiguration as the "base" configuration object
they code to is wrong, IMO. Either they should use the Configuration
interface, which would need to include the hierarchical APIs such as
configurationAt, or they should use HierarchicalConfiguration, which
should be converted to an interface.
If the goal - which I think was a good one - is to make everything be
hierarchical, then Flat is just a special case where no subtrees exist,
i.e. the root of the hierarchy is a leaf node. The only thing you really
need to do in that case is prohibit adding child nodes.
So my recommendation would be to change the Configuration interface to
include the hierarchical methods.
Ralph
I fully agree. It was intended to add the methods for hierarchical
configurations to the Configuration interface, so that everything is
available through this interface.
Unfortunately I did not make too much progress in refactoring the
configuration2 branch. My idea was to make all configurations
hierarchical first (and the flat package was a step into this direction)
and then extend the Configuration interface. It would also be possible
to do it the other way around; then we would have to add dummy
implementations for the new methods to all configurations which are not
yet hierarchical.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
