Hey Guys,
While working on OpenApi integration as well as GraphQL implementation, I
faced issues on how to automatically document request/response JSON
structure for service attributes that were of Collection types (Map, List
etc).
For simple types, it is just plain easy but when it comes to Map/Lists, you
have to know what exactly is inside them to be able to convey properly in
the OpenApi schema.
I was thinking to may be try to introduce nested attributes in service
definition such that if the attribute type is Map/List, you can actually
specify what goes inside that attribute -
<attribute name=*"header"* type=*"Map"* mode=*"IN"* optional=*"true"* >
<attribute name=*"xy"* type=*"Integer"* default-value=*"0"* />
<attribute name=*"xyz"* type=*"String"* default-value=*"test"*/>
</attribute>
With this change, it becomes possible to generate the schema for the
service attribute, Where as if we don't have this option, we can't possibly
indicate what the structure of the "header" key is going to be if it was
represented in JSON format.
Of course, this change will only help documentation and GraphQL
implementation and that there is very little case for it to benefit a
general OFBiz service call.
Any thoughts or comments on this? Is this too big of a change (impact wise
and not coding perspective) to avoid it and consider something else? Has
this been discussed before?
Best,
Girish
