I have a json like:
bodyJson = {
“userUUID” : mUserUUID,
}
str = FormatJson(bodyJson, 1)
This str is sent as the string on AsyncPostFromString, with the following headers :
mRequest.AddHeader(“Content-Type”, “application/json”)
mRequest.AddHeader(“Accept”, “application/json”)
mRequest.AsyncPostFromString(str)
mRequest.EnableEncodings(true)
For some reason, the string str is all in lowercase (“userUUID” becomes “useruuid”)
Any idea?
“dan_shneider” wrote:
I have a json like:
bodyJson = {
“userUUID” : mUserUUID,
}
…For some reason, the string str is all in lowercase (“userUUID” becomes “useruuid”)
Associative array keys are case-insensitive by default, and in the case of associative array literal values and dot operator assignments are not case-preserving.
Thus, if you do “print bodyJson” you will see that the assigned key name is “useruuid”.
Depending on your requirements, you could alternatively do:
bodyJson = {}
bodyJson["userUUID"] = mUserUUID
and then the FormatJSON result would be what you expect, as the assignment using the literal is case-preserving on the key.
“RokuKC” wrote:
Associative array keys are case-insensitive by default, and in the case of associative array literal values and dot operator assignments are not case-preserving.
It would be better (better design) if string-literals as keys in AA literals are case-preserving, unlike the var-name keys. I.e.
Brightscript Debugger> ? {"A": "A", B: "B"}
<Component: roAssociativeArray> =
{
A: "A" 'wishful thinking'
b: "B"
}
It will both bring it in line with [“A”] behavior and also cater to developer’s intuition of “no, i want it exactly as i wrote it - see, quoted verbatim! - no improvisations”
Thanks a lot for the help. will try that out.
bodyJson = {}
bodyJson["userUUID"] = mUserUUID
This is working. thanks a lot.
Got bit by the same issue and took a while debugging it since server kept of rejecting the json request as FormatJson() gave a json with keys converted to all lower-case. Any future plans of making the keys case-sensitive for the roassociativeArray?
Doubt it, the whole language is case insensitive, except when it’s not. 
Personally I try to keep everything in my code lowercase_with_underscores instead of camelCase, just to enforce some consistency. The official Roku examples are all over the map in terms of camelCase, I was really confused at first until I found a mention in the docs that BS is case insensitive.
I would as well, but the server folks are inconsistency using camel case in some places, all lower case in others and separated by _ in still others. I don’t have control and the api’s are already complete and being used. Changes now would wreck havoc in a bunch of other places.
Ok, so have a close, attentive look to this example:
Brightscript Debugger> check = function(d): d.a = "a": d.A = "A": d["b"] = "b": d["B"] = "B": ? d: end function
Brightscript Debugger> d = {}: check(d)
<Component: roAssociativeArray> =
{
a: "A"
B: "B"
}
Brightscript Debugger> d.SetModeCaseSensitive(): check(d)
<Component: roAssociativeArray> =
{
B: "B"
a: "A"
b: "b"
}
The dot-notation is a case-lowering option.
The indexing is case-preserving BUT case-insensitive at the same time - so use that if you are sure there will be no keys that differ only in upper/lower casing. And if you set SetModeCaseSensitive(), then the indexing operator turns into both case-preserving AND case-sensitive.
That does not apply to the dictionary literals (i.e. {a: 1, A: 2}) though - they are allways case-clobbering (for now?)
Thank you for the clear explanation. It is good to know that there is a solution for same keys with different case if it ever comes up.
