It was always a bit of a hack to use static methods on the
qbehaviour_whatever classes to return metadata about the behaviour. It
is better design to have real qbehaviour_whatever_type classes to report
that metadata, particularly now that we are planning to add more such.
For example, inheritance works better with real classes. See, for
example, the improvements in
question_engine::get_behaviour_unused_display_options().
This change has been implemented in a backwards-compatbile way. Old
behaviours will continue to work. There will just be some developer debug
output to prompt people to upgrade their code properly.
Comment format (FORMAT_...) was correctly being processed when the
manual grading happened as the result of a form submission. It was only
when done using the question_usage or question_attempt API method that
there was no way to specify the format. (Although I think the only place
this API as used was in the unit tests.)
Note that question_attempt::manual_grade API had to change, but I don't
think that is a real API change. Calling code should be using
question_usage::question_attempt, which is backwards compatible.
Note that now, if you don't pass format, then no error is generated, but
a developer debugging message is generated.
These changes move the logic to the behaviour class, which is how things
should be.
It also makes it easier to re-use the code that displays the messages
like "Marks for this submission: 1.00/1.00. Accounting for previous
tries, this gives 0.33/1.00." in other places.
To try to make it clearer what is going on, I introduced a new class
qbehaviour_adaptive_mark_details to hold and document the data that the
behaviour needs to return, and the renderer can base its display on.
As far as my testing can tell (and there are new unit tests), this
commit does not change the existing behaviour.
This commit also replaces all the string concatenation that is going on,
which should help translators. At the moment, a few of the old strings
are still in the language file, and are used in the unit tests to verify
that the behaviour has not changed.
Thanks to Oleg Sychev for making a helpful suggestion about the API.
1/ type/match/tests/walkthrough_test.php - tests are failing randomly, looks like some weird randomisation is going on there - see TODOs
2/ type/multianswer/tests/upgradelibnewqe_test.php contains invalid expected value - see TODO
Eloy Lafuente (stronk7)