Introduction:
This document describes the design approach of using the TPD framework in the portal.
Background:
Jira Issue: https://project-sunbird.atlassian.net/browse/SH-3
Epic: https://project-sunbird.atlassian.net/browse/SH-33
Presently any tenant is using the framework as customization list of tenant-specific data(BGMS, Topics, sub-topics etc..). This framework is very well defined for ETB workflow
Problem Statement:
How custom tenant framework can be used for content/resources created for course.
Key design problems:
The course related workflows (course, content/resources creation) should be attached with the default/custom TPD framework specified by the tenant
Existing workflow:
Since, SH-3, we have segregated the create workflow into two parts:
a. Textbook
b. Training.
Now, we need to change this workflow, as we have introduced a custom framework for any tenant (as of now, CBSE has its custom framework called ‘cbse-tpd’ ) and we need to take that framework while creating content from the training sub-tab.
Solution 1:
We will make an API call (getformConfig) to get the custom framework while we start creating any course/resource from the training sub-tab.
** request body for the form read API:
{ formType: 'framework', formAction: 'search', contentType: 'framework-code', }
Note : Since we are making the same getFormConfig API call to get the custom framework what we are making in the “Training” page, then we can take the same from the cache.
If the user is directly coming to the workspace and trying to create anything from the training sub-tab, then only we will make the API call and store it in the cache.
So, When the user goes to the “Training” page, we won’t make the API call again.
Pros: This is an existing workflow. It will be easy to implement.
Cons: Now going forward with this approach, all the creation related to training should take this custom framework (if any). Whether it is just a content creation from the training sub-tab or copying of a course or front-end creation of a curriculum course. Changes have to be done in all the places.
Solution 2 :
To get a new API which will give a list of frameworks tagged with a tenant.
We, from the portal side, will call this API in the first place to get the list of frameworks and use these frameworks accordingly.
Pros: We will get the list of frameworks in the very first place.
Cons: Dependency on the back-end team to create this new API.
Solution 3:
We can have the list of frameworks in the getTenantInfo which we also call when the portal is loaded for the first time.