Jörg Schaible wrote: > Oliver Heger wrote: > >>I have added new hierarchical configuration implementations >>based on the >>node handler approach. >> >>There is now a new AbstractHierarchicalConfiguration<T> class >>providing basic functionality for dealing with hierarchical >>structures. >> >>Derived from that is InMemoryConfiguration, which is almost equivalent >>to HierarchicalConfiguration. The new SubConfiguration class is the >>counterpart to SubnodeConfiguration. >> >>I copied the tests from the HierarchicalConfiguration, and they run >>successful for the new configuration class. There are minor >>differences in the handling of attributes: I decided not to allow >>multiple values for an attribute as was possible for >>HierarchicalConfiguration as part >>of the list handling functionality. IMO this was rather >>confusing than >>helpful. Obviously these differences are not covered by the >>unit tests. >> >>Next steps are further configuration implementations based on the new >>classes. I will do some experiments with XMLConfiguration and a new >>preferences configuration class. >> >>We can decide how to deal with the old classes. We could completely >>replace them with the new ones or deprecate them only. > > > For a major (incompatible) release 2.0 ... replace them. No need to burden > ourselves with old code maintenance. Get rid of old stuff as soon as possible. > > - Jörg > Agreed. After refactoring of the hierarchical file-based configurations is complete, it shows that the new configurations are indeed a full replacement for the old ones: all unit tests are still running.
About the naming: If all our configurations are hierarchical (at least this is the plan currently), there does not seem to be much point in calling a concrete implementation "HierarchicalConfiguration". Therefore I used the name "InMemoryConfiguration" for the replacement (because the whole data is stored as ConfigurationNode objects in memory). In the first discussions about the new configuration2 branch somebody suggested using a different package structure, which is more focused on modularity, i.e. there should be packages containing configuration implementations with a specific functionality. I would like to follow this suggestion. Any objections or further comments? Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
