[xxx.yyy] key=value
After reading the file we would have this property: xxx.yyy.key=value
If we assume the part of the key before the first dot is the section name, then on saving we would get:
[xxx] yyy.key=value
Prefixing the key with the section name and its brackets may be a solution, but I don't know how it will work with subsets.
[section1]key1=value1 [section2]key2=value2
Also I've found some useful information regarding the ini file format: http://cloanto.com/specs/ini.html
Existing ini file parsers in Java: http://www.bebbosoft.de/api/de/bb/util/IniFile.html http://unidata.ucar.edu/packages/dods/api/javaDocs/dods/util/iniFile.html http://www.ubique.ch/code/inieditor/javadoc/ch/ubique/inieditor/IniEditor.html
Emmanuel Bourg
Inger, Matthew wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
