Hi all, Today we had a discussion on Asset Store in G-Reg, and in that discussion there was a proposal to redefine how an RXT would be added/saved. But it requires migration, and therefore it is not something that we'd be doing in a patch release, so, we should consider having a short-term as well as long-term solution to this.
Thanks, Senaka. On Fri, Nov 2, 2012 at 5:34 AM, Subash Chaturanga <[email protected]> wrote: > > > On Fri, Nov 2, 2012 at 4:54 AM, Samisa Abeysinghe <[email protected]> wrote: > >> >> >> On Fri, Nov 2, 2012 at 4:45 AM, Subash Chaturanga <[email protected]>wrote: >> >>> >>> >>> On Fri, Nov 2, 2012 at 4:25 AM, Samisa Abeysinghe <[email protected]>wrote: >>> >>>> Looking at these use cases, I would imagine that we have to have an LC >>>> like listing of RXT types under config tab, rather than having them listed >>>> individually in there - in other words, one-stop-shop view to help with >>>> these actions. >>>> >>> >>> If I am not mistaken you mean a LC like listing under Home > >>> Extensions > Configure > Lifecycles ? If so that is the intended >>> implementation (i.e Home > Extensions > Configure > Artifact Types). >>> >> >> +1 >> >> >> >>> Anyway we will have the RXT configurations individually listed under >>> Home > Configure. >>> >> >> If we have the above, would we still need this? >> > > In the current implementation what we have is the RXTs gets list > under Home > Configure. And what I am implementing is a LC creation like > UI as above which also has the list of artifacts. And there I thought a > delete option is enough in that list. > > >> >> >> >>> >>> >>>> >>>> On Thu, Nov 1, 2012 at 11:21 PM, Senaka Fernando <[email protected]>wrote: >>>> >>>>> Hi Subash, >>>>> >>>>> Hold on, there are multiple angles to this. You've just pointed out >>>>> one, but there are several other things one might try to do. For example, >>>>> >>>>> 1. someone might want to create a copy from an existing RXT and create >>>>> a new one. Some people actually do this even today. For them, edit is not >>>>> required, but being able to view the existing RXT is. (note: in the LC UI, >>>>> view and edit are both a single interface). >>>>> >>>>> 2. another user might try to make changes to the columns in a list UI, >>>>> but not actually change the layout of the add/edit view. Asking someone to >>>>> delete and add again is not the best answer. >>>>> >>>>> So, for #1, view is required and for #2 a partial edit is required. We >>>>> also have a #3, which Eranda pointed out (i.e. being able to reconfigure >>>>> the layout of the add/edit view). #3 can actually be done through the >>>>> configure UI, but one could ask, why don't we have a complete edit instead >>>>> of a partial edit, and get rid of the separate configure UI. This would >>>>> make services and RXTs inconsistent, but then again, we can convert >>>>> service >>>>> to be represented using an RXT too. >>>>> >>>>> So, I'd like to suggest that we reconsider this decision and >>>>> understand the problem end-to-end and find a proper lasting solution, >>>>> without attempting a quick fix. >>>>> >>>>> Thanks, >>>>> Senaka. >>>>> >>>>> On Thu, Nov 1, 2012 at 10:24 PM, Eranda Sooriyabandara < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Subash, >>>>>> >>>>>> >>>>>> On Thu, Nov 1, 2012 at 9:18 PM, Subash Chaturanga <[email protected]>wrote: >>>>>> >>>>>>> Hi, >>>>>>> This is regarding when GReg provides a UI to upload RXTs and also >>>>>>> list them. Shall we have $subject ? Because if we provide edit options >>>>>>> for >>>>>>> an already installed RXT, once the RXT config is updated, already >>>>>>> created >>>>>>> RXT instances out of the old one becomes staled. And you cannot expect >>>>>>> the >>>>>>> new behavior from the old instances (users might not able to identify >>>>>>> the >>>>>>> old ones explicitly) . In that context I feel it is an invalid use case. >>>>>>> >>>>>>> This can be considered when we support development time governance. >>>>>>> So shall we do $subject ? >>>>>>> >>>>>> >>>>>> +1. Since we use have the validations for RXTs when uploading, we >>>>>> should have the feeling that there are no error in the configuration. So >>>>>> I >>>>>> guess there is no point in updating a RXT other than to do a content >>>>>> (artifact content) change which can be done by changing the configuration >>>>>> (Configure tab). So there are less or no usecase in changing the RXT. >>>>>> >>>>>> thanks >>>>>> Eranda >>>>>> >>>>>> * >>>>>> * >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Senaka Fernando* >>>>> Member - Integration Technologies Management Committee; >>>>> Technical Lead; WSO2 Inc.; http://wso2.com* >>>>> Member; Apache Software Foundation; http://apache.org >>>>> >>>>> E-mail: senaka AT wso2.com >>>>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 >>>>> Linked-In: http://linkedin.com/in/senakafernando >>>>> >>>>> *Lean . Enterprise . Middleware >>>>> >>>>> Thanks, >>>> Samisa... >>>> >>>> Samisa Abeysinghe >>>> VP Engineering >>>> WSO2 Inc. >>>> http://wso2.com >>>> http://wso2.org >>>> >>>> >>>> >>> >>> >>> -- >>> >>> Subash Chaturanga >>> Software Engineer >>> WSO2 Inc. http://wso2.com >>> >>> email - [email protected] >>> phone - 077 2225922 >>> >>> Thanks, >> Samisa... >> >> Samisa Abeysinghe >> VP Engineering >> WSO2 Inc. >> http://wso2.com >> http://wso2.org >> >> >> > > > -- > > Subash Chaturanga > Software Engineer > WSO2 Inc. http://wso2.com > > email - [email protected] > phone - 077 2225922 > > -- *Senaka Fernando* Member - Integration Technologies Management Committee; Technical Lead; WSO2 Inc.; http://wso2.com* Member; Apache Software Foundation; http://apache.org E-mail: senaka AT wso2.com **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://linkedin.com/in/senakafernando *Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
