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. 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 ? 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
