Hello Girish, IMO, the option which you have suggested looks good in case if we want to leverage upon the existing service definitions for creating the API documentation. I also think that this could be a good addition to OFBiz in the developer perspective, as right now, it is very difficult to guess the content of the Map/List attributes seeing at service definition. For the attribute type GenericValue, we can skip the nested structure.
Kind Regards, -- Pritam Kute On Thu, Jul 16, 2020 at 5:21 PM Girish Vasmatkar < girish.vasmat...@hotwaxsystems.com> wrote: > 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 >
