Jump to content

Recommended Posts

  • 2 weeks later...

 

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:

1090371450_2021-08-0517_26_42-Untitled2BlockDiagramonJSONtext.lvproj_MyComputer_.png.63907e2224240eac829f7dadb8bfa9d8.png

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

Link to comment

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

Link to comment

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.

Link to comment
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.

Link to comment
  • 1 month later...
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?

 

image.png

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

Link to comment
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
Link to comment

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?

Link to comment
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

1344596818_MissingJSON.png.6295ac54b049d6fa13467c4b182582cb.png1456594771_MissingJSONOutput.png.d52056df16414281a474f4bcf14469db.png

 

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?

Link to comment

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 by drjdpowell
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By LogMAN
      I recently stumbled upon this issue while debugging an application that didn't handle JSON payload as expected.
      As it turns out, Unflatten From JSON breaks on NUL characters, even though Flatten To JSON properly encodes them as ("\u0000").


      I have confirmed the behavior in LabVIEW 2017, 2019, and 2020 (all with latest service packs and patches), currently waiting for confirmation by NI.
      Workaround: Use JSONtext
    • By drjdpowell
      Package for working with JSON.  Uses high-speed text parsing, rather than building an intermediate representation as with prior LabVIEW JSON libraries (this is much faster).  Allows easy working with "subitems" in JSON format, or one can convert to/from LabVIEW types.  Uses the new "malleable VIs" of LabVIEW 2017 to convert to any LabVIEW type directly.
      JSON text makes use of a form a JSON Path notation, allowing easy and rapid access to the subitems of interest.
      Requires LabVIEW 2017 and install by VIPM 2017 or later.
      Original conversation about JSONtext.
      On the LabVIEW Tools Network.
      JDP Science Tools group on NI.com.
      Copyright 2017 JDP Science Limited
    • By drjdpowell
      View File JSON LabVIEW
      JSON is a data interchange format (sometimes compared to XML, but simpler). There are multiple projects to create a JSON package for LabVIEW. This is yet another one motivated by this hijacked conversation originally about a different project to convert JSON into LabVIEW Variants.

      This project uses a set of LVOOP classes to match the recursive structure of JSON, rather than variants. It allows conversation to and from JSON. All functionality is available through two polymorphic VIs: Set and Get. In addition to Get and Set VIs for common data types, one can also convert directly to or from complex clusters via variant-JSON tools.

      Copyright 2012-2016 James David Powell, Shaun Rumbell, Ton Plomp and James McNally.
      [Note: if you are using LabVIEW 2017, please also see the JSONtext library as a an alternative.]
      Submitter drjdpowell Submitted 10/04/2012 Category General LabVIEW Version  
    • By ThomasGutzler
      Hi,
      I'm receiving a JSON string from a web API, which I'm trying to convert into a cluster (of clusters) but I've run into some problems:
      1) Sometimes the order of the elements in the JSON string changes, which causes my conversion to fail.
      2) Sometimes the "object" returned via JSON is null, which causes my conversion to fail if I use clusters within clusters. It works with variants in clusters but then I need to convert the all the variants manually
      Is there any way to improve my code to fix those problems? The attached snippet is a simplified version. In my project, the first JSON string to data is done in a library. The second conversion from "result" variant to data is done in my application. This makes a direct conversion from JSON string more difficult.

    • By drjdpowell
      JSON is a data interchange format (sometimes compared to XML, but simpler). There are multiple projects to create a JSON package for LabVIEW. This is yet another one motivated by this hijacked conversation originally about a different project to convert JSON into LabVIEW Variants.

      This project uses a set of LVOOP classes to match the recursive structure of JSON, rather than variants. It allows conversation to and from JSON. All functionality is available through two polymorphic VIs: Set and Get. In addition to Get and Set VIs for common data types, one can also convert directly to or from complex clusters via variant-JSON tools.

      Copyright 2012-2016 James David Powell, Shaun Rumbell, Ton Plomp and James McNally.
      [Note: if you are using LabVIEW 2017, please also see the JSONtext library as a an alternative.]
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.