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