I have a need to create multi-value properties that either contain no value or
just a single value.
In JSon the looks like this:
{
“noValueMulti”: [],
“singleMultiValue”:[“single”]
}
Because the Repository Initializer is using a comma separated list as indicator
when to create a multi-value I cannot do either of these.
I would suggest that you allow something like this:
set properties on /pathC
set noMultiValue{String[]} to
set singleMultiValue{String[]} to “single”
end
Cheers - Andy
> On Feb 1, 2021, at 3:57 PM, Andreas Schaefer <[email protected]> wrote:
>
> I ran into another issue:
>
> How can I define a multi-value string with No or just ONE entry?
>
> When I try:
>
> - set test to “one”, // It is a String[] multi-value but with two
> values where the 2nd is empty
> - set test to , // The parsing fails
>
> In addition using a keyword like ‘end’ fails to parse:
>
> - set end to “TEST” // Fails to parse
> - set end{String} to “TEST” // Fails to parse
> - set ‘end’ to “TEST” // Fails to parse
> - set “end” to “TEST” // Fails to parse
>
> Cheers - Andy
>
>> On Feb 1, 2021, at 1:58 PM, Andreas Schaefer <[email protected]>
>> wrote:
>>
>> I got around this issue by extracting the setting of the properties into a
>> reference file (repoinit.txt) and there is works as there the quotes can be
>> escaped with a \.
>>
>> - Andy
>>
>>> On Feb 1, 2021, at 12:52 PM, Andreas Schaefer <[email protected]>
>>> wrote:
>>>
>>> Hi
>>>
>>> As it turns out the problem is NOT the curly brackets but rather the
>>> internal double quotes.
>>>
>>> - Andy
>>>
>>>> On Feb 1, 2021, at 12:05 PM, Andreas Schaefer <[email protected]>
>>>> wrote:
>>>>
>>>> Hi
>>>>
>>>> If I try to create a property with a curly brackets in it then the parsing
>>>> fails:
>>>>
>>>> set properties on /var/dxml/folderprofiles
>>>> set globalDefaultConfigs{String} to \"{\"type\":\"one\"}\"
>>>> end
>>>>
>>>> I tried to escape the curly brackets with \{ and \} but to no avail.
>>>>
>>>> Is there a way to use unicode or ascii codes or any other way to fix it?
>>>>
>>>> Should this be considered a bug as curly brackets in a string properly is
>>>> a valid value? If so I will create a ticket for it.
>>>>
>>>> - Andy
>>>
>>
>
