Closed nseb closed 2 months ago
I have some comments:
I feel that it is adapted to serialization in only one direction; with Infinitic, we serialize/deserialize. But I guess there must be some cases where properties can be ignored in both directions.
Unless I am mistaken, you don't need new developments if you can update the ObjectMapper globally at worker level. Is that right? (One issue I can see is that this updated mapper object is global and not per workflow or per service - but it practice it may be enough)
What would be a new development? The presence of a @JsonView annotation on the objects to be serialized is not enough because I don’t know in advance if the user wants to use it. If I take inspiration from Spring, the idea would be that Infinitic takes into account a @JsonView annotation at class or method level in workflows and services, when handling ser/deserialization of parameters? How to define it at Client level (when starting a workflow)?
Hello @geomagilles
2 cf point 3 ,global for jsonview it's not the solution
3 Exact , Therefore for enable a jsonview , for example the client set in the meta map in the init workflow , a special attribute to set the correct jsonview value . As we would do with an annotation in spring at the controller level. And Infinitic can use this special meta attribute to enable or disable the correct view for serialize/deserialize
Fixed by b52c8a40bc9b9e3d68b38d1ee29b67bf6fa157cd
In Jackson, there is a JsonView feature, to have a different json format for the same object. In the case of infinitic, to integrate into an existing project, it would be interesting to support this functionality: https://www.baeldung.com/jackson-json-view-annotation
For example : In workflow , in meta a special meta name , json.view , can be set for select the correct json view desired , And Infinitic , if detected this special meta name , set the correct jsonview in the objectmapper.