Closed christianp closed 1 year ago
I don't think this can completely replace the built-in getCorrectAnswer
method, because there are lots of parts with custom marking algorithms that don't extend the base script, and they would break if this note was suddenly required.
So the note should just override getCorrectAnswer
if it's present.
Another wrinkle: getCorrectAnswer
often sets other keys in the settings
object.
So I think each part type has to check for the expected_answer
note in getCorrectAnswer
, rather than having some generic logic in the base Part
type.
Actually, having looked at the other part types, I think you'd only need to do this for number entry parts anyway. I think it'd be better to add a "display answer" setting to the number entry part, like the one for patternmatch.
At the moment, the expected answer for the built-in part types is produced using some built-in JavaScript.
I've just written a question using a number entry part which allows "nan" for "not a number". The built-in expected answer is shown as "0", which is incorrect. In general, I could have allowed all sorts of different strings, so I should be able to say what the expected answer is. The marking algorithm is a natural place to do this.
So there should be a note called
expected_answer
which produces a value of the same type as what ends up instudentAnswer
.