I would like to argue on the AJAX update after each click. Calculation of total grade is simple enough to be managed by JS. And if I were a teacher, I would change my mind several times during reading an assignment and would only like to submit the rubric when I filled it and sure about it.

Are we going to track historical changes made to grades? If yes, this AJAX will make the history unreadable

Something I would like to add:

• the number of points to be written for each cell
• add a column with total points assigned/maximum points for each row

Calculation of total grade is simple enough to be managed by JS

It can be for rubric. But other plugins can be more complicated and can even require huge data from the database or external sources etc. Plus, MD noticed one useful side effect of the proposed mechanism. In case of fallen browser in the middle of grading, the teacher would find the rubric like "autosaved" next time they came back.

Are we going to track historical changes made to grades?

If we ever implement revisions, surely we can tweak the log reader so that it is able to aggregate records.

the number of points to be written for each cell

Sure, good idea. Thanks!

add a column with total points assigned/maximum points for each row

Hm, that is not very common in rubric examples I have seen. What's that information good for?

Hi Marina,

I did a quick overview of your current work available at https://github.com/marinaglancy/moodle/compare/rubric...wip-MDL-29481-rubric

• firstly please note that the code does not seem to be based on the most recent version of the 'rubric' branch in my repository and you did some things in a different way than I did.
• I was hoping you would use https://github.com/mudrd8mz/moodle-gradingform_random as an example of how I see the grading plugin and its editor implemented. It is illustrated there how to get the content and optionally the course module if it is available. Note that your new manager's method get_cm() is unacceptable as it makes the grading areas available within activity modules only. And this is wrong as we will want to support creating the gradable area for an item in the gradebook (or a block etc), too. So the only thing you can rely is that the gradable area lies within some course context (which is what my code does). Also see how $cm can be obtained from the manager's context if it is available.
• the pattern

  if (! $course = $DB->get_record(...)) {
      print_error();
  }
  

  is very 1.9-ish. Why not using the nice MUST_EXIST flag?

• using $PAGE->requires->js() is not a good way of using JS in new code. This call was created for a legacy reasons mainly. All new DEV projects should use proper YUI module with no exception (always remember that we in DEV team show the way for other contributors on how the ideal code for Moodle should look like. Half-baked solutions are not a good sign, even if they work). Again, look at the gradingmethod_random for an example.

Implemented without AJAX yet