Multivalue properties

[sghpjuikit]

Property multivalue support is important for 2 reasons:

• no problem with escaping/value joining
• more readable file

This issue aims to also implement this support for xml format used for widget properties.

The ideal is to remove any value joining going on and prevent data corruption as well as avoid character escaping. Lastly Config.toS/ofS/valueS conversion API should be updated/removed.

[sghpjuikit]

Working prototype implemented. I added another abstraction layer, so basically we have: property file -> Map<String, List<String>> -> Map<String,PropVal> -> List<Config<T>>

This is really nice, because it allows treating multivalues in property files explicitly, like:

file.readProperties()  // returns Map<String,PropVal>
file.readProperties()["keyForMultiValue"]  // returns PropVal
file.readProperties()["keyForMultiValue"].val1  // returns String
file.readProperties()["keyForMultiValue"].valN  // returns List<String>
file.readProperties()["keyForMultiValue"].valN  // returns List<String>

User who doesn't care only needs to use val1 on each access (not a big deal), and the user who cares will benefit tremendously - no more parsing, joining, bothering.

The PropVal is sealed class and seals Prop1/PropN. They can be easily used polymorphicaly (e.g. to populate maps) and with the abstract val1/valN they interop very well - single value requested as multivalue becomes singleton list, while multivalue requested as single value will return 1st element (because technically every single value is 1 element multivalue) and safely, since the list can not be empty (this can not of course be guaranteed, see map.put("x", PropVal(listOf)).get("x").val1 // fail), but is only problem in code, going through the write/read into the property file, no empty values will be present.

[sghpjuikit]

I'm almost done. Everything is awesome except one issue:

Empty list creates empty multi-value, which means 0 key=value pairs written in the property file. While that sounds intuitively correct, it makes it impossible to distinguish no multi-value and empty multi-value. We must be able to distinguish these, as it decides whether default value will be overridden by empty or stay as default.

We require:

• ability to distinguish empty multi-value and no multi-value
• no additional escaping
• no key or value corruption
• no ambiguity what is key/separator/value

Using a placeholder for value nor key leads to no good. Hovewer, using different separator than = seems to be suitable here.

I will use =>, as a terminating =, because no value can follow it. If a value follows it, as in some.key=>some value, then it is part of a value, which is >some value, because => means empty value for its key. As can be seen, this elegantly checks all the requirements we have.

[sghpjuikit]

Implemented in 37b85c5