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). Anyway we will have the RXT configurations individually listed under Home > Configure. > > 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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
