If we are not storing trivial artifacts, it is very difficult to use a common UI for store and especially for publisher. If a store framework is used, we end up extending it and in many situations it can become more complex than developing a new UI. Therefore, I agree with Nuwan and SajithAR that we should focus on reusable UIs only for parts that can be used as it is, or with minimal modifications such as login, user management, etc.
- Chathura On Wed, Sep 28, 2016 at 11:57 AM, SajithAR Ariyarathna <sajit...@wso2.com> wrote: > On Wed, Sep 28, 2016 at 10:06 AM, Chandana Napagoda <chand...@wso2.com> >> wrote: >> I believe that we should identify commonly used components and implement >> them in a generalized manner. So relevant product team can extend those >> components based on their requirements. > > Agreed, this is the mitivation/goal of UUF. > > On Wed, Sep 28, 2016 at 11:09 AM, Nuwan Dias <nuw...@wso2.com> wrote: > > My gut feeling is that if we go down this path, we will put a lot of >> effort/cycles to build a generic component/framework. Then we will again >> put a lot of effort to extend that component and try to build the specifics >> for the relevant Product Store. Which kind of doesn't make sense. > > This is exactly my concern. > > One approach we discussed early, is to develop a web app (e.g. APIM Store) > and identify what can be generalized and make them into generic UI > component alongside. > > Thanks. > > > On Wed, Sep 28, 2016 at 11:09 AM, Nuwan Dias <nuw...@wso2.com> wrote: > >> >> >> On Wed, Sep 28, 2016 at 10:06 AM, Chandana Napagoda <chand...@wso2.com> >> wrote: >> >>> Hi, >>> >>> As per my understanding, within WSO2 products there should be some set >>> of components which are providing generalized and shared features to >>> products including searching, basic listing, login UI, etc. Otherwise most >>> of the product team have to duplicate their effort. Ex: IS portal, IoT, and >>> APIM teams have to write their searching components, and that will be a >>> duplicated effort. I believe that we should identify commonly used >>> components and implement them in a generalized manner. So relevant product >>> team can extend those components based on their requirements. >>> >> >> All these capabilities are addressed by APIs. Ex: In the case of listing >> APIs, what API Manager does it a GET /apis. Same for search. i.e GET >> /apis/search?name=xxx&version=1.0.0. So each product (in C5) will >> basically have its own APIs that perform these functionality. And these >> functionality (back-end) won't be shared, because how we fetch APIs and how >> we fetch Devices will be completely independent and there won't be anything >> that's shared between them. >> >> The only thing that looks common is is the rendering part. But even in >> that, different products will have different needs. Ex: API Manager will >> want to groups APIs into packages (products) and display on the listing >> page. It may have meta information that's specific to API Manager (Business >> Owner). So there are still many specifics to address in the rendering part. >> My gut feeling is that if we go down this path, we will put a lot of >> effort/cycles to build a generic component/framework. Then we will again >> put a lot of effort to extend that component and try to build the specifics >> for the relevant Product Store. Which kind of doesn't make sense. You also >> need to take into consideration the release dependencies, version >> incompatibilities, etc, etc. Isn't this the same thing we tried to do once >> with Enterprise Store? >> >>> >>> Regards, >>> Chandana >>> >>> >>> On Tue, Sep 27, 2016 at 8:01 PM, SajithAR Ariyarathna <sajit...@wso2.com >>> > wrote: >>> >>>> Hi All, >>>> >>>> Creating a reusable Store component was one of goals we had in our >>>> minds at UUF initial discussions. At that time there was couple of products >>>> APIM, AppM, EMM mobile store, GReg etc. that need a Store UI. So developing >>>> a generalized Store component was a requirement. However with the new >>>> product strategy there is not as many products (only APIM, IoT, IS) that >>>> need a Store UI. I feel like their requirements are too broad and diverse, >>>> hence we might not be able to develop a generalized Store component. >>>> Instead of developing a Store component, we can develop other small >>>> component that are needed for a store e.g. SSO component, Social, >>>> Self-signup, user-mgt. This is just my opinion/gut feeling. We should >>>> discuss this thoroughly. >>>> >>>> Shall we setup a meeting for this? >>>> >>>> Thanks. >>>> >>>> On Tue, Sep 27, 2016 at 7:04 PM, Selvaratnam Uthaiyashankar < >>>> shan...@wso2.com> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Sep 27, 2016 at 6:47 PM, Nuwan Dias <nuw...@wso2.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Sep 27, 2016 at 6:31 PM, Selvaratnam Uthaiyashankar < >>>>>> shan...@wso2.com> wrote: >>>>>> >>>>>>> >>>>>>> On Tue, Sep 27, 2016 at 6:14 PM, Nuwan Dias <nuw...@wso2.com> wrote: >>>>>>> >>>>>>>> Do we really need a Store Framework for C5? >>>>>>>> >>>>>>> >>>>>>> >>>>>>> May be store framework is a wrong terminology, but there should be a >>>>>>> reusable store component written by using UUF. >>>>>>> >>>>>> >>>>>> So UUF itself is re-usable. We're going to build a Store component >>>>>> that's also re-usable using UUF. That's two levels of abstraction before >>>>>> we >>>>>> get to the actual generalization. It sounds like too much abstraction to >>>>>> me >>>>>> :). Unless there is a strong need, IMO we should just go by reusing what >>>>>> UUF offers and build our own Stores on that. >>>>>> >>>>> >>>>> I'll let UUF guys to answer this, but one of the requirement was to >>>>> create reusable components like store/login/dashboard using UUF. >>>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>>> Rather, isn't it a UI framework (UUF) we need to build UIs? Apart >>>>>>>> from API-M and IoTS, are there any other products which need a Store? >>>>>>>> >>>>>>> >>>>>>> Store is needed in IS (end user portal, similar to AppM) as well. >>>>>>> >>>>>> >>>>>> The end user portal is a dashboard right? Its not really a Store. >>>>>> >>>>> >>>>> Part of end user portal is the store of applications available for the >>>>> user. Similar to app manager store with applications configured with SSO. >>>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Even if we come up with a Store Framework, I think the facilities >>>>>>>> it provides will be minimal isn't it? Since the products that use this >>>>>>>> Store will have its own set of APIs for the back-end functionality, the >>>>>>>> only thing the Store UI would be doing is to call that set of APIs for >>>>>>>> the >>>>>>>> relevant functionality (ex: search API, list API). Therefore if we try >>>>>>>> to >>>>>>>> list the generic functionality offered by the Store Framework, I feel >>>>>>>> the >>>>>>>> functionality it provides will be minimal. And if that's true, then >>>>>>>> there's >>>>>>>> really no point in building a Store Framework. The products better >>>>>>>> build >>>>>>>> their own Stores using the common UI framework based on a theme that's >>>>>>>> common across the platform. >>>>>>>> >>>>>>>> On Tue, Sep 27, 2016 at 3:40 PM, Chandana Napagoda < >>>>>>>> chand...@wso2.com> wrote: >>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> While analyzing store requirements of C5 based products(IoT, >>>>>>>>> APIM), we have few areas to be clarified. Based on the current >>>>>>>>> understanding, C5 based store will not be bound into existing >>>>>>>>> governance >>>>>>>>> aspects. This should be a store framework with listing and searching >>>>>>>>> capabilities. >>>>>>>>> >>>>>>>>> Should we consider generic metadata-based asset model for C5 based >>>>>>>>> Store? >>>>>>>>> >>>>>>>>> Does asset authoring(publisher) should be implemented with the >>>>>>>>> store, or relevant product team should implement it based on their >>>>>>>>> use case? >>>>>>>>> >>>>>>>>> Does store needs to support multi-tenancy or are we moving to the >>>>>>>>> different tenant-based container approach? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Chandana >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Chandana Napagoda* >>>>>>>>> Associate Technical Lead >>>>>>>>> WSO2 Inc. - http://wso2.org >>>>>>>>> >>>>>>>>> *Email : chand...@wso2.com <chand...@wso2.com>**Mobile : >>>>>>>>> +94718169299 <%2B94718169299>* >>>>>>>>> >>>>>>>>> *Blog : http://cnapagoda.blogspot.com >>>>>>>>> <http://cnapagoda.blogspot.com> | http://chandana.napagoda.com >>>>>>>>> <http://chandana.napagoda.com>* >>>>>>>>> >>>>>>>>> *Linkedin : http://www.linkedin.com/in/chandananapagoda >>>>>>>>> <http://www.linkedin.com/in/chandananapagoda>* >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Nuwan Dias >>>>>>>> >>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>> email : nuw...@wso2.com >>>>>>>> Phone : +94 777 775 729 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> Architecture@wso2.org >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> S.Uthaiyashankar >>>>>>> VP Engineering >>>>>>> WSO2 Inc. >>>>>>> http://wso2.com/ - "lean . enterprise . middleware" >>>>>>> >>>>>>> Phone: +94 714897591 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nuwan Dias >>>>>> >>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>> email : nuw...@wso2.com >>>>>> Phone : +94 777 775 729 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> S.Uthaiyashankar >>>>> VP Engineering >>>>> WSO2 Inc. >>>>> http://wso2.com/ - "lean . enterprise . middleware" >>>>> >>>>> Phone: +94 714897591 >>>>> >>>> >>>> >>>> >>>> -- >>>> Sajith Janaprasad Ariyarathna >>>> Software Engineer; WSO2, Inc.; http://wso2.com/ >>>> <https://wso2.com/signature> >>>> >>> >>> >>> >>> -- >>> *Chandana Napagoda* >>> Associate Technical Lead >>> WSO2 Inc. - http://wso2.org >>> >>> *Email : chand...@wso2.com <chand...@wso2.com>**Mobile : +94718169299 >>> <%2B94718169299>* >>> >>> *Blog : http://cnapagoda.blogspot.com >>> <http://cnapagoda.blogspot.com> | http://chandana.napagoda.com >>> <http://chandana.napagoda.com>* >>> >>> *Linkedin : http://www.linkedin.com/in/chandananapagoda >>> <http://www.linkedin.com/in/chandananapagoda>* >>> >>> >> >> >> -- >> Nuwan Dias >> >> Software Architect - WSO2, Inc. http://wso2.com >> email : nuw...@wso2.com >> Phone : +94 777 775 729 >> > > > > -- > Sajith Janaprasad Ariyarathna > Software Engineer; WSO2, Inc.; http://wso2.com/ > <https://wso2.com/signature> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
