Changed the resource path as RuwanA suggested and changed the resource
content structure to give some context.
*New custom property definitions location*
/_system/governance/appmgt/applicationdata/custom-property-definitions/
*app_type*.json
e.g.(
/_system/governance/appmgt/applicationdata/custom-property-definitions/
*webapp*.json )
*New definitions structure*
{"*customPropertyDefinitions*
":[{"name":"overview_custom1"},{"name":"overview_custom2"}]}
On Thu, Jun 16, 2016 at 3:17 PM, Rushmin Fernando <[email protected]> wrote:
> Thanks for the feedback Ruwan. Yes we should do that :-)
>
> On Wed, Jun 15, 2016 at 5:50 PM, Ruwan Abeykoon <[email protected]> wrote:
>
>> Hi Rushmin,
>> Can we change
>> file path /_system/governance/appmgt/applicationdata/custom-
>> property-definitions/*app_type*.json
>>
>> Reason: it looks nice.
>>
>> Cheers,
>> Ruwan
>>
>> On Wed, Jun 15, 2016 at 4:53 PM, Rushmin Fernando <[email protected]>
>> wrote:
>>
>>> 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
>>>
>>>
>>
>>
>> --
>>
>> *Ruwan Abeykoon*
>> *Associate Director/Architect**,*
>> *WSO2, Inc. http://wso2.com <http://wso2.com/> *
>> *lean.enterprise.middleware.*
>>
>> email: [email protected]
>>
>> _______________________________________________
>> 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
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
