Support JSON to Variant when no datatype provided

[Francois Normandin]

For some applications, I sometimes do not have a strictly-typed datatype to provide as an input for parsing the JSON string. It would be useful to support “JSON to Variant” when no input datatype (Void) is provided. The result would return a scalar, cluster or array based on the JSON string. This deserialization is obviously slower than by providing a datatype, but would complete the set of base functionality to make a roundtrip in any direction.

‌

[James Powell]

Hi Francois,

The principle I’m following is to use JSON (and “subJSON” including LabVIEW strings with a “<JSON> tag) in place of any Variants. So, for example, an application config JSON might contain a config of a submodule. I get that submodule config as a JSON string and pass it into the submodule. That submodule might extract subJSON text and pass it into its own sub-components. I don’t use Variants at any step except the final one where I have the actual LabVIEW type (where the Variant is used internal to the JSONtext VIM functions). Thus I have never developed the function you are asking for (but have developed the <JSON> tag on LabVIEW strings to extract subJSON).

Can you give some examples of the use cases you which to support with this “JSON to Variant” function? If there are cases that Variants provide capability that subJSON does not then I am interested. I imagine there might be some existing Variant-based libraries that you might want to interface to?

‌

[James Powell]

but would complete the set of base functionality to make a roundtrip in any direction

There is already complete functionality for such round trips. This suggests my documentation in JSONtext is poor. I will look into improving it.

[Francois Normandin]

Hi James,

the application is to use it as part of a serializer-deserializer embedded in a configuration manager that breaks down components in key-value pairs, making it extensible to any type of storage (file, database, cached map, etc.).

It’s actually part of an extension to my CfgManager project which allows the user to plugin their own serializer and config manager. The configuration manager stores key-value pairs from any data source (variant or not) and uses a serializer to marshall/unmarshall to/from the user’s preferred format.

I’m looking for a single library that can do A to B, B to C, C to B and B to A.
JSONtext does the three first steps, but only partially covers the last one.

In the first step, I use JSONtext library to format incoming data into a JSON string:

The second part is to extract the key-value pairs from the serialized JSON string. For this application, it breaks it down into a Section and key-value pairs. Below is the API I need to conform to for any extension of the CfgManager base class.

That’s it for the Variant to Section/Key-Value pairing. Simple and straightforward.

The roundtrip starts with recreating a JSON string from the persistent values. Kudos for the “Unflatten JSON Path to Object” method, it is truly amazing.

The last part is where I haven’t found a full equivalent in JSONtext, so I use JKI-JSON also. But I’d rather use a single library as a dependency. (JKI-JSON does not implement the second and third steps to decompose into key-value pairs, so I can’t use JKI-JSON for the whole process either)

So my workaround, for now, is this:

If the datatype is provided, I use JSONtext, otherwise I use JKI-JSON to rebuild a compatible variant from the JSON string provided. The case where type is “Void” is really the only one missing from your library, IMO. Perhaps there is an alternative way that I haven’t found?

cheers,
François

‌

‌

[Francois Normandin]

I’ll clean the code a bit, but I think I’ll have a solution to contribute…
(I’m travelling, so not sure when I’ll make the pull request)

‌

[James Powell]

I have to think about this a bit. There is a current feature that maps Variant Attributes to a JSON Object that may conflict with this (though I don’t personally use Variant Attributes either). Can you make a standalone VI that converts a JSON Object to a Variant cluster without knowing the type? That would solve your problem and I can always add that specialist function to the “Advanced” palette. I’m not committing to making changes to the standard JSONtext VIs (yet).

‌

[Francois Normandin]

I see what you mean, but I don’t think Variant Attributes are supported in the VI that would be affected. This frame (and the others) don’t support it:

‌

But in doubt, I understand you are keen not to change the current known behaviour which is to throw an error.

The “Scalar JSON text to Variant.vi” could be left unchanged and, as you suggest, a new methods could be added “JSON text to Variant (Void).vi” in the advanced palette. That would definitely suit my needs. Apart from the error 1 that is currently thrown, there is still no variant attribute support in that method, as evidenced by the comment on that block diagram (in the Void case) which states “Empty Variant #ToDo Variant Attributes?”

Actually, one change that affects the rest of the library is that to make it recursive, it cannot be inlined… So I’ll bundle this proposed change into a separate VI to make sure the “Scalar JSON text to Variant.vi” can stay inlined for speedier long array/cluster deserialization.

Anyhow, I will make a pull request which you can examine at your leisure and see if you want those changes or not.

[James Powell]

Dont rush, I'm on holiday the next week. Btw, variant attributes functionality was originally added to the previous library, LAVA JSON, by Ton Plomp, who used a lot of variant-attributes. I've never used them and, I guess, never finished them in JSONtext.

[Francois Normandin]

OK, I tried to create a pull request, but apparently Bitbucket (Mercurial) can only do it from the same repo. I’d need to collaborate on your repo to be able to push a branch or create a pull request. (another reason to use Git I suppose )

So… for now it can be viewed from this fork on my own repo: https://bitbucket.org/normandinf/jsontext/

(“variant-void” branch)

[Francois Normandin]

@James Powell (bumping this thread)

‌