You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 27, 2024. It is now read-only.
Is your feature request related to a problem? Please describe.
A user might want to experiment with several different course plans without having to override them, in addition, he
might want to share his plan with other users, and have them "fork" his plan and modify it further.
Describe the solution you'd like
A solution based on database support:
On the backend side, this would require model changes, namely, the addition of a Plan model, and decoupling of Student from Take, instead, a Plan has many Takes, and a student has many Plans.
A plan can also have a field indicating whether it is publicly readable or private, and a name/description.
There would also need to be limits on the number of plans (and the number of courses within each plan) to
prevent abuse.
On the front-end side, there would be a menu under the navbar with various options:
Save simply saves the current plan to DB, if the current plan was never saved, the user
would be prompted to enter its title
Save As allows duplicating the plan, saving it with a different name
Open allows loading a pre-existing plan from DB.
Describe alternatives you've considered
It might be simpler from an implementation standpoint, to support saving/loading to a file(e.g JSON) which includes the current track and all courses taken within the plan.
Users could then manage those plans with standard filesystem tools (e.g, save them to cloud), or share them in various places.
Because these files are relatively small, we might even be able to share them via URL links, which might make them more accessible, e.g, a link that looks like https://uniclosure.me/import_plan?plan_json=.........
Upon opening this link, the user would be asked whether to override his current plan(the one in local-storage) or combine it.
Of course, placing the burden of managing these plans on the user is also a disadvantage, and doesn't make use of
our API. But it can also be implemented alongside the DB support, as an alternative way of saving/loading plans.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
A user might want to experiment with several different course plans without having to override them, in addition, he
might want to share his plan with other users, and have them "fork" his plan and modify it further.
Describe the solution you'd like
A solution based on database support:
On the backend side, this would require model changes, namely, the addition of a
Plan
model, and decoupling ofStudent
fromTake
, instead, aPlan
has manyTake
s, and a student has manyPlan
s.A plan can also have a field indicating whether it is publicly readable or private, and a name/description.
There would also need to be limits on the number of plans (and the number of courses within each plan) to
prevent abuse.
On the front-end side, there would be a menu under the navbar with various options:
Save
simply saves the current plan to DB, if the current plan was never saved, the userwould be prompted to enter its title
Save As
allows duplicating the plan, saving it with a different nameOpen
allows loading a pre-existing plan from DB.Describe alternatives you've considered
It might be simpler from an implementation standpoint, to support saving/loading to a file(e.g JSON) which includes the current track and all courses taken within the plan.
Users could then manage those plans with standard filesystem tools (e.g, save them to cloud), or share them in various places.
Because these files are relatively small, we might even be able to share them via URL links, which might make them more accessible, e.g, a link that looks like
https://uniclosure.me/import_plan?plan_json=.........
Upon opening this link, the user would be asked whether to override his current plan(the one in local-storage) or combine it.
Of course, placing the burden of managing these plans on the user is also a disadvantage, and doesn't make use of
our API. But it can also be implemented alongside the DB support, as an alternative way of saving/loading plans.
The text was updated successfully, but these errors were encountered: