Am 17.08.2011 00:04, schrieb Emmanuel Bourg:
Le 16/08/2011 22:27, Oliver Heger a écrit :
Aren't we free to decide how to represent data structures in a
configuration? I mean, the dot keys used by XMLConfiguration is also
just a convention. We could transform a plist file to a XML-friendly
structure and store it in a hierarchical configuration. We just have to
document how to access list structures. We could then add specialized
convenience methods to PListConfiguration for accessing lists in a way
more intuitive for plist users. Wouldn't this be an option?
Our plist configurations are already hierarchical. The difference lies
in the way the lists are stored.
In the XML way a list is typically structured as:
root
list
element -> value1
element -> value2
element -> value3
In the plist way it's structured as:
root
list -> [value1, value2, value3]
My understanding is that in a plist file a path can't be used more than
once. So if you explode the structure of a list to put one element per
node, you have to reverse the operation and regroup sibling nodes into a
list when the configuration is written. Headache guaranteed for the
implementer :)
Yes, it would certainly mean more effort on implementation side, but it
would also gain some benefits for users. We do transformations for other
configuration implementations, too, e.g. in
HierarchicalINIConfiguration. Well, the transformation for plist
configurations seems to be more complex.
That said, I am not against the patch. If you think it works for most of
the users, just go ahead and commit it. Alternatively we could postpone
this issue to the next release, so there is more time to think about a
solution. I am still on the opinion that it makes sense to get out a
binary compatible release soon which has been updated for Java 1.5. Here
the fix could be included.
Oliver
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
