Option to export LabVIEW Maps as JSON Map Objects {}

[ck]

Hi,

would it be possible to (optionally) export LabVIEW maps with string keys as JSON map {} objects?

As the official JSON documentation states (emphasis mine):

The models of object systems can be wildly divergent and are continuing to evolve. JSON instead provides a simple notation for expressing collections of name/value pairs. Most programming languages will have some feature for representing such collections, which can go by names like record, struct, dict, map, hash, or object.

Therefore, I think that LabView maps that have string keys are better represented as JSON objects {}, instead of 2-element key-value arrays []. I do realize that this would be inconsistent to the exported form of other map objects, therefore I suggest this to be implemented as an (default off) option, similar to the Labview extensions switch.

The reason I think this option should exist is that many other JSON implementations will store key-value entries as JSON objects {}. Having to handle this case externally to interact with these implementations requires quite some effort, which I think should better be a part of JSON text itself. It would also produce more semantically correct JSON in this case.

Preferably the option should only be required for exporting, while the import would accept both notations (but probably not mixed within one file / section) as import source for a LabVIEW map with string keys.

‌

Thanks for considering this idea and many thanks for this great JSON library.

Kind regards.

[James Powell]

This looks quite doable and worthwhile. Would extend the <JOBJ> tag (currently used to convert JSON Objects to Array ofCluster) so it works on Maps with string keys.

[James Powell]

I have attached a new beta version to try to the original post. Should accept a JSON Object and convert to a Map. Will alos go teh other way, if the Map is in a Cluster, and its name has the <JOBJ> tag at front.

[ck]

jsonText1.6.11.117_bug.vi

[ck]

jsonText1.6.11.117_bug.vi, new version

[James Powell]

I think this is just Issue #39, the fact that one can’t go from JSON to a Vairiant (as the JSON doesn’t have a specific type). Why are you using Variants, rather than strict-typed data or subJSON?

[ck]

Sorry for the late reply, I didn’t receive a notification email.

I tested your preview version. I can use the <JOBJ> tag to enable {} object export. However, on json import, this fails for my (admittedly rather complex) data structure. This problem is also in the released 1.6.10.113, so its not a regression.

Error is:

Error 74
Flattened String To Variant in JSONtext.lvlib:SetMap.lvlib:JSON to Map.vi:1080001->JSONtext.lvlib:JSON text to Variant.vi:4410002->JSONtext.lvlib:JSON to Cluster.vi:3430002->JSONtext.lvlib:JSON text to Variant.vi:4410006->jsonText1.6.11.117_bug.vi

The JSON I try to import is

{"MessageGUID":"448D652F-B46F-4859-8369-20FAD3AECEAB","From_Designator":"","From_GUID":"","To_DesignatorOrPath":"","To_GUID":"","MessageCommand":"RMA_Ping","MessageCommandArgument":"","MessagePayloadSerialized":"null","PayloadEncoding":"JSON","SendRouteReturnPath":".","MessageIsReply":false,"ReplyType":"NO_REPLY","InReplyToMessageGUID":"","CommandExecutionErrorResult":{"status":false,"code":0,"source":""},"VisitedNodeDesignators":[],"VisitedNodeGUIDs":[],"MessagePriority":"Normal","AttributesRetainedInReply":{"tst2":[{"str1":"teststring1","num1":10},"Variant"],"tst3":[{"str1":"teststring3","num1":-3},"Variant"]},"AttributesNotRetainedInReply":{"tst1":[{"str1":"teststring1","num1":10},"Variant"]}}

I have attached a VI to reproduce the error (I hope I removed all the typedefs now). Sorry for the complex test case :-/ I hope this is not an intended limitation that I missed somewhere. It's not critical for me, since I already have a VI that manually breaks this cluster down so JSONtext can export/import it as {} json maps, but I think one of the nice strong points of JSONtext is that it can handle almost every frequently used LV datatype (besides complex that is), so this error might be of interest.

Thanks for your good work creating and maintaining this library.

attachement: jsonText1.6.11.117_bug.vi, now hopefully without typedefs

[ck]

After switching to a JSON encoded value in the cluster within the map, the <JOBJ> tag works as expected.

I now remember that I had this same issue with variants in my outer message datastructure as well, which is why I serialized the variant separately. This is what I currently do for the maps as well, and while I process the variants I also create the json {} maps manually.

I was hoping that I could remove that code for better maintainability (and perhaps better speed), but now I think the variants prevent this anyway. This was the first use case that came to my mind, but I have other cases where I have maps without any variants that will benefit from the new <JOBJ> behavior, so thanks a lot for the new feature.

‌

As a sidenote, the reason I use variants in the first place is that the attribute data in there is not always this cluster. It's basically my internal message structure, and I use a variant for cases where start- and endpoint of a message are in Labview (so performance is better). The payload data then does not need to be json encoded at all. JSON is used for data exchange via zmq to python, which unfortunately cannot handle LV variants :-).

[ck]

Updated VI without variants, now working as expected

[James Powell]

One thing to consider here is improving that error message, to something like “Variants to supported”