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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
