Feature request: support deserialization/deserialization of variant attributes
Closed this issue · 1 comments
Variant attributes are the de facto O(1) key-value store for LabView. They map well to JSON data. I've been working on a fork of this project that supports serialization/deserialization of variant attributes to/from JSON. This code is available in:
https://github.com/robertbcalhoun/JKI-JSON-Serialization/tree/feature/variant-attributes-1.1.2
I wrote this because I needed to generate to submit run-time defined, well-formatted JSON to an Amazon AWS service. However it is also useful for parsing inbound JSON data. I request that this code it be merged at some point (after appropriate JKI code review etc) because I'm finding it very challenging to keep up with the changes to the JKISoftware master.
The main changes are:
-
On serialization, detect incoming data of type "void" (which otherwise throws an error) and treat it as a a run-time defined object with data stored as variant attributes. This work out nicely; the default void variant has zero attributes, representing the empty JSON object "{}". This is done via adding a case for "void" in "Flatten to String".
-
On deserialization, detect when a void variant is passed as "Type and Defaults" and deserialize as a variant attribute. This is handled with a version of the unflatten function, "Unflatten From String to Variant Attributes" that re-uses the most of the same function in the library.
I've left unresolved a discrepancy with the handling of "null" vs "{}". I can fix it in my library, but only by breaking a test case of Tomi's, which maps "{}" to "null". I've left that unfixed for now.
I have also not resolved the fact that Tomi and I both created a VI holding the null data type (with same definition, fortunately.) Not really a bug, just duplicate code.
Below are some examples. Note you can handle some legal JSON string that are otherwise impossible to handle in LabView.
Rob Calhoun
Whoops, I see you already responded to this in #8 . Understood.