Jörg Schaible wrote:
Emmanuel Bourg wrote on Tuesday, March 30, 2004 4:44 PM:
Hi, last week I started playing with the Preferences API and
a Windows
configuration manipulating the registry through JNI. I had not
experimented with hierarchical configurations before, this
led me to a
dumb question : what are we supposed to do when a key
contains a dot ?
Should we search the value in the sub nodes or get the first property
in the current node matching the key ? This issue can be
illustrated with
the following XML configuration:
a
b
cvalue1/c
/b
b.cvalue2/b.c
/a
What's the key a.b.c supposed to return ? value1 ? value2 ? Or
an array with both ?
A lot of configurations have a hierarchical structure : LDAP,
JNDI, the
windows registry, INI files (a tree a depth 1), XML files, the Avalon
configuration API, the JDK 1.4 Preferences API. That makes me
wonder if
we aren't on the wrong track for a generic configuration API,
[configuration] is Properties centric for historical reasons,
should we
keep trying to flatten hierarchical structures and make them
look like a
.properties file ? Should we change the Configuration interface to
support hierarchical structures directly (and turn
PropertiesConfiguration into a tree) ?
To clean-up the resurrected HierarchicalConfiguration problem, you will have to do this anyway. And IMHO you're right and I already mensioned that e.g. JDNI's nature *is* hierarchical. Even the java properties are. The flat structure is just a special case of a more generic hierarchical structure. The flat accessor a.b.c is a shortcut for a(0).b(0).c(0).
Should we support both
separately with an XPath like syntax to unify the keys ?
Definately, but post 1.0. I think you will be able to remove a lot of code with a real generic solution. For 1.0 we will have to modify the Configuration interface at least in a way, we can solve the problem with HierarchicalConfiguration and Oliver had a solution for this (making Configuration hierarchical arware).
Regards,
Jörg
Unfortunately I won't have time prior to Thursday evening. Can you tell
me which unit tests are failing? If it's only the test for
ConfigurationXMLDocument, I would suggest to drop this class in the 1.0
release and add it later again (I think it is unlikely that this class
is already used; it was lost after the move from sandbox and nobody
noticed). Other tests should not fail because they still worked after
the SubConfiguration refactoring.
If we start thinking about more support for hierarchical configurations
(an approach I really welcome), I now don't want to come up with a quick
solution for the actual problem. It would be much better to do it right
in the next release.
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
