I have implemented this feature as a slight variation of aforementioned
solution #1.
So rather than saving the custom property definitions in the RXT itself (as
another fields) there is a separate configuration file in the registry.
The reason behind this approach is to make sure that automatic UI
generation using RXT doesn't break.
*How to configure*
Add a custom property definition file for the desired app type (e.g.
webapp or mobile)
-- The file path should
be /_system/governance/appmgt/applicationdata/custom-property-definitions-
*app_type*.json
(e.g.
/_system/governance/appmgt/applicationdata/custom-property-definitions-webapp.json)
-- The content of the file should be a JSON which should look something
like below.
*[{"name":"overview_custom1"},{"name":"overview_custom2"}]*
*Request / Response payload fragment*
{
"name": "app1",
"version": "1.0",
"isDefaultVersion":true,
.
.
.
*"customProperties":[*
* {*
* "name":"overview_custom1",*
* "value":"custom_property_1"*
* }*
* ]*
}
On Fri, Jun 10, 2016 at 4:55 PM, Rushmin Fernando <[email protected]> wrote:
> *Correction*
>
> If RXTs has the support, we can go for #2, else #1 is a good option.
>
>
> On Fri, Jun 10, 2016 at 4:49 PM, Rushmin Fernando <[email protected]>
> wrote:
>
>> App Manager team had a quick chat on this and came up with the following
>> points.
>>
>> It is better if we can have the first class concepts like app-name,
>> context, version etc .. remain fixed.
>>
>> But like Sagara mentioned, we should make the custom attributes fields
>> dynamic in the DTO. For that, we can use a list of CustomProperty objects.
>>
>> e.g.
>>
>> AppDTO
>> -name
>> -version
>> -context
>> -other first class concepts
>> -cutomProperties :: List<CustomProperty>
>>
>> CustomProperty
>> -name
>> -value
>>
>> When populating the DTO, how can we know whether a property is a custom
>> property ? *Two options*
>>
>> 1) Maintaining a special field in the RXT, with the names of the custom
>> fields (Dimuthu's idea)
>> 2) Marking the registry property with a meta-property. e.g. customField
>>
>> If RXTs has the support, we can go for #1, else #1 is a good option.
>>
>>
>>
>>
>>
>> On Tue, Jun 7, 2016 at 9:44 AM, Dinusha Senanayaka <[email protected]>
>> wrote:
>>
>>> Hi All,
>>>
>>> We could not go for approach suggested by Sagara due to the reasons
>>> explained by Lahiru in previous reply. We could go for what Dimuthu has
>>> suggested (keep custom fields in a json string), but it will be difficult
>>> to populate UI. Anyway if we cannot keep rxt metadata something like
>>> follows we have to go with that approach. Appreciate any other suggestions
>>> on this ?
>>>
>>> <field type="text" required="true" *customField="true"*>
>>> <name>Name</name>
>>> </field>
>>>
>>> Regards,
>>> Dinusha.
>>>
>>> On Fri, May 27, 2016 at 11:21 PM, Lahiru Cooray <[email protected]>
>>> wrote:
>>>
>>>> Hi,
>>>> (In AppM REST API design we followed the contract first approach
>>>> according to [1])
>>>>
>>>> The main concern is how do we manage an API definition (eg:swagger) if
>>>> our
>>>> request/response data models are dynamic?
>>>> And also in AppM user story there are few domain specific constraints
>>>> we need to address so AFAIC our models should be specific.
>>>>
>>>> So, to cater the $subject one approach would be as Dimuthu has
>>>> mentioned, constructing a JSON string with all custom fields
>>>> name/value pairs and add that as a value in an RXT field, where we are
>>>> aware of the custom attributes. So we can place a property in our DTO to
>>>> filter and dynamically add the custom attributes.
>>>>
>>>>
>>>> [1] WSO2 REST APIs Design Guidelines
>>>> <https://mail-attachment.googleusercontent.com/attachment/u/1/?ui=2&ik=eeed032778&view=att&th=153cac6e0121d5c7&attid=0.3&disp=inline&realattid=f_imfqigvq2&safe=1&zw&saddbat=ANGjdJ97Zr-Wn0_34Q8gZ93xllw3HjDhqBz_TCvuJEeZblKVlnghpEZoX6H3D6njd1VCmZEG-HTQvjocS7xhODFpbrjvINDTQkO9vtp0-MX0dBysDGBBGBWCXKKa6hKvblsJuYsYWVYO7-MwzuJvGBHk_KkKR3oFQyRGE4yke5n4NYNxnfI07P5eHbb7914r4bhxtXLX8X3m65F7-GYyr42EPpdQOPt1yy-bQ2Yi-Msmb4qlD0Ya4UAGqX7h1FxSFEMLJLJY7cRNsz5QYnXpy3sggp_EWbSyg5QyQqAZN1G5WPx6VeMX-8ibEyIoWYL1rtQsKB0Oi7u52iQDDB3OwIvXFljJdJb-2POsQMPUSPy30m84dgQ_Aqj-eWWQzh-IK-eoHzsYQuaXb87w5Fe7neHW_AQDfRuBXy6rZNeluVOxZPgUnXaTe5X353OYTswQdWCIx9-dw2qpsupxF0ECm_vIHoIQF-oKNUBpHPKQThM0XaKm4IEYxQl-XEt1cYT6lQSM2Xe-pEKgyhPnaBIQN30tIYwDO86LliRALRTDGTnc315abijbbjWbCTEosVlJ3o52QI8t5Eow0mkcT8mhzQpTFFKInPRzwDU3MBsYataoWBnJjhngR47o-DUw7Dwiri5Hyph6FoSw5PvMUJiU>
>>>>
>>>> On Fri, May 27, 2016 at 10:03 AM, Dimuthu Leelarathne <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> According to the userstory, I think the custom fields are going to be
>>>>> defined per deployment. In that case we can ask the RXT to be modified at
>>>>> the deployment time as Sagara suggested. Or else you can construct a JSON
>>>>> string with all custom fields name/value pairs and add that as a value in
>>>>> an RXT field. I also believe Sagara's approach is more elegant as that has
>>>>> inherent support and full-fills the requirement.
>>>>>
>>>>> thanks,
>>>>> Dimuthu
>>>>>
>>>>> On Thu, May 26, 2016 at 10:35 PM, Sagara Gunathunga <[email protected]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, May 26, 2016 at 10:36 AM, Dinusha Senanayaka <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> +Chandana
>>>>>>>
>>>>>>> On Thu, May 26, 2016 at 9:03 PM, Dinusha Senanayaka <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> There are some use cases that publisher UI need to be customized by
>>>>>>>> adding new UI fields. Those fields can be used in the store for
>>>>>>>> different
>>>>>>>> use cases (eg; App Price). With the support of Enterprise Store,
>>>>>>>> getting
>>>>>>>> this done is very easy. It's just adding new field/s in the RXT and few
>>>>>>>> modifications to .hbs file. We don't have to do anything additionally
>>>>>>>> to
>>>>>>>> POST/UPDATE/GET app info with these new fields trough the jaggery
>>>>>>>> APIs.
>>>>>>>>
>>>>>>>> Requirement is how are we going to do this with the new REST API
>>>>>>>> model. We use pre-defined DTO classes for request/response generation
>>>>>>>> with
>>>>>>>> the swagger definition. Therefore publisher users could not add new
>>>>>>>> custom
>>>>>>>> fields easily and get them supported through the APIs as previously
>>>>>>>> without
>>>>>>>> modifying the code.
>>>>>>>>
>>>>>>>> One option is, pre-define "customFields" object inside AppDTO class
>>>>>>>> and get the users to define custom fields in the RXT with new tag
>>>>>>>> called
>>>>>>>> "customFields". So that we could populate value inside the DTO class by
>>>>>>>> looking at the fields marked as customFields in the RXT. But this
>>>>>>>> requires
>>>>>>>> capability to define some additional property to RXT field in addition
>>>>>>>> to
>>>>>>>> name/value. @Registry team, any ideas on whether this is possible ?
>>>>>>>>
>>>>>>>
>>>>>> I don't see any issue to solve at the Registry/RXT model level, as
>>>>>> you also mentioned once you modify underline RXT to accommodate
>>>>>> additional
>>>>>> fields ES will pickup them easily. If you look at G-Reg REST API wick
>>>>>> also
>>>>>> adjust RXT changes automatically.
>>>>>>
>>>>>> You face to above problem due to pre-defined DTOs, you need to find a
>>>>>> solution at that level, better not to use fixed DTOs at all. May be
>>>>>> referring to G-Reg REST API implementation will help[1]
>>>>>>
>>>>>>
>>>>>> [1] -
>>>>>> https://github.com/wso2/carbon-governance/tree/master/components/governance/org.wso2.carbon.governance.rest.api
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks !
>>>>>>
>>>>>>>
>>>>>>>> Suggestions/feedback are appreciated.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Dinusha.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Dinusha Dilrukshi
>>>>>>>> Associate Technical Lead
>>>>>>>> WSO2 Inc.: http://wso2.com/
>>>>>>>> Mobile: +94725255071
>>>>>>>> Blog: http://dinushasblog.blogspot.com/
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Dinusha Dilrukshi
>>>>>>> Associate Technical Lead
>>>>>>> WSO2 Inc.: http://wso2.com/
>>>>>>> Mobile: +94725255071
>>>>>>> Blog: http://dinushasblog.blogspot.com/
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Architecture mailing list
>>>>>>> [email protected]
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sagara Gunathunga
>>>>>>
>>>>>> Architect; WSO2, Inc.; http://wso2.com
>>>>>> V.P Apache Web Services; http://ws.apache.org/
>>>>>> Linkedin; http://www.linkedin.com/in/ssagara
>>>>>> Blog ; http://ssagara.blogspot.com
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> [email protected]
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dimuthu Leelarathne
>>>>> Director, Solutions Architecture
>>>>>
>>>>> WSO2, Inc. (http://wso2.com)
>>>>> email: [email protected]
>>>>> Mobile: +94773661935
>>>>> Blog: http://muthulee.blogspot.com
>>>>>
>>>>> Lean . Enterprise . Middleware
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> [email protected]
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Lahiru Cooray*
>>>> Software Engineer
>>>> WSO2, Inc.;http://wso2.com/
>>>> lean.enterprise.middleware
>>>>
>>>> Mobile: +94 715 654154
>>>>
>>>
>>>
>>>
>>> --
>>> Dinusha Dilrukshi
>>> Associate Technical Lead
>>> WSO2 Inc.: http://wso2.com/
>>> Mobile: +94725255071
>>> Blog: http://dinushasblog.blogspot.com/
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Best Regards*
>>
>> *Rushmin Fernando*
>> *Technical Lead*
>>
>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware
>>
>> mobile : +94772891266
>>
>>
>>
>
>
> --
> *Best Regards*
>
> *Rushmin Fernando*
> *Technical Lead*
>
> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware
>
> mobile : +94772891266
>
>
>
--
*Best Regards*
*Rushmin Fernando*
*Technical Lead*
WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware
mobile : +94772891266
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
