I don't particularly like the idea of adding additional methods onto
concrete classes. I would rather use the "subset" method of the
configuration interface if someone wants to deal with a particular
section. Note however, that when you use "subset", any changes
in the new configuration don't affect the parent. Someone would
still have to go back and change the parent.
I prefer the idea of prefixing the section name. It's a simpler
implementation (though i could easily come up with a bigger hierarchy
complete with some sort of NamedConfiguration interface and so forth)
where calling subset and changing the subset would affect the parent.
IniFileConfiguration conf = ...;
Configuration sub = null;
String sectionName = null;
Iterator it = conf.getSectionNames();
while (it.hasNext()) {
sectionName = (String)it.next();
sub = conf.subset(sectionName);
}
-----Original Message-----
From: Emmanuel Bourg [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 03, 2004 2:27 PM
To: Jakarta Commons Developers List
Subject: Re: [Configuration] IniFile
That might be interesting, I see 2 approaches, either prefix the keys
with the section name, thus your example would produce the following
properties:
section1.key1=value1
section2.key2=value2
or handle a .ini file as a composite configuration, with 1 configuration
per section. A WindowsConfiguration class could be a subclass of
CompositeConfiguration with additional methods for loading/saving the
configuration, and adding a property under a specific section (something
like setProperty(String section, String key, String value)).
Emmanuel Bourg
Inger, Matthew wrote:
> Any interest in an INI File configuration class?
> It would read a Windows style .ini file. A sample:
>
> [Section1]
> key1=value1
>
> [Section2]
> key2=value2
>
> would produce the following properties:
>
> Section1/key1=value1
> Section2/key2=value2
>
> Unfortunately, empty sections would not be dealt with
> by the existing state of what i have.
>
> -----Original Message-----
> From: J�rg Schaible [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 03, 2004 8:35 AM
> To: Jakarta Commons Developers List
> Subject: RE: [Configuration] Standard DOM ?
>
>
> Emmanuel Bourg wrote on Wednesday, March 03, 2004 2:22 PM:
>
>
>>J�rg Schaible wrote:
>>
>>
>>>Well, this is not what I would like to have, again because of the
>>>dom4j dependency. I already have a
>>
>>HierarchicalDOMConfiguration that
>>
>>>is based on the w3c classes only. I just took the code from
>>>HierarchicalDOM4JConfiguration and replaced the relevant parts. The
>>>same could be done for a DOMConfiguration. To complete the DOM
>>>support a <dom> tag could be supported by the factory. Also the
>>>factory could be refactored so that the most functionality is in an
>>>abstract base class and the derived classes would add the supported
>>>tags. ConfigurationFactory would support anything contained in the
>>>configuration package (= backward compatibility) and the user could
>>>create his own factory with the elements he would like to use (and
>>>their dependencies). Additionally this would allow user-defined
>>>Configuration classes or the support of DatabaseConfiguration in the
>>>factory.
>>>
>>>What do you think?
>>
>>I don't know the motivations for using DOM4J, but using the standard
>>interfaces and removing a dependency is certainly interesting.
>>
>>A pluggable extension mechanism for the ConfigurationFactory would be
>>nice too.
>
>
> Do I have to consider something else concerning submission/donation of the
> code?
>
> Regards,
> J�rg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
