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