Hi, I have now created a patch with my first implementation of HierarchicalConfiguration and related classes. Here are some remarks to the new classes:
HierarchicalConfiguration This is a base class for configuration classes that use a hierarchical schema to store their properties. The class is fully functional and provides meaningful implementations for all abstract methods defined in AbstractConfiguration. HierarchicalDOM4JConfiguration A sub class of HierarchicalConfiguration that allows to parse XML documents using DOM4J. This class does the same as DOM4JConfiguration, but keeps the structure of the parsed documents. Saving of configuration properties is not implemented yet. HierarchicalConfigurationXMLReader This class is a faked SAX parser that operates on HierarchicalConfiguration objects. It processes a configuration object and generates corresponding SAX events that can be caught and evaluated by a ContentHandler implementation. The associated unit test shows how this class can be used to construct a DOM4J document from a configuration object. With this class it should also be possible to feed configuration objects into a Digester. ConfigurationKey This class is used internaly to construct keys and iterate over the single parts a key consists of. I made it public because it may be useful for clients as well. The class hides the concrete syntax of a property key, so instead of dealing with strings, property delimiters, index or attribute markers a client only needs to call methods of this class. There are unit tests for each of these classes; according to the reports they have a quite high coverage rate ;-) Please send me your critics, ideas and suggestions and your thoughts how (and if) to integrate this stuff with the existing code. I think the concept of transforming a Configuration object to XML by using a simplified SAX parser could be useful for non hierarchical configuration objects, too. So it would be nice to have a corresponding implementation. Then there is another idea that came me when I wrote HierarchicalDOM4JConfiguration: How about separating the code for writing configuration objects from the configuration classes? There could be different ConfigurationOutputter classes for different formats (properties, XML, ...). This would have a couple of advantages, e.g. it would allow to save configuration data in another format than it was loaded from. What do you mean? Oli
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
