Ralph Goers schrieb:
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?
So you mean that AbstractFlatConfiguration is not needed as a base class
for non-hierarchical configurations?
Its main functionality is to provide support for creating the tree of
configuration nodes on demand and keep it up-to-date. Derived classes
can still operate on their native data structures, e.g. maps.
If you extend AbstractHierarchicalConfiguration directly, wouldn't you
have to implement the handling of nodes yourself?
But anyway, its a while since I deeply looked into these things. If you
want to try something out, don't hesitate!
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
