On Dec 13, 2008, at 12:42 PM, Oliver Heger wrote:
Ralph Goers schrieb:
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.
I don't think any dummy implementations are needed. If
BaseConfiguration extended AbstractHierarchicalConfiguration instead
of AbstractFlatConfiguration it would need to override createNode to
disallow node creation and register the FlatNodeHandler . Other than
that what else would need to be done?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
