[CR] JSONtext

[Aristos Queue]

@ShaunR "Didn't that do JSON?"
Yes. Initially I rolled my own JSON parser, but it was rewritten to call JSONText as subVIs. The Character Lineator is a better framework (my opinion) for importing and exporting objects into/out of JSON than trying to hook the serializer directly. Raw JSON doesn't provide any schema version management nor any data massaging capacities. It's just fields without context. The JSONText library is important for the raw string handling. You need more infrastructure sitting above it to actually use JSON. CL is one possible choice for that infrastructure. The serializer hook that was added to JSONText in its last revision allows users to roll their own infrastructure.

[drjdpowell]

Alternative (6): all attributes are returned as JSON values.  Rather than get the attribute as the actual type, the User would get the attribute as a string, then use From JSON to convert to type. 

One could make VIMs that combine these two steps, and these VIMs might possibly be made to work with non-JSON attributes as well.

[ShaunR]

18 hours ago, Aristos Queue said:

it was rewritten to call JSONText as subVIs.

A paean to the utility of JSONText.

Edited Thursday at 02:34 PM by ShaunR

[Aristos Queue]

9 hours ago, ShaunR said:

A paean to the utility of JSONText.

Kind of. The JSONText VIs are more efficient overall than my originals that I slapped together in a weekend. But the current JSONText VIs do have some inefficiencies that my originals didn’t have (most notably, see the earlier post about accessing all fields of an object) that crop up when translating schemas. And the single  serializer hook is insufficient to do some operations — support for sets/maps or custom translations of complex data structures, for example. These are things that the CL architecture accounts for that I wish JSONText was refactored to support. Having said that, I’m happy enough for my own projects with the existing toolkit and unwilling to donate the refactoring time. 
 

It is definitely a good toolkit. But it still has a long way to go in my opinion. 

[drjdpowell]

10 hours ago, Aristos Queue said:

support for sets/maps

There is support for Sets and Maps in the latest version; I wouldn't want such things require any kind of "hook".

[drjdpowell]

10 hours ago, Aristos Queue said:

or custom translations of complex data structures

I hope Users can do whatever they want using the lower-level functions plus subJSON with the <JSON> tag.

 

[drjdpowell]

10 hours ago, Aristos Queue said:

But the current JSONText VIs do have some inefficiencies that my originals didn’t have (most notably, see the earlier post about accessing all fields of an object)

The Object thing is not where I would spend limited effort in performance improvements, as I would expect the User to actually use the item Values and thus require a copy at some point.   I would rather improve the JSONpath search algorithm.

[ShaunR]

3 minutes ago, drjdpowell said:

I hope Users can do whatever they want using the lower-level functions plus subJSON with the <JSON> tag.

Indeed. I don't know what AQ is referring to with CL (Command Line? Common Lisp?) but I have a feeling he has an eye on the library supporting JSON Schema-another IETF brain-fart which made HTML a nightmare until they ditched it and brought us XML. They have a habit of taking nice simple solutions and "formalising" them them into bloated, complicated solutions that nobody uses.

10 hours ago, Aristos Queue said:

But it still has a long way to go in my opinion.

I think the library is pretty much feature complete at this point-maybe some data types missing but can't think of any off the top of my head - so this sounds peculiar...unless JSON schema is your target.

Remember. Many of us only use toolkits like these because NI refused to make the native JSON primitives' fit-for-purpose.

[Francois Normandin]

38 minutes ago, ShaunR said:

Indeed. I don't know what AQ is referring to with CL

AQ's Character Lineator

 

[Aristos Queue]

12 hours ago, ShaunR said:

Remember. Many of us only use toolkits like these because NI refused to make the native JSON primitives' fit-for-purpose.

Dont misunderstand me: I think it’s a great toolkit, and I think it should be a G toolkit not a language primitive. I’m just finding it’s edge cases. 🙂

[ShaunR]

9 hours ago, Aristos Queue said:

I think it’s a great toolkit, and I think it should be a G toolkit not a language primitive.

Possibly in this case as it has searching. But we wouldn't have to write parsers if the current primitives were useful 

I don't know what the current status of the G toolkit is, since the last person that took over maintenance and release is no longer active on this forum.

9 hours ago, Aristos Queue said:

 I’m just finding it’s edge cases. 🙂

That's fair enough and I'm sure appreciated. However JSON Schema - if that's your target - isn't an edge case. Your Lineator would be the place to implement that, so I'm confused by the comment "long way to go" for a library that I think is pretty much feature complete.