JSON parser

[dwisti]

Here is my first attempt to produce an equal result to the original code. I should be making a few more improvements with white space and the way arrays are handled.  I few issues here before you download this VI.  First, you need to have the OpenG Labview Data Library.  If you don't have it, you can get it from VIPM.  Second, you need to have the VIs from Github.  A link to the JSON repo from Philmod is posted above.  The attached VI can then be used inside "Test cluster2json.vi" to show the same result as the control reference based solution.

[drjdpowell]

Just an idea: have you considered leveraging OpenG's "Format into String" (with default formating) instead of your innermost case structure?  It handles a large array of types, including timestamps, enums, paths, complex numbers, etc., which would be a lot of work for you to add explicitly.  

-- James

[dwisti]

Thanks James, I think that is a good idea.  My plan was to get rid of the innermost case structure all together.  I would like to see arrays handled in the same manor as other data types.  To do that, arrays would be pushed on to the stack (queue) much like nested clusters. But using the "Format into String" might work just as well.

[dwisti]

James,

You were right.  Its much nicer now.

[drjdpowell]

Good work.

One extra optional suggestion.  The OpenG tools work by flattening the variants and parsing.  Flattening can be expensive for large items.   Often when one uses several Data Tool VIs in sequence, one is actually flattening the same data more than once.  For example, you are calling both "Get Array Element TDEnum" and "Array to Array of VData" on the same thing.  Both of these call "Varient to Header Info", and so the data is flattened twice.  By looking inside those VI's at the lower-level functions, one can usually come up with code that avoids duplicated operations (and often with fewer data copies).  In other words, one can make it higher performance.  Often this isn't worth the effort, but it might well be for a messaging system like JSON depending on your application.  One can always leave this improvement till later.

-- James

[dwisti]

James,

Thanks for your advice.  Here's the latest VI.

[SteveChandler]

Hello, I wrote the original code that the github code is based on. I have no problems rewriting or modifying it. I am on my phone but will look at your solution as soon as I can.

Have you considered asking the OpenG team to distribute this? It is a perfect addition. Also I would be very impressed if you could implement the opposite and unflatten JSON to a cluster.