|
In revision 22061, I checked in a mechanism for switching UI beans via sakai.properties, along with a sample "course grades to spreadsheet" converter which contacts the Course Management API and tries to make the Registrar happy.
Right now it requires quite a bit of manual intervention to test, so about all you'll be able to check on nightly is that the default behavior hasn't been broken. I can rig up a special test DB and deployment for demonstrations. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Here's the goal:
* Some swappable mechanism for intercepting course grade spreadsheet downloads after the enrollments and course grade records have been filtered and before the spreadsheet file itself is built. (We're partway there due to the changes made for
SAK-7712.)* As a proof-of-concept / sample / test that just happens to match UC Berkeley requirements, provide an alternative plug-in interceptor that takes input A-F letter grades, goes to the Course Management API to see what grading scale the student is supposed to be graded against (e.g., "A-F", "P/NP", "S/U"), translates the input grades to the desired grades as needed, and adds an extra column to the spreadsheet to hold the original A-F letter grade alongside the column with the official final grade.
Here's my current development plan:
1) Figure out what the alternative plug-in needs from the Course Management API, and make sure I can get it into the test data. (This will let me set up testing. Without it, we'll have no way of being sure that the new code works.)
2) The current Course Grade backing bean has a method that converts domain data (enrollments and course grade records) into generic spreadsheet-style data (a list of rows of columns). Extract that method into a configurable interface and figure out how to inject it into the application with minimal fuss.
3) Write a second implementation of that interface to do our proof-of-concept task.
4) Document it!