On Thu, Sep 10, 2015 at 9:43 PM, Nuwan Dias <[email protected]> wrote: > > > On Thu, Sep 10, 2015 at 6:17 PM, Sagara Gunathunga <[email protected]> > wrote: > >> >> >> On Thu, Sep 10, 2015 at 3:38 PM, Lakshman Udayakantha <[email protected] >> > wrote: >> >>> Hi, >>> >>> API Manager currently uses its own lifecycle implementation. It will >>> limited to a defined set of lifecycle statuses. >>> With API Manager 1.10.0, The plan is to move with registry life cycles. >>> Currently API Publisher loads pre-defined list of statuses. This will be >>> changed to load statues from registry. Registry manages lifecycle >>> information in APILifeCycle.xml. After loading lifecycle status from >>> registry, it will be able to add custom lifecycle status also to API >>> Manager. >>> >> >> +1 >> >> I guess most of the backend code changes required for this is already >> available with API-M 2 code base. >> >>> >>> Here are two suggestions raised to implement this in UI level, >>> >>> 1. We can add a label to show the status instead of drop down list and >>> can show the event transitions as buttons. updated status will show on >>> status label. Those visible status names will load from status ids in >>> APILifeCycle.xml. According to the status, appropriate buttons will be >>> loaded. Visible button status will be transition event in APILifeCycle.xml. >>> >>> As an example: >>> >>> when API is in Created status the only possible status transitions are >>> "Promote" and "Publish" according to default APILifeCycle.xml. So buttons >>> with those names will be visible as below picture depicted. >>> >>> >>> ​Pros: Invalid transitions will not be selected from drop down list, >>> Easier to implement rather replace with API Manager 2.0.0 publisher feature >>> lifecycle UI (look option 2). >>> Cons :User has no way to know the next status until user clicks the >>> promote or demote buttons. As a solution for this we can load the button >>> names for next status. But if there are huge number of next statuses it >>> will be unfeasible to load all the button names. >>> >>> 2. This has already implemented in API Manager 2.0.0 feature for greg >>> integration with D3js library. We can integrate that UI in API Manager >>> 1.10.0 too by replacing current drop down menu and button set. >>> Pros : This will give a clear picture to the user about status >>> transition and nice looking interface, Invalid transitions will not be >>> selected from drop down list. >>> Cons : Since future UIs of API Manager will be the UI belongs to API >>> Manager 2.0.0 feature set, recreating API Manager 2.0.0 lifecycle UI in API >>> Manager 1.10.0 will be an additional effort. >>> >> >> Isn't that option-1 involved with additional effort ? because you have >> to implement UIs for option-1 and throw it out completely during 2.0.0 and >> the other point is option-2 is already working on API-M 2.0-SNAPSHOTS so >> can't be much hard to port. Having said I don't have strong preference on >> one over another. >> > > What was done for GREG was on top of ES. Since 1.10.0 isn't using ES, its > easy to come up with a much simpler UI rather than trying to port the stuff > on ES to APIM. And we already have a Lifecycle Management section on our > UI, tweaking that a bit won't be much of an effort. > >> >> BTW I have a different suggestion, During the G-Reg 5.0.0 development >> time we wanted to design improved UX experience for Lifecycle view and >> Lifecycle transition but we had to delayed this item due to timeline >> problems, may be we should get UX teams help and design proper UX >> experience for LCM this time so that we can use same design consistently in >> G-Reg, ES , APP-M, API-M etc. WDYT ? >> > > +1, but this should be done on ES as it is done today. And the other > products should inherit from that IMO. >
What I actually mean was properly design use experience and user interfaces for Lifecycle view/Lifecycle transition ( basically an exercise with UX folks), depend on timelines we may choose implementation technology (ES, Jaggery or anything else ) what important is to build some consistent experience across the platform which is independent from implementation technology . Thanks ! > >> >> Thanks ! >> >>> >>> >>> Thanks >>> -- >>> Lakshman Udayakantha >>> WSO2 Inc. www.wso2.com >>> lean.enterprise.middleware >>> Mobile: *0711241005* >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sagara Gunathunga >> >> Architect; WSO2, Inc.; http://wso2.com >> V.P Apache Web Services; http://ws.apache.org/ >> Linkedin; http://www.linkedin.com/in/ssagara >> Blog ; http://ssagara.blogspot.com >> >> > > > -- > Nuwan Dias > > Technical Lead - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 > -- Sagara Gunathunga Architect; WSO2, Inc.; http://wso2.com V.P Apache Web Services; http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
