question_type::save_question_answers function added, supporting
saving answers and extra answer fields. It can be called from
save_question_options function for the questions, using
question_answers table. Special functions created for overloading
so that every question could tune it to it's own form.
Shortanswer qtype save_question_options() converted as a proof of
concept and for testing purposes.
Extra answer data may be optional, saving DB space - i.e. not every row in
question_answers will have respective row in extra answers table. Current
implementation of question_type::get_question_options() won't return such
answers at all. This commit fix that, changing join type for db query.
Also fixed coding style violation in the variable name in get_question_options.
This adds 3 new methods, called from question_type::save_hints,
to make it easier for different question types to overload this
functionality without duplicating code.
Question types that will benefit from this change include
oumultiresponse, ddmarker, preg and correctwriting.
The files that belong to the question hints are neither moved when the
question is moved to another context, nor deleted when the question is
deleted.
Oops! How come no one noticed that until today.
Conflicts:
question/type/upgrade.txt
There were already one just added upgrade.txt file so this ended
conflicting. Reviewed the contents, I've deleted the less detailed
note about pluginname, leaving the longer description added by Tim.
Ciao :-)
The (partially|in)?correct feedback fields acutally store their files in a file area with component 'question'. Some code, however, was written as if they were stored in the qtype_whatever area.
From OU bug #921 "Order of answer fields in Variable numeric keeps changing" Cannot
reproduce this bug on my system but hopefully this will fix the problem. I added
an ORDER BY clause to the sql for fetching answers with extra answer fields.
The most significant issue is that the HTML editor alwasy wraps <p> tags round the input, but that is not appropriate for the choices. It is especially not appropriate because we want to display the choices in a <lable> for accessibility and usability reasons. In valid HTML label can only contain inline elemnts. Therefore, I introduced a make_html_inline method, with a minimal implementation. (It could be improved in future.)
Long term, I think the best option would be a new form field type, editorinline, or something like that. That would be a smaller version of TinyMCE that only lets you enter inline elements.
Tim Hunt