I am writing a parser for a remote API to fetch metadata about a product.
I have a class named Product that stores different properties about the product.
In this class I created a property called metadata. First it was of type Dictionary but as the parsing will be difficult due to nested dictionaries and specific conditions, I wanted to create a specific class ProductMetadata that will be in charge of retrieving all the data that I want to display inside a Listbox.
So my goal is to organize methods and constants in a different class and I thought about creating a Class with as Super the Dictionary class.
But when I try to assign the Dictionary generated from ParseJSON to the class ProductMetadata (with super Dictionary). I got an illegalCastException (normal there) but I would like to not store the dictionary in a property of ProductMetadata.
I thought about creating a module too but I do not know what is the best way to make it work. What is the best solution to achieve that?
Have you seen how ActiveRecord / an ORM works? I use a similar design with remote APIs and build classes that represent the data structures I need. The way I build the class I’m abstracted from the specifics of the API when building app functionality.
That’s the route I’d recommend.
I’d also recommend dumping ParseJSON / Dictionary as that’s a significantly more difficult way to work with JSON than using the JSONItem class.
I will try to test JSONItem, I just thought that Dictionary was the way to work with JSON and also had some issues in old versions of Xojo using JSON but maybe it was a bad use of me.
It does not solves the initial question on how to structure the code to parse all that in a different class/module but helps me a lot, thank you
They had made an attempt to do this, but it failed miserably because who in their right mind wants to delve into introspection just to parse some JSON. The approach was over-engineered and is more difficult to use than the long-time JSONItem class. Xojo has updated JSONItem under the hood to use system provided APIs, so the class is fast and usable now.
I was really suggesting an ActiveRecord-like structure. The class would have a function like Save and that would handle the API request. You then interact with the class instead of the API when building app functionality.
I’m doing a terrible job describing this, but I’m trying to be sincere about what I’m suggesting.
For your sample link, I’d maybe have a Record class that holds properties like RecordType and RecordNumber, as well as a Reference class, which the Record would hold an array of.
Update:
Here is a sample structure I built very quickly from this example JSON. It’s not fully complete, and the methods don’t include code, but this is a rough idea of how I would structure a system for this. For what it’s worth, integrating with remote APIs is one of my specialties if you need any professional assistance.
I disagree with Tim and like ParseJSON/GenerateJSON over JSONItem, so use whichever you’re more comfortable with. JSONItem uses the same engine as the functions anyway.
@Tim_Parnell thank you for being so thorough in your answer regarding Xojo JSON usage. I have been wanting to ask about the specifics on the different JSON implementations in Xojo, and how they may have changed in the last couple of years - and you have brought the topic up.
I had bookmarked a thread where @Kem_Tekinay had shown benchmarks and had discussed his JSONItem_MTC replacement. In it he had recommended using ParseJSON and GenerateJSON because they were newer and faster. The thread was this one:
Fortunately, @Kem_Tekinay has also arrived on this thread, again suggesting the use of ParseJSON and GenerateJSON. I was planning on using ParseJSON and GenerateJSON going forward due solely for performance reasons.
So, if I understand this right, everything I learned about JSON performance in Xojo in 2020 (I actually bookmarked that thread for future reference), can now be thrown out the window? JSONItem, ParseJSON and GenerateJSON can be used interchangeably and there will be no difference in speed?
Again, I really thank you guys for bringing this up, because I would have been operating under false assumptions based on facts from a couple of years ago. If I could use any of these, without having to worry about performance, that is great to know.
