Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Matching question type: Difference between revisions

From MoodleDocs
(→‎Response storage: now using 'code' field)
Line 37: Line 37:
==Response storage==
==Response storage==


The matching questiontype needs to store information about the order of its subquestions and the selected responses. Because each subquestion is identified by one record in the quiz_match_sub table, the ids of this table are used to identify both the question and the response part. For each subquestion a '-'-separated pair is created, giving first the id of the record that provided the subquestion and then the id of the record that provided the selected response. E.g. 1-3 means that the answer of the third question was selected for the first subquestion. Correct responses are always pairs of identical ids, e.g 2-2. If no response is selected, the second id in the pair is set to '0'. These pairs are then put into a comma separated list to allow each subquestion to store a response.
The matching questiontype needs to store information about the order of its subquestions and the selected responses. Because each subquestion is identified by one record in the quiz_match_sub table, the ids of this table could be used to identify both the question and the response part. This is indeed how it was done until Moodle 1.5. This however had the drawback that students who looked at the page source could figure out which answer belonged to which question. Since Moodle 1.6 the response part is encoded with respect to the new 'code' field in the quiz_match_sub table. The entry in the 'code' field is randomly created with rand() when a subquestion is created.
 
For each subquestion a '-'-separated pair is created, giving first the id of the record that provided the subquestion and then the code of the record that provided the selected response. E.g. 1-3 means that the answer of the third question was selected for the first subquestion. If no response is selected, the second entry in the pair is set to '0'. These pairs are then put into a comma separated list to allow each subquestion to store a response.


==Question options object==
==Question options object==

Revision as of 15:45, 13 February 2006

Database tables

quiz_match

This table is only used in the code for saving matching questions and can therefore be considered redundant.

id
int(10) unsigned NOT NULL auto_increment,

Primary key

question
int(10) unsigned NOT NULL default '0',
Foreign key to the id field in the quiz_questions table
subquestions
varchar(255) NOT NULL default ,

quiz_match_sub

The quiz_match_sub extends the quiz_questions table. It stores the pairs of questions and answers (as strings) that need to be matched for a correct solution.

id
int(10) unsigned NOT NULL auto_increment,
question
int(10) unsigned NOT NULL default '0',
Foreign key to the id field in the quiz_questions table
questiontext
text NOT NULL,
answertext
varchar(255) NOT NULL default ,

Response storage

The matching questiontype needs to store information about the order of its subquestions and the selected responses. Because each subquestion is identified by one record in the quiz_match_sub table, the ids of this table could be used to identify both the question and the response part. This is indeed how it was done until Moodle 1.5. This however had the drawback that students who looked at the page source could figure out which answer belonged to which question. Since Moodle 1.6 the response part is encoded with respect to the new 'code' field in the quiz_match_sub table. The entry in the 'code' field is randomly created with rand() when a subquestion is created.

For each subquestion a '-'-separated pair is created, giving first the id of the record that provided the subquestion and then the code of the record that provided the selected response. E.g. 1-3 means that the answer of the third question was selected for the first subquestion. If no response is selected, the second entry in the pair is set to '0'. These pairs are then put into a comma separated list to allow each subquestion to store a response.

Question options object

The $questions->options object has the properties

subquestions
an array of all the records from the quiz_match_sub table for this question, i.e., all the question-answer pairs, indexed by the ids.
shuffleanswers
a flag that indicates whether the answers should be shuffled, provided this is enabled at the quiz level.

State options object

The $state->options object has a single property 'subquestions' which holds an array of objects representing the question-answer pairs, indexed by the ids. Each entry from the table is an object with the following properties:

id
question
questiontext
answertext
options

The options property in turn is an object with a single property answers which is an array of objects with the following properties:

id
the id of this subquestion
answer
the answertext for this subquestion
fraction
this is always set to 1 and has the effect that all subquestions carry the same weight.

The reason this is done in such a complicated manner is that it makes it easier to reuse the code for the matching question type also for the random short-answer questiontype.