"I was
hoping it would be possible to avoid copy-and-paste. Renderers should be state-less, and each method should have everything the need passed in as arguments."
Sorry but Cloze reality is an
hopeless case
.
The first constraint is that the short_answer, numerical and multichoice must be in-line with the question text whichs mean that for multichoice a select element is used.
Even if I used calls to the actual renderers with questiontext = '' the result will not be in-line because of the various <div> tags.
multichoice renderer part of the code of public function formulation_and_controls(question_attempt $qa,
question_display_options $options) {
$result = '';
$result .= $this->output_tag('div', array('class' => 'qtext'),
$question->format_questiontext());
$result .= $this->output_start_tag('div', array('class' => 'ablock'));
$result .= $this->output_tag('div', array('class' => 'prompt'),
get_string('selectone', 'qtype_multichoice'));
$result .= $this->output_start_tag('div', array('class' => 'answer'));
foreach ($radiobuttons as $key => $radio) {
$result .= $this->output_tag('span', array('class' => $classes[$key]),
$radio . $feedbackimg[$key] . $feedback[$key]) . "\n";
}
$result .= $this->output_end_tag('div'); // answer
$result .= $this->output_end_tag('div'); // ablock
Furthermore the feedback and good response are shown as a popup window when the mouse is over the input element.
As for horizontal multichoice, it is already offered in actual Cloze because it is usefull for yes, no, I don't know questions.
An almost complete quiz with many similar questions can be put easily in a table inside a single cloze question.
The horizontal/ vertical choice used the layout column of question_multichoice table.
I can however divide the different tasks ( grading, feedback, display) of multianswer formulation_and_controls function so as to refer to the specific qtype of each subquestion and create a specific multichoice select renderer.
A similar problem occurs with calculated with can be a numerical or a multichoice although simpler because the standard rendering can be used.
My first tests done on calculated in december only include the numerical version of calculated.
So we can also discuss the calculated case before the Cloze.
As there was a need to a simpler editing interface for a simpler calculated question using only private datasets, I create the calculated simple question type.
The question editor is simpler and the question rendering can use the numerical version of the calculated question type.
There was a need to a multichoice using datasets
- (i.e in a single question you can ask the student to choose the response for a circle area which offer a choice between the good one (pi*r2) and a common error (2pir))
so I build a more complex question editor that can edit either as a numerical question type or as a multichoice question type.
The calculated question editor allow (on 3 pages) all the possibility of datasets.
The choice between numerical or multichoice is done on the first page and cannot be changed after that in order to eliminate any problem when using the question in a quiz if the user could modify the question type later.
A better choice will be to create a new question type i.e. calculated multichoice but its appears more easy to do it this way given your concerns about the number of official question types
.
Also calculated simple question type is created mostly because the plug-in structure does not allow two question_edit_forms but this question type use most of the calculated code.
Having calculated simple , calculated (as numerical) and calculated multichoice question types mean the following:
- Calculated simple and calculated (as numerical) use mostly the numerical engine code as the calculated questiontype code.
- Calculated multichoice
- will simplify the calculated question_edit_forms,
- use the same datasetdefinition code
- use the calculated dataset code
- and mostly the multichoice (single or multiple) engine code.
- give to the user a clear indication of the question type.
These three question type versions will be the most easy to maintain on the long, long term as my interest in calculated question type goes back to the 1970 years and, although being 67 years old, my life expectancy is around 20 years
.
Pierre
.
