Hi Samisa, On Fri, Nov 2, 2012 at 5:53 AM, Samisa Abeysinghe <[email protected]> wrote:
> > > 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. >> > > There is a usability issue with listing RXT randomy in the config tab. > 1. it looks messy with 10/12 RXTs > 2. I have no control as a user on the listing order > > The link only allow editing, thus why not have that linked form the > listing page and be done with it rather than adding to the menu? > +1 and done. Will commit after code freeze is done. Now the new menu provides a sorted list of RXTs which has options to delete/view/edit. > >> >>> >>> >>> >>>> >>>> >>>>> >>>>> 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 >> >> 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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
