Page MenuHomePhabricator

Clean up and improve course type implementation
Closed, DeclinedPublic

Description

Continue the process of encapsulating constants and functions relating to course type.

For example, app/assets/javascripts/components/course.cjsx compares a course.type against
'ClassroomProgramCourse', and references l10n strings courses.students_short and courses.editors, depending on course type.

We also might want to build a real feature on top of "course type", for example a library of templates for common types of course, available for cloning.

Event Timeline

awight created this task.Feb 4 2016, 8:17 AM
awight raised the priority of this task from to Needs Triage.
awight updated the task description. (Show Details)
awight added subscribers: Aklapper, Base, StudiesWorld and 2 others.
awight renamed this task from Course type should be a first-class object to Push everything about course types into their first-class encapsulation.EditedFeb 4 2016, 8:22 AM
awight updated the task description. (Show Details)
awight set Security to None.

Looks like this work is already well along. See app/models/classroom_program_course.rb

awight added a comment.Feb 4 2016, 8:47 PM

There should be a database table for course type, that we can query for a list of valid types.

In a later phase, we could provide an admin UI for creating new group types.

awight added a comment.Feb 4 2016, 9:06 PM

The Course base class should not have any knowledge of specific course types.

There should be a database table for course type, that we can query for a list of valid types.
In a later phase, we could provide an admin UI for creating new group types.

Interesting idea... I suppose we could have various modules defining different behaviors — different scopes for course.revisions and the other things specified currently via the ClassroomProgramCourse and other type models. Seems like a lot of UI and refactoring for a use case — arbitrary new course types — that we can probably get very far without.

awight added a comment.Feb 5 2016, 8:20 PM

Seems like a lot of UI and refactoring for a use case — arbitrary new course types — that we can probably get very far without.

I agree, we're best off with the absolute minimum of course types to start with--most of all, just the freeform "generic" type, which we can extend to be useful for all of the most common cases. Arbitrary types and course metadata would come much later if ever.

All I care about for the MVP is that we can add more properties to course type, and I imagine that can be done in the concrete subclasses with or without database backing.

awight renamed this task from Push everything about course types into their first-class encapsulation to [Epic] Clean up course type implementation.Feb 17 2016, 6:14 AM
awight triaged this task as Low priority.
awight added a project: Technical-Debt.
awight renamed this task from [Epic] Clean up course type implementation to [Epic] Clean up and improve course type implementation.Feb 17 2016, 6:18 AM
awight updated the task description. (Show Details)
awight lowered the priority of this task from Low to Lowest.Feb 27 2016, 6:35 AM
awight renamed this task from [Epic] Clean up and improve course type implementation to Clean up and improve course type implementation.Feb 27 2016, 6:51 AM
awight moved this task from Unsorted to Cleanup on the Technical-Debt board.Apr 21 2016, 8:45 PM
DStrine removed a subscriber: awight.Oct 31 2016, 2:16 PM
Ragesoss closed this task as Declined.Apr 23 2019, 10:20 PM

I think the Single Table Inheritance approach to course types has worked pretty well; looking back on this now, I don't think there's anything I'd want to majorly change.