Open atkretsch opened 7 years ago
The solution in the serializer was to use this 'contract resolver': https://github.com/joukevandermaas/saule/blob/master/Saule/Serialization/JsonApiContractResolver.cs (see #132).
I'm guessing we could do the same for the deserializer.
@joukevandermaas Yes, that makes more sense than my initial idea. If you don't mind I'll take a crack at it and put up a PR.
That would be great!
Hello gentlemen, any update regarding this issue?:)
@esotery I'm still very open to a PR!
Unfortunately I haven't had time to take another look at this yet. Hoping I will in the near future, but in the meantime, @esotery feel free to do so yourself if you're so inclined!
Fixed. Sorry, It would have been fixed yesterday but the the internet connection dropped out.
Similar to #131, but for deserialization.
Given the following class structure:
...the following JSON (e.g. in a
POST
request):...will result in a
Person
class such thatperson.Name.FirstName == null
andperson.Name.LastName == null
.However, if the nested attributes are changed to UpperCamelCase (e.g.
FirstName
andLastName
), then the result is correct (e.g.person.Name.FirstName == "John"
,person.Name.LastName == "Doe"
). And when serializing (e.g. in a response), the result has the expected kebab-case (because of #131).I know many examples of nested objects like this can probably be refactored as relationships, etc., but as discussed in #131 it's sometimes useful to use "value objects" for grouping of closely-related attributes. Additionally, if the default behavior for serialization is to handle kebab-casing all the way down, then it seems reasonable that the same should be true for deserialization for consistency and request/response symmetry.
From poking around the code a bit, it seems like the
ResourceDeserializer
would have to be changed to recursively callToFlatStructure()
for non-primitive attribute values (similar to what it does for relationships).