+1 for providing a view option in addition. So what is the conclusion ?
On Thu, Nov 1, 2012 at 11:21 PM, Senaka Fernando <sen...@wso2.com> 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 <era...@wso2.com>wrote: > >> Hi Subash, >> >> >> On Thu, Nov 1, 2012 at 9:18 PM, Subash Chaturanga <sub...@wso2.com>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 > > -- Subash Chaturanga Software Engineer WSO2 Inc. http://wso2.com email - sub...@wso2.com phone - 077 2225922
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
