KeyValue setting type

[autermann]

Implement a new setting type that pairs two values.

See https://github.com/52North/iceland/issues/31.

[vigneshtdev]

is this feature request still open?

[vigneshtdev]

friendly ping.

[autermann]

Yes, it is.

[vigneshtdev]

https://github.com/52North/arctic-sea/blob/c1103d5dff4e53c327d6aaf995da31a39eb6f9f8/faroe/core/src/main/java/org/n52/faroe/SettingValueFactory.java#L367

I have a created a generic pair class. But here when a new SettingValue is created it is always passed in a string(eg. "X,Y"). How can I get to know about the datatype of X & Y? Or for now do I assume that we are only dealing with strings?

[autermann]

i still need clarification on two aspects:

1. Is the datatype for the pair variables always going to be string?
2. How should this show up in settings.json file
3. What should be default behaviour?

The API was designed without complex settings in mind, so these are currently all strings. For the localized string setting the value contains JSON so I would do the same here. Or if you have the time change the parameter to be a JsonToken.

I have a created a generic pair class. But here when a new SettingValue is created it is always passed > in a string(eg. "X,Y"). How can I get to know about the datatype of X & Y? Or for now do I assume that we are only dealing with strings?

The idea behind the Key-Value-SettingsType is not just to values but to allow the user to input a something like a Map<X,Y>. I think it's safe to say that X is always a String, the type of Y could go into a KeyValueSettingDefinition.

[vigneshtdev]

The idea behind the Key-Value-SettingsType is not just to values but to allow the user to input a something like a Map<X,Y>. I think it's safe to say that X is always a String, the type of Y could go into a KeyValueSettingDefinition.

How will this be different from ChoiceSettingDefiniton? Only the way the setting gets configured will be different right?

[autermann]

The value of a ChoiceSettingDefiniton is the same as for the StringSettingDefinition (a simple String). The only difference is that it specifies which string values are allowed. The options map in the setting definiton maps the allowed values of the setting to the values that are displayed to the user (see here for an example definition). In the end, the options are used to create an HTML snippet like this:

<select>
  <option value="key1">value1</option>
  <option value="key2">value2</option>
  <option value="key3">value3</option>
</select>

[vigneshtdev]

What I had in my mind was something like,

<bean class="org.n52.faroe.settings.KeyValueSettingDefinition">
        <property name="key" value="Center" />
        <property name="title" value="Possible coordinates for center of circle" />
        <property name="order" value="25.0" />
        <property name="group" ref="serviceSettingDefintionGroup" />
        <property name="value" ref="centreCooridnates" />
 </bean>

<bean class="org.n52.faroe.settings.model.Pair" id="centreCooridnates">
        <constructor-arg ref = "doubleValue" />  
        <constructor-arg ref = "doubleValue" />
</bean>

<bean id="doubleValue" class="java.lang.Double">
        <constructor-arg index="0" value="3.7"/>
</bean>

So for a Pair<A,B> B can be a hashMap as well. WDYT?

[autermann]

Sorry, but I see no benefit in having a pair as a setting. You could just use two string settings to accomplish the same.

And if you want do define a setting with a simple String -> String mapping, what is A in Pair<A, Map<String, String>> suppose to contain?

I suggest you start with the following class definition, which pretty much summerizes what is required:

class KeyValueSettingSettingDefinition extends AbstractSettingDefinition<Map<String, String>>

Or, if you want to be brave:

class KeyValueSettingSettingDefinition<V> extends AbstractSettingDefinition<Map<String, V>>

The only way you could use your Pair<K, V> class would be in a list like this:

class KeyValueSettingSettingDefinition<V> extends AbstractSettingDefinition<List<Pair<String, V>>>

But this version has different semantics, as it allows different values for the same key...