[CR] JSONtext

[drjdpowell]

Issue 92: https://bitbucket.org/drjdpowell/jsontext/issues/92/all-integer-types-needed-for-set-map

[drjdpowell]

Please try this fix:

jdp_science_jsontext-1.6.6.106.vip

[Niatross]

5 hours ago, drjdpowell said:

Please try this fix:

jdp_science_jsontext-1.6.6.106.vip 2.9 MB · 2 downloads

That was a quick turn around. I was going to have a look into it myself but I hadn't even had chance.

Thanks for sorting it!!

[QueueYueue]

 

On 8/5/2021 at 10:29 AM, drjdpowell said:

Consider just not including those parameters.  Rather than {"A":123,"B":null,"C":789} just have {"A":123,"C":789}; then "B" will be default.

Alternately you could put named-Variant values inside your variants (which teh Variant-to-Data node will pass through:

Variants are quite tricky, as they can serve both as a temporary container for a value, and a value itself.

This is opposite of what I would expect to see. Fundamentally if I give you a cluster with named items (who cares about the data type), I expect the JSON output to an object with fields matching the names of the clusters. All of this "variants have names" discussion is optimizing of weird LabVIEW shenanigans instead of a primary use case.

 

On 8/5/2021 at 10:19 AM, Aristos Queue said:

Allow me to rephrase then.

Recording an array when passed a NAMED cluster is definitely a bug, regardless of the behavior of the variants.

+1

[QueueYueue]

The following VIs aren't reentrant but should be:

- JSONtext.lvlib:Format JSON Array Text.vi
- JSONtext.lvlib:Parsing Error.vi
- JSONtext.lvlib:Format JSON Object.vi
- JSONtext.lvlib:Get all Object Items.vi
- JSONtext.lvlib:Get Array Elements.vi
- JSONtext.lvlib:Parsing Error in converting to LabVIEW type.vi

[drjdpowell]

Does anyone actually use Variants in clusters in this way?  To me, this is not even a tertiary use case of JSONtext, so it would be helpful to hear from people with real-world uses.  I am tempted to suggest throwing a "Variants not supported" error, but even that would add overhead which I am loath to do.

[Tim_S]

20 minutes ago, drjdpowell said:

Does anyone actually use Variants in clusters in this way?  To me, this is not even a tertiary use case of JSONtext, so it would be helpful to hear from people with real-world uses.  I am tempted to suggest throwing a "Variants not supported" error, but even that would add overhead which I am loath to do.

I've used them in that way pre-maps leveraging variant attributes. Don't expect JSONtext to handle that use case, though.

[Aristos Queue]

4 hours ago, drjdpowell said:

Does anyone actually use Variants in clusters in this way? 

Yes. My current customer does. It is a primary use case that we are currently working around the obvious (and trivial to fix) bug in the toolkit. 

[Michael Aivaliotis]

is it possible to improve the error handling for empty strings? Perhaps have a special error code I can filter on if an empty string is detected?

 

[drjdpowell]

15 hours ago, Michael Aivaliotis said:

is it possible to improve the error handling for empty strings? Perhaps have a special error code I can filter on if an empty string is detected?

 

Use case?   Why do you need different custom error than the 402841: "Invalid JSON formatting" that you have now?

[JKSH]

On 10/11/2021 at 1:34 AM, Michael Aivaliotis said:

is it possible to improve the error handling for empty strings? Perhaps have a special error code I can filter on if an empty string is detected?

How about wiring the string into a case structure selector?

• Case "": Do your special output
• Case Default: Wire the string into the JSON VIM

[Michael Aivaliotis]

Yes, empty string is invalid JSON, but so could be malformed text, which is more serious than an empty string which could imply reading a non-existent JSON item.

How should I handle reading JSON files where data elements are missing? I like having the default data input so if an item is missing, it returns the default, of course. But now I have to write special code for every node. What is the best practice when using this toolkit for this use-case?

I guess I could create custom wrappers. But I wanted to avoid the extra work for something that's common.

Am I using it wrong?

[JKSH]

5 hours ago, Michael Aivaliotis said:

How should I handle reading JSON files where data elements are missing?

Missing as in "field does not exist in the object", or missing as in "field exists but the value is an empty string"?

• The latter is not truly missing. It exists, and its value is an empty string.
• The former can be handled using the "Data Type and Default Value" inputs

 

5 hours ago, Michael Aivaliotis said:

an empty string which could imply reading a non-existent JSON item.

Sounds like you're using "Find Item.vim"? Make use of the "Found" output, OR switch to "Find Item (as LVtype).vim" to specify the default value.

 

6 hours ago, Michael Aivaliotis said:

I guess I could create custom wrappers. But I wanted to avoid the extra work for something that's common.

How do you envision providing the default value if you are able to filter out the proposed "Empty String" error?

[drjdpowell]

JKSH has explained as well as I could the expected use.  "Missing from Object" is determined when operating on the Object.  

I had a look, and it should be reasonably easy to give a different error for a string with only whitespace, but I'll need to understand use case for it better.  I, personally, never find the need to write custom error-handling code.

By the way, if one's use case is "set from this JSON as much as possible, or use supplied default for items where this is not possible", then one can just not use the error wires at all.

Edited Friday at 08:05 AM by drjdpowell