You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "Girish Vasmatkar (Jira)" <ji...@apache.org> on 2020/07/21 05:23:00 UTC
[jira] [Updated] (OFBIZ-11902) Nested attributes for Collection
Types
[ https://issues.apache.org/jira/browse/OFBIZ-11902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Girish Vasmatkar updated OFBIZ-11902:
-------------------------------------
Description:
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 -
{code:java}
// code placeholder
{code}
<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>
{code:java}
// code placeholder
{code}
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.
was:
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.
> Nested attributes for Collection Types
> --------------------------------------
>
> Key: OFBIZ-11902
> URL: https://issues.apache.org/jira/browse/OFBIZ-11902
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL APPLICATIONS
> Affects Versions: Trunk
> Reporter: Girish Vasmatkar
> Assignee: Girish Vasmatkar
> Priority: Minor
> Fix For: Upcoming Branch
>
>
> 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 -
>
> {code:java}
> // code placeholder
> {code}
> <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>
> {code:java}
> // code placeholder
> {code}
>
> 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.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)