Hello, I'm not sure if I understand what you mean.
My problem with the addProperty() method is not caused by some kind of error a unit test could detect. It's merly a design issue. At the moment addProperty() is implemented so that it first handles stuff related to collections or string values that contain multiple property values. This is fine because it is a generic feature support by all configuration classes. But then instead of calling addPropertyDirect() it calls getPropertyDirect() and performs the adding by hand. Here it creates a Container if necessary and adds this container by calling addPropertyDirect(). This part is not compatible with my implementation and is in my opinion to much tight to a concrete mechanism of storing the properties. I could of course overwrite addProperty() in my implementation, but then I would have to copy the first part which deals with the collections. To demonstrate the direction I am following with my HierarchicalConfiguration I have attached an early version of a corresponding unit test. The test of the getProperty() method shows how single elements of complex property lists can be accessed. Greetings Oli ----- Original Message ----- From: "Eric Pugh" <[EMAIL PROTECTED]> To: "'Jakarta Commons Developers List'" <[EMAIL PROTECTED]> Sent: Wednesday, October 10, 2001 12:12 PM Subject: RE: [configuration]HierarchicalConfiguration > Can you provide a unit test that demonstrates the problem? If the problem > is because of your specific subclass, can you just create a mock version? > That way we have something firm to lookat, and then we can discuss the > pro's/con's of moving the methods around... > > Eric > > > -----Original Message----- > > From: Oliver Heger [mailto:[EMAIL PROTECTED] > > Sent: Friday, October 10, 2003 11:32 AM > > To: Jakarta Commons Developers List > > Subject: Re: [configuration]HierarchicalConfiguration > > > > > > Hello Eric, > > > > I did not mean to remove the whole Container stuff from > > AbstractConfiguration. I think Containers are still needed > > (at least) to > > distinguish results of getPropertyDirect(): is the result a > > single property > > of type Collection or is it a list of properties of scalar types? > > > > My problem is only with the addProperty() method that is > > implemented in > > AbstractConfiguration in a way that it enforces multiple values of a > > property to be stored in a Container - and I want to do it different. > > > > So I would like to suggest to move the part of the > > AbstractConfiguration.addProperty() method that deals with > > Container to the > > addPropertyDirect() method of BaseConfiguration and let > > AbstractConfiguration.addProperty() call addPropertyDirect > > instead. This > > makes it possible to use different storage algorithm in > > derived classes. > > > > As far as I see addProperty() is the only method that assumes such a > > Container specific storage logic, but there may be other > > locations I have > > not found yet. > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
