TreeView of Json data

[stanl]

https://jsonviewer.software.informer.com/1.2/


just doesn't seem to be there ::)

[ChuckC]

As long as you have some kind of treeview control that you can populate with arbitrary data in WinBatch, there's no reason why you couldn't populate it with data from a JSON source.

It seems to me that the biggest issue with WinBatch & JSON is that there simply isn't a basic straight forward way to go between JSON notation and either a basic WIL "map" or a series of nested maps.

In the .NET world, the NewtonSoft JSON NuGet package is my go-to tool of choice, and it could certainly be utilized in WinBatch.  Alternatively, Microsoft implemented higher performing albeit less flexible JSON support natively in .NET 5 under the System.Text.Json name space.  I don't recall if WIL can make use of .NET 5 [Core] or if it is limited to .NET Framework, so YMMV with the built-in JSON support.  NewtonSoft works in both .NET Framework and .NET 5 [Core].

I don't know if it warrants an entire extender or just a library of well-designed UDFs.

[stanl]

I don't know if it warrants an entire extender or just a library of well-designed UDFs.

Chuck;


Would expect you would join in on threads about Json and Jim's extender. Your knowledge and opinions are necessary as this board moves into a WB implementation. If you get a chance and can look at the last script I uploaded to obtain weather alert data for a state - the Json involves

   
• polygon type [individual lat/long points]
• https hyperlinks
• parseable???  date formats
• regular element=>data pairs... 

Since we get weather alerts on our phones, the url only serves the purpose of how complicated Json can be. :o

[stanl]

[PS: EDIT]


forgot to mention... I tried WB and Newtonsoft 2 years ago. Could not even get it to instantiate. It seems if you were to build it into WB there would have to be a distribution for other users, or am I wrong? I have even tried Newstonsoft C# in PS and that fails. I presently work with a SAP db and although they have a Json API, most is still done in XML.

[td]

Newtonsof.Json seems to instantiate just fine assuming this is what you mean by instantiate:

Code (winbatch) Select Expand

ObjectClrOption('Appbase', 'C:\Temp\Json120r3\Bin\net45')
ObjectClrOption('use', 'Newtonsoft.Json')
objJsConv = ObjectClrNew('Newtonsoft.Json.JsonConvert')


Haven't tried to use it for anything so don't know how much you can do with it.

Also, dotNet core assemblies cannot be used with WinBatch CLR hosting most likely because MSFT has blocked access to them via the low-level native APIs used by WIL CLR hosting.

[td]

In the interest of checking WIL CLR hosting's compatibility with non-MSFT assemblies and not intending to suggest this example or the assembly in general has any practical use in WinBatch scripts but the example does show that methods from the Newtonsoft.Json assembly can be accessed:

Code (winbatch) Select Expand

ObjectClrOption('Appbase', 'C:\Temp\Json120r3\Bin\net45')
ObjectClrOption('use', 'Newtonsoft.Json')
objJsParser = ObjectClrNew('Newtonsoft.Json.Linq.JToken')
strJs = $" {"id":: 1,
    "name":: "Leanne Graham",
    "username":: "Bret",
    "email":: "Sincere@april.biz",
    "address":: {
      "street":: "Kulas Light",
      "suite":: "Apt. 556",
      "city":: "Gwenborough",
      "zipcode":: "92998-3874",
      "geo":: {
        "lat":: "-37.3159",
        "lng":: "81.1496"
      }
    }
  }$"
objJs = objJsParser.Parse(strJs)
objItem = objJs.First
strJsPath = objItem.Path
Pause("First Item's Path", strJsPath)
exit

[stanl]

Like I said... 2 years ago.

[ChuckC]

I've been too short of bandwidth to contribute on the subject in the way that I would prefer, though I have been trying to keep up with reading current discussions.  What I was suggesting with NewtonSoft JSON was a way to bridge the gap between the text form of JSON and something native to WIL, like "maps", with as little coding as possible to make it happen.

There's also a C++ JSON library that I've worked with before that is trivially simple to make use of and which consists of nothing more than a single C++ header [.hpp] file.

https://github.com/nlohmann/json

It's what I was using in my C++ projects back 3 or 4 years ago before I switched over to pure c#/.NET projects.  With a bit of work, it would be fairly straight forward for a WIL extender to be written using it and would bypass all concerns about having to get the NewtonSoft JSON NuGet package and utilizing .NET from WinBatch, as that in and of itself complicates or even precludes using an extender for JSON support.

[JTaylor]

That is what my Extenders does to some degree.   I can't return maps yet but I return the data in a Map compatible format so one can wrap the response in a MapCreate() function.

Jim

[stanl]

In the interest of checking WIL CLR hosting's compatibility

I grabbed the latest Newtonsoft and CLR has no issues. I looked and had scripts from 2013 where I was trying to use the serializer and gave up finding I could get what I needed then with jScript.