Unflatten from Partial/incomplete JSON File

[Richard_Ha]

I've been using INI files to store configuration data, but I'd like to move to JSON.

When doing a "Read Key" from an ini file, is the key doesn't exist I can specify a default value.

This doesn't seem to be the case for JSON, is there a way around it if I only want to store some elements of the cluster and any that aren't explicity declared use the default value? It looks as though I'd have to explicity declare null for any elements that I don't want to save.

[mikeporter]

The problem is that although we are using these strings to pass data, at its essence a JSON string is defining a data structure. Consequently, while the two strings might appear very similar to us, they are describing two different data structures so simply unflattening won't work. You can however parse the string yourself and by knowing the labels of the elements in the structure parse out just the values that are present.

Mike...

[drjdpowell · Accepted solution]

Try an alternate JSON implimentation, such as the one on LAVA.

[Richard_Ha]

Thanks guys. 

I think I'll just stick with ini files for now!

[mikeporter]

I hear what you are saying, but consider that paring the JSON string is really rather trivial.

For example, you know what the name of the item is, so the item in teh JSON streing will be that surrounded by double quotes, and followed by a colon.

Next, everything from there to the next comma or close curley parentheses will be the data associated with that item.

Real simple...

Mike...

[mikeporter]

For Example:

Mike...

[drjdpowell]

The OP wants to use JSON to store configuration clusters, presumably without writting a lot of custom parsing code.  Simple parsing will also be unable to handle duplicated names, such as the JSON text:

{ "Operator": { "Test 1": "Joe", "Test 2": "Mary" }, "Test 1": 1, "Test 2": 2 }

[Richard_Ha]

I've modified your example slightly to be more generic using some OpenG VIs.

It still can't deal with Array, or subclusters, or duplicated names but would probably work for my needs.

[mikeporter]

Exactly!

The idea with the example was to get you pointed in the right direction. I particularly like the adding of the logic for derive the field names from the cluster, and giving the code the ability to process data values differently based on the datatype of the value. You have learned to think ahead.

"Amateurs write programs, professionals write toolboxes"

Just remember that the cluster that you use to initialize the shift register also servers to define the default values for each field.

Mike...

[drjdpowell]

---

@Richard_Ha wrote:

I've modified your example slightly to be more generic using some OpenG VIs.

It still can't deal with Array, or subclusters, or duplicated names but would probably work for my needs.

---

Is there a reason you aren't using the JSON implimentation on LAVA?  It does basically the same thing, only it's complete, and handles arrays, subclusters, and a large number of LabVIEW datatypes.