jeffh
Consider JSON-Schema for externalizing structure and validation?
Have you considered using anything like JSON-Schema to help externalize some of the model definition and validation?
I'm a huge fan of the graceful fatal/non-fatal error handling and it seems like with the addition of an optional flag on a JSON-Schema element, you could effectively break out a lot of that stuff, and spit out a list of errors, reasons, and JSON-Path locations. We can influence the JSON data on the server, but so much of it is configurable for them at run time, long after our iOS app is in the wild.
I don't think I fully understand what you mean. Are you saying Hydrant mappers built from a JSON-schema or model generation?
That being said, I have only lightly considered how JSON-Schema would fit in. I also was considering perhaps generating mappers from an example JSON file (with some extra tagging for optional fields). It sounds interesting but I haven't explored that idea much.
A schema file would be able to describe a model and also set expectations of attribute data types (or sub-models). Then, as pieces instance data come in, a JSON-Schema validator would give a list of any errors and their exact location in the data (using JSON-Path notation.
I keep saying JSON, but it doesn't even have to be JSON, per se -- as long as the data can be initially parsed into NSDictionaries and NSArrays, then an Objective-C JSON-Schema validator can do a lot of heavy lifting for you.
The punch line is that if you've got Hydrant wired in to a schema validator on the client, it wouldn't necessarily need to know much about the model structure until runtime -- the client could pick up a small schema file from the server in preparation for parsing the subsequent REST response data.
I'd built framework that constructs Core Data entities and models at runtime using some home-grown JSON metadata, but didn't have the benefit of something like Hydrant to make it more tolerant of unexpected variations. Instead, the client code became packed with tons of extra error handling code.
If I were to do it over, (actually I plan to) I'd use JSON schema and map the models to NSCoding/NSCopying subclasses of NSObject constructed at runtime-- skipping Core Data in favor of something more flexible.
G
Sent from my iPhone.
On May 17, 2015, at 5:45 PM, Jeff Hui [email protected] wrote:
I don't think I fully understand what you mean. Are you saying Hydrant mappers built from a JSON-schema or model generation?
That being said, I have only lightly considered how JSON-Schema would fit in. I also was considering perhaps generating mappers from an example JSON file (with some extra tagging for optional fields). It sounds interesting but I haven't explored that idea much.
— Reply to this email directly or view it on GitHub.
It's definitely something that Hydrant's implementation could extend to support, but there still needs to be some way to map the schema file to properties of classes in source besides making some simple generalizing assumptions like HYDReflectiveMapper (aka, apply a key function).