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
