+1 to option 1. I don't think there will be many states the lifecycle can go to from a given state. And the buttons should show the demote actions as well. Ex: If the API is in the "PUBLISHED" state, the possible state transitions are "CREATED" (demote), "PROTOTYPED" (demote), "BLOCKED" and "DEPRECATED". Therefore all these buttons should be displayed when the API is in the published state.
The default lifecycle xml should be in the file system of the product. And it should get copied to the registry space of the super tenant on first server startup. For tenants, it should get copied to the relevant tenant space when the tenant gets loaded the first time. This way organisations can change the default lifecycle states if necessary. The "PUBLISHED" state should be mandated. That should be the state the API goes into when you go through the API publishing wizard and press on "Save and Publish". We should also plan for a data migration strategy for people to migrate from 1.9.x to 1.10.0. Thanks, NuwanD. 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. > > 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. > > > Thanks > -- > Lakshman Udayakantha > WSO2 Inc. www.wso2.com > lean.enterprise.middleware > Mobile: *0711241005* > > -- Nuwan Dias Technical Lead - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
