JSON oh my life

General
1

Never written code to parse JSON before. Been tackling it in Xojo all weekend.

Good God, who could have imagined such an easily human readable format would be such a damn nightmare to traverse in code!? Hahaha, I mean, I get it. I understand why the JSONItem is structured the way that it is, and now that I’m starting to wrap my mind around it it, it’s quite an elegant mechanism, all things considered.

But oh lord, this has been a journey. 2/10, don’t recommend. LOL

2 Likes
2

Hi Emma, i agree and think Xojo should include more and better code examples in the documentation and example projects.

1 Like
3

I much prefer XML, although many years ago I decried it on the basis that it was a hugely wasteful file format.
Eventually I realised it has a lot of advantages over a binary storage - human almost-readable and editable, plus any app that reads such a file can decide what parts it wants to use.
You can stick new bits in without breaking existing apps.

But apparently that’s old hat, and JSON is where it’s at these days.
Yet to see something to change my mind, but it may happen. :slight_smile:

4

Yeah I remember the XML days. Its robustness is also its weakness. It takes far more code to deal with XML than JSON, both reading and writing. You can’t just turn a dictionary into XML. But JSON’s popularity has a lot to do with JavaScript, since every damn thing is coded with JavaScript these days. Being able to transfer/store objects with a single command is wonderful. So it makes a lot of sense to use for APIs. Other languages have to come along for the ride.

Even then, I’m not sure I’d really like to return to the XML days. I wrote the XML-RPC client classes for REALbasic/Xojo and boy am I glad that isn’t necessary these days. The fact of the matter is XML is a total chore to work with compared to JSON. I’d rather give up some features than deal with the endless boilerplate required to handle XML.

3 Likes
5

i write my xojo kanban board data to JSON and read it back. a time-consuming development and not intuitive.
Xojo still have a lack of object serialization included.
in C# you just have to inherit a class and you can save the object to XML and create the object from XML.
i serialized a entire invoice with many objects and list of objects without great effort.
same for web services or web api controller.

2 Likes
6

Interesting.
JSON always looks like a real nightmare to me.
I suppose ‘once you get used to it’ :slight_smile:
I quite like XQL

7

Plan you data structure, then just read/write as you’ve planned. Usually this is very simple.
If you are making something not very simple, not obvious, document it.

Then traversing it is piece of cake.

8

Apart from the human readable bit (albeit a little bit of practice and a hex editor), you can construct binary formats in an extensible way so that new data can be added or injected without breaking existing apps. IFF was created EONs ago with that capability. AIFF, TIFF etc etc… Interchange File Format - Wikipedia

What I love the most about binary formats is speed…

When I set about creating my own help viewer for App Wrapper (and it is in Sleep Aid) because Apple broke Apple help for third party apps (Monterey I think), I wanted to use a database, but because Xojo refuses to support read-only databases, I had to build my own. I don’t want to load up the entire index to be able to find a page (as I would with XML or JSON), so I researched hash tables. When a customer searches for something it uses the hash table to narrow down the results, then loads those into memory, before narrowing down even further. It’s quick enough that you’d never know it’s loading on demand, nor do you have to wait when you open the help viewer for the data to be loaded, or copied someone else on the disk to work around something that Xojo simply don’t want to improve.

1 Like
9

Yup. IFF. And If I recall properly the OLEDocument that Office used…

1 Like
10

One thing I do in my project that uses JSONItem is to make a couple classes that represent the various “objects” in the JSON and then I implement Operator_Convert methods for them that allow me to seamlessly go back and forth:

sub Operator_Convert(json as JSONItem)
    self.GivenName = json.Value("given_name")
    self.Surname = json.Lookup("surname", "")
end

function Operator_Convert() as JSONItem
    var json as new JSONItem

    json.Value("given_name") = self.GivenName
    json.Value("surname") = self.Surname

    return json
end

This is nice because they build on each other. For example:

sub Operator_Convert(json as JSONItem)
    self.Mom = json.Child("mom")
    self.Dad = json.Child("dad")
end

function Operator_Convert() as JSONItem
    var json as new JSONItem

    json.Child("mom") = self.Mom
    json.Child("dad") = self.Dad

    return json
end

And arrays are easier:

var people() as Person

for i as integer = 0 to json.LastRowIndex
    people.Add json.ChildAt(i)
next

Anyway, I hope this helps a little bit. It’s made my life a whole lot easier, if it is a lot of boilerplate that I wish Xojo would do for us. :wink:

2 Likes
11

I have been using these two Einhugur libs to handle XML and JSON for some time now and I find they make life much easier.

https://www.einhugur.com/Html/JSONIIISerializationFramework/index.html

https://www.einhugur.com/Html/XmlSerializationFramework/index.html

1 Like
12

I feel your pain. Parsing the first time usually gets me spectacular crashes. Variants and Dictionaries, Oh My! Using the debugger to see each step and what the data expects next was my savior.

13

Are a problem with the Dictionary method of parsing JSON. I constantly recommend that you do not use that method. The JSONItem class makes parsing JSON much more straightforward, and the code is self documenting.

4 Likes
14

Oh, I forgot to mention that on the Mac, Apple provides a way to serialize dictionaries into XML files or binary files.

It is a lot of work to make it work with Xojo, but something that I’ve probably added a feature request for somewhere.

1 Like