Question Engine 2:Design - Revision history

Mudrd8mz: Text replacement - "" to ""

2021-07-14T20:19:39Z

Text replacement - "</code>" to "</syntaxhighlight>"

← Older revision		Revision as of 20:19, 14 July 2021
Line 229:		Line 229:
	$this->assertPattern('/' . preg_quote('Not good enough!') . '/', $html);		$this->assertPattern('/' . preg_quote('Not good enough!') . '/', $html);
	}		}
	</~~code~~>		</syntaxhighlight>

	Note that this code does not interact with the database at all. Data is only stored to or loaded from the database if you call $qag->load_... or $qag_save... methods.		Note that this code does not interact with the database at all. Data is only stored to or loaded from the database if you call $qag->load_... or $qag_save... methods.
Line 267:		Line 267:
	// ...		// ...
	}		}
	</~~code~~>		</syntaxhighlight>


Line 281:		Line 281:
	// ...		// ...
	}		}
	</~~code~~>		</syntaxhighlight>


Line 326:		Line 326:
	// Do something with each step of the question attempt in order.		// Do something with each step of the question attempt in order.
	}		}
	</~~code~~>		</syntaxhighlight>

Mudrd8mz: Text replacement - "`" to ""`


2021-07-14T13:33:43Z
Text replacement - "<code php>" to "<syntaxhighlight lang="php">"

				
				
				
				
				
				← Older revision
				Revision as of 13:33, 14 July 2021
				
Line 156:
Line 156:
Here is some proposed code from an integration test method. It creates an attempt containing one true/false question and walks through a student getting it right, and then at teacher overriding the grade. Here is some proposed code from an integration test method. It creates an attempt containing one true/false question and walks through a student getting it right, and then at teacher overriding the grade.



<code php> <syntaxhighlight lang="php">
     public function test_delayed_feedback_truefalse() {      public function test_delayed_feedback_truefalse() {
         // Create a true-false question with correct answer true.          // Create a true-false question with correct answer true.
Line 245:
Line 245:
An enumeration that defines constants the various states a question can be in, with some helper methods: An enumeration that defines constants the various states a question can be in, with some helper methods:



<code php> <syntaxhighlight lang="php">
abstract class question_state { abstract class question_state {
     const NOT_STARTED = -1;      const NOT_STARTED = -1;
Line 274:
Line 274:
This class contains all the options for what may, or may not, be visible when a question is rendered. This class contains all the options for what may, or may not, be visible when a question is rendered.



<code php> <syntaxhighlight lang="php">
class question_display_options { class question_display_options {
     public $flags = QUESTION_FLAGSSHOWN;      public $flags = QUESTION_FLAGSSHOWN;
Line 322:
Line 322:



There are two helper classes question_attempt_step_iterator and question_attempt_reverse_step_iterator which let you write code like There are two helper classes question_attempt_step_iterator and question_attempt_reverse_step_iterator which let you write code like
<code php> <syntaxhighlight lang="php">
foreach ($qa->get_iterator() as $stepindex => $step) { foreach ($qa->get_iterator() as $stepindex => $step) {
     // Do something with each step of the question attempt in order.      // Do something with each step of the question attempt in order.



Mudrd8mz: Text replacement - "class="nicetable"" to "class="wikitable""
2021-07-14T13:22:09Z
Text replacement - "class="nicetable"" to "class="wikitable""

				
				
				
				
				
				← Older revision
				Revision as of 13:22, 14 July 2021
				
Line 31:
Line 31:
This is a rename of question_attempts. This is a rename of question_attempts.



{| class="nicetable" {| class="wikitable"
! Column !! Type !! Comment ! Column !! Type !! Comment
|- |-
Line 49:
Line 49:
There is now no requirement for (attemptid, questionid) to be unique. There is now no requirement for (attemptid, questionid) to be unique.



{| class="nicetable" {| class="wikitable"
! Column !! Type !! Comment ! Column !! Type !! Comment
|- |-
Line 83:
Line 83:
Same purpose as the old question_states table, but simplified. Same purpose as the old question_states table, but simplified.



{| class="nicetable" {| class="wikitable"
! Column !! Type !! Comment ! Column !! Type !! Comment
|- |-
Line 111:
Line 111:
Note that, the old question_states.answer field used to save a lot of repetitive information from one state to the next, for example the other questionid for random questions, and the choices order for multiple-choice questions with shuffle-answers on. In future, this sort of repetitive information will not be saved. Instead, during question processing, the question types will be given access to the full state history. Note that, the old question_states.answer field used to save a lot of repetitive information from one state to the next, for example the other questionid for random questions, and the choices order for multiple-choice questions with shuffle-answers on. In future, this sort of repetitive information will not be saved. Instead, during question processing, the question types will be given access to the full state history.



{| class="nicetable" {| class="wikitable"
! Column !! Type !! Comment ! Column !! Type !! Comment
|- |-



Jagob: /* Words related to grades */
2011-05-25T12:11:55Z
Words related to grades

				
				
				
				
				
				← Older revision
				Revision as of 12:11, 25 May 2011
				
Line 19:
Line 19:
Therefore, we have the three words fraction, mark and grade that should be used consistently throughout the question engine code. Fractions are rarely shown in the user interface*, while I believe the quiz UI already uses the marks/grades terminology consistently. Therefore, we have the three words fraction, mark and grade that should be used consistently throughout the question engine code. Fractions are rarely shown in the user interface*, while I believe the quiz UI already uses the marks/grades terminology consistently.



When used as a verb - to assign a grade/mark/fraction - as in grade_response, regrade or manual_grade, the work grade is always used. When used as a verb - to assign a grade/mark/fraction - as in grade_response, regrade or manual_grade, the word grade is always used.



<nowiki>*</nowiki> the one place where fraction is displayed in the UI is on the question editing screens, where you set the 'grade' for a particular answer on a scale of 0 to 100%. <nowiki>*</nowiki> the one place where fraction is displayed in the UI is on the question editing screens, where you set the 'grade' for a particular answer on a scale of 0 to 100%.



TimHunt: /* question_attempts */
2010-07-03T16:26:42Z
question_attempts

				
				
				
				
				
				← Older revision
				Revision as of 16:26, 3 July 2010
				
Line 56:
Line 56:
| questionusageid || INT(10) NOT NULL REFERENCES question_usages.id || Which attempt this data belongs to. | questionusageid || INT(10) NOT NULL REFERENCES question_usages.id || Which attempt this data belongs to.
|- |-
| numberinusage || INT(10) NOT NULL || As questions are added to a usage, they are numbered sequentially. | slot || INT(10) NOT NULL || As questions are added to a usage, they are numbered sequentially.
|- |-
| behaviour || VARCHAR(32) NOT NULL || The question behaviour that is managing this question attempt. | behaviour || VARCHAR(32) NOT NULL || The question behaviour that is managing this question attempt.





TimHunt at 17:03, 26 April 2010
2010-04-26T17:03:06Z


				
				
				
				
				
				← Older revision
				Revision as of 17:03, 26 April 2010
				
Line 40:
Line 40:
| owningplugin || NOT NULL VARCHAR(255) || The plugin this attempt belongs to, e.g. 'mod_quiz', 'block_questionoftheday', 'filter_embedquestion'. | owningplugin || NOT NULL VARCHAR(255) || The plugin this attempt belongs to, e.g. 'mod_quiz', 'block_questionoftheday', 'filter_embedquestion'.
|- |-
| preferredmodel|| NOT NULL VARCHAR(255) || The the archetypal interaction model that should be used for new questions added to this usage. | preferredbehaviour || NOT NULL VARCHAR(255) || The the archetypal behaviour that should be used for new questions added to this usage.
|} |}



Line 58:
Line 58:
| numberinusage || INT(10) NOT NULL || As questions are added to a usage, they are numbered sequentially. | numberinusage || INT(10) NOT NULL || As questions are added to a usage, they are numbered sequentially.
|- |-
| interactionmodel || VARCHAR(32) NOT NULL || The question interaction model that is managing this question attempt. | behaviour || VARCHAR(32) NOT NULL || The question behaviour that is managing this question attempt.
|- |-
| questionid || INT(10) NOT NULL REFERENCES question.id || Which question this is the attempt data for. | questionid || INT(10) NOT NULL REFERENCES question.id || Which question this is the attempt data for.
Line 107:
Line 107:
This stores the data submitted by the student (a list of name => value pairs) that lead to the state stateid. This replaces the old question_states.answer field. This stores the data submitted by the student (a list of name => value pairs) that lead to the state stateid. This replaces the old question_states.answer field.



There will be a convention that ordinary names like 'myvariable' should be used for submitted data belonging to the question type; names prefixed with a !, like '!myaction' should be used for data belonging to the question interaction model; and names prefixed with a _ can be used for internal things, for example, the random question might store '_realquestionid' attached to the 'open' state, or a question type that does a lot of expensive processing might store a '_cachedresult' value, so the expensive calculation does not need to be repeated when reviewing the attempt. There will be a convention that ordinary names like 'myvariable' should be used for submitted data belonging to the question type; names prefixed with a :, like ':myaction' should be used for data belonging to the question behaviour; and names prefixed with a _ can be used for internal things, for example, the random question might store '_realquestionid' attached to the 'open' state, or a question type that does a lot of expensive processing might store a '_cachedresult' value, so the expensive calculation does not need to be repeated when reviewing the attempt.



Note that, the old question_states.answer field used to save a lot of repetitive information from one state to the next, for example the other questionid for random questions, and the choices order for multiple-choice questions with shuffle-answers on. In future, this sort of repetitive information will not be saved. Instead, during question processing, the question types will be given access to the full state history. Note that, the old question_states.answer field used to save a lot of repetitive information from one state to the next, for example the other questionid for random questions, and the choices order for multiple-choice questions with shuffle-answers on. In future, this sort of repetitive information will not be saved. Instead, during question processing, the question types will be given access to the full state history.
Line 165:
Line 165:
         $tf->maxgrade = 2;          $tf->maxgrade = 2;
         $quba = question_engine::make_questions_usage_by_activity('unit_test');          $quba = question_engine::make_questions_usage_by_activity('unit_test');
         $quba->set_preferred_interaction_model('delayedfeedback');          $quba->set_preferred_behaviour('delayedfeedback');
         $qnumber = $quba->add_question($tf);          $qnumber = $quba->add_question($tf);
         // Different from $tf->id since the same question may be used twice in          // Different from $tf->id since the same question may be used twice in
Line 329:
Line 329:






===question_interaction_model=== ===question_behaviour===



Will have subclasses like Will have subclasses like
* question_delayedfeedback_model * qbehaviour_delayedfeedback
* question_interactive_model * qbehaviour_interactive
* ... * ...



Question interaction models control exactly what happens when as a question_attempt is started, a submission is processed, or finished, etc. Question behaviours control exactly what happens when as a question_attempt is started, a submission is processed, or finished, etc.






===core_question_renderer=== ===core_question_renderer===



Renderers are responsible for generating the HTML to display a question in a particular state. The core_question_renderer it responsible for all the bits that do not depend on the current question type or interaction model. Renderers are responsible for generating the HTML to display a question in a particular state. The core_question_renderer it responsible for all the bits that do not depend on the current question type or behaviour.






Line 354:
Line 354:






===qim_renderer=== ===qbehaviour_renderer===



Base class for Base class for
* qim_delayedfeedback_renderer * qbehaviour_delayedfeedback_renderer
* qim_interactive_renderer * qbehaviour _interactive_renderer
* ... * ...



Responsible for generating the bits of HTML that depend on the interaction model. For example the submit button in adaptive mode. Responsible for generating the bits of HTML that depend on the behaviour. For example the submit button in adaptive mode.



==Changes to the question type API== ==Changes to the question type API==
Line 370:
Line 370:
==Proposed robustness and performance testing system== ==Proposed robustness and performance testing system==



A major change to the question engine should really only be contemplated in combination with the introduction of a test harness that makes it easy to run correctness, performance and reliablitity tests. A major change to the question engine should really only be contemplated in combination with the introduction of a test harness that makes it easy to run correctness, performance and reliability tests.



One adavntage of the way data will be stored in the new system is that everything originally submitted by the user will be stored in the database in a format very close to the one in which it was originally received by the web server. Therefore, it should be easy to write a script that replays saved quiz attempts. This is the basis of a test harness. I will create such a test script as part of this work. One advantage of the way data will be stored in the new system is that everything originally submitted by the user will be stored in the database in a format very close to the one in which it was originally received by the web server. Therefore, it should be easy to write a script that replays saved quiz attempts. This is the basis of a test harness. I will create such a test script as part of this work.



==Huge class diagram== ==Huge class diagram==



TimHunt at 19:26, 26 February 2010
2010-02-26T19:26:47Z


				
				
				
				
				
				← Older revision
				Revision as of 19:26, 26 February 2010
				
Line 382:
Line 382:
==See also== ==See also==



In the next section, [[Developing a Question Interaction Model|Developing a Question Interaction Model]] I describe what a developer will need to do to create a Question Interaction Model plugin for the new system. In the next section, [[Overview_of_the_Moodle_question_engine|Overview_of_the_Moodle_question_engine]] summarises the new system. It is intended to be the developer documentation for the new system once it is finished.



* Back to [[Question_Engine_2|Question Engine 2]] * Back to [[Question_Engine_2|Question Engine 2]]



TimHunt at 10:12, 8 December 2009
2009-12-08T10:12:00Z


				
				
				
				
				
				← Older revision
				Revision as of 10:12, 8 December 2009
				
Line 1:
Line 1:
{{Template:Question_engine_2}}
This page explains how I think the question engine should work in Moodle 2.0 or 2.1. This page explains how I think the question engine should work in Moodle 2.0 or 2.1.



Line 384:
Line 385:



* Back to [[Question_Engine_2|Question Engine 2]] * Back to [[Question_Engine_2|Question Engine 2]]

{{CategoryDeveloper}} 
[[Category:Quiz]] 



TimHunt: /* Proposed robustness and performance testing system */
2009-11-27T17:02:27Z
Proposed robustness and performance testing system

				
				
				
				
				
				← Older revision
				Revision as of 17:02, 27 November 2009
				
Line 373:
Line 373:
One adavntage of the way data will be stored in the new system is that everything originally submitted by the user will be stored in the database in a format very close to the one in which it was originally received by the web server. Therefore, it should be easy to write a script that replays saved quiz attempts. This is the basis of a test harness. I will create such a test script as part of this work. One adavntage of the way data will be stored in the new system is that everything originally submitted by the user will be stored in the database in a format very close to the one in which it was originally received by the web server. Therefore, it should be easy to write a script that replays saved quiz attempts. This is the basis of a test harness. I will create such a test script as part of this work.



==Huge class diagram==

This diagram shows all the classes in the question code (no including specific plugins), with most of the core of my new proposal implemented.

[[Image:Question_classes.png]]



==See also== ==See also==



TimHunt at 11:30, 25 November 2009
2009-11-25T11:30:58Z


				
				
				
				
				
				← Older revision
				Revision as of 11:30, 25 November 2009
				
Line 376:
Line 376:
==See also== ==See also==



In the next section, [[Question Engine 2:Implementation plan|Implementation plan]] outlines how I will implement this. In the next section, [[Developing a Question Interaction Model|Developing a Question Interaction Model]] I describe what a developer will need to do to create a Question Interaction Model plugin for the new system.



* Back to [[Question_Engine_2|Question Engine 2]] * Back to [[Question_Engine_2|Question Engine 2]]

← Older revision		Revision as of 13:33, 14 July 2021
Line 156:		Line 156:
	Here is some proposed code from an integration test method. It creates an attempt containing one true/false question and walks through a student getting it right, and then at teacher overriding the grade.		Here is some proposed code from an integration test method. It creates an attempt containing one true/false question and walks through a student getting it right, and then at teacher overriding the grade.

	<~~code~~ php>		<syntaxhighlight lang="php">
	public function test_delayed_feedback_truefalse() {		public function test_delayed_feedback_truefalse() {
	// Create a true-false question with correct answer true.		// Create a true-false question with correct answer true.
Line 245:		Line 245:
	An enumeration that defines constants the various states a question can be in, with some helper methods:		An enumeration that defines constants the various states a question can be in, with some helper methods:

	<~~code~~ php>		<syntaxhighlight lang="php">
	abstract class question_state {		abstract class question_state {
	const NOT_STARTED = -1;		const NOT_STARTED = -1;
Line 274:		Line 274:
	This class contains all the options for what may, or may not, be visible when a question is rendered.		This class contains all the options for what may, or may not, be visible when a question is rendered.

	<~~code~~ php>		<syntaxhighlight lang="php">
	class question_display_options {		class question_display_options {
	public $flags = QUESTION_FLAGSSHOWN;		public $flags = QUESTION_FLAGSSHOWN;
Line 322:		Line 322:

	There are two helper classes question_attempt_step_iterator and question_attempt_reverse_step_iterator which let you write code like		There are two helper classes question_attempt_step_iterator and question_attempt_reverse_step_iterator which let you write code like
	<~~code~~ php>		<syntaxhighlight lang="php">
	foreach ($qa->get_iterator() as $stepindex => $step) {		foreach ($qa->get_iterator() as $stepindex => $step) {
	// Do something with each step of the question attempt in order.		// Do something with each step of the question attempt in order.

← Older revision		Revision as of 13:22, 14 July 2021
Line 31:		Line 31:
	This is a rename of question_attempts.		This is a rename of question_attempts.

	{\| class="~~nicetable~~"		{\| class="wikitable"
	! Column !! Type !! Comment		! Column !! Type !! Comment
	\|-		\|-
Line 49:		Line 49:
	There is now no requirement for (attemptid, questionid) to be unique.		There is now no requirement for (attemptid, questionid) to be unique.

	{\| class="~~nicetable~~"		{\| class="wikitable"
	! Column !! Type !! Comment		! Column !! Type !! Comment
	\|-		\|-
Line 83:		Line 83:
	Same purpose as the old question_states table, but simplified.		Same purpose as the old question_states table, but simplified.

	{\| class="~~nicetable~~"		{\| class="wikitable"
	! Column !! Type !! Comment		! Column !! Type !! Comment
	\|-		\|-
Line 111:		Line 111:
	Note that, the old question_states.answer field used to save a lot of repetitive information from one state to the next, for example the other questionid for random questions, and the choices order for multiple-choice questions with shuffle-answers on. In future, this sort of repetitive information will not be saved. Instead, during question processing, the question types will be given access to the full state history.		Note that, the old question_states.answer field used to save a lot of repetitive information from one state to the next, for example the other questionid for random questions, and the choices order for multiple-choice questions with shuffle-answers on. In future, this sort of repetitive information will not be saved. Instead, during question processing, the question types will be given access to the full state history.

	{\| class="~~nicetable~~"		{\| class="wikitable"
	! Column !! Type !! Comment		! Column !! Type !! Comment
	\|-		\|-

← Older revision		Revision as of 12:11, 25 May 2011
Line 19:		Line 19:
	Therefore, we have the three words fraction, mark and grade that should be used consistently throughout the question engine code. Fractions are rarely shown in the user interface*, while I believe the quiz UI already uses the marks/grades terminology consistently.		Therefore, we have the three words fraction, mark and grade that should be used consistently throughout the question engine code. Fractions are rarely shown in the user interface*, while I believe the quiz UI already uses the marks/grades terminology consistently.

	When used as a verb - to assign a grade/mark/fraction - as in grade_response, regrade or manual_grade, the ~~work~~ grade is always used.		When used as a verb - to assign a grade/mark/fraction - as in grade_response, regrade or manual_grade, the word grade is always used.

	<nowiki>*</nowiki> the one place where fraction is displayed in the UI is on the question editing screens, where you set the 'grade' for a particular answer on a scale of 0 to 100%.		<nowiki>*</nowiki> the one place where fraction is displayed in the UI is on the question editing screens, where you set the 'grade' for a particular answer on a scale of 0 to 100%.

← Older revision		Revision as of 16:26, 3 July 2010
Line 56:		Line 56:
	\| questionusageid \|\| INT(10) NOT NULL REFERENCES question_usages.id \|\| Which attempt this data belongs to.		\| questionusageid \|\| INT(10) NOT NULL REFERENCES question_usages.id \|\| Which attempt this data belongs to.
	\|-		\|-
	\| ~~numberinusage~~ \|\| INT(10) NOT NULL \|\| As questions are added to a usage, they are numbered sequentially.		\| slot \|\| INT(10) NOT NULL \|\| As questions are added to a usage, they are numbered sequentially.
	\|-		\|-
	\| behaviour \|\| VARCHAR(32) NOT NULL \|\| The question behaviour that is managing this question attempt.		\| behaviour \|\| VARCHAR(32) NOT NULL \|\| The question behaviour that is managing this question attempt.

← Older revision		Revision as of 17:03, 26 April 2010
Line 40:		Line 40:
	\| owningplugin \|\| NOT NULL VARCHAR(255) \|\| The plugin this attempt belongs to, e.g. 'mod_quiz', 'block_questionoftheday', 'filter_embedquestion'.		\| owningplugin \|\| NOT NULL VARCHAR(255) \|\| The plugin this attempt belongs to, e.g. 'mod_quiz', 'block_questionoftheday', 'filter_embedquestion'.
	\|-		\|-
	\| ~~preferredmodel~~\|\| NOT NULL VARCHAR(255) \|\| The the archetypal ~~interaction model~~ that should be used for new questions added to this usage.		\| preferredbehaviour \|\| NOT NULL VARCHAR(255) \|\| The the archetypal behaviour that should be used for new questions added to this usage.
	\|}		\|}

Line 58:		Line 58:
	\| numberinusage \|\| INT(10) NOT NULL \|\| As questions are added to a usage, they are numbered sequentially.		\| numberinusage \|\| INT(10) NOT NULL \|\| As questions are added to a usage, they are numbered sequentially.
	\|-		\|-
	\| ~~interactionmodel~~ \|\| VARCHAR(32) NOT NULL \|\| The question ~~interaction model~~ that is managing this question attempt.		\| behaviour \|\| VARCHAR(32) NOT NULL \|\| The question behaviour that is managing this question attempt.
	\|-		\|-
	\| questionid \|\| INT(10) NOT NULL REFERENCES question.id \|\| Which question this is the attempt data for.		\| questionid \|\| INT(10) NOT NULL REFERENCES question.id \|\| Which question this is the attempt data for.
Line 107:		Line 107:
	This stores the data submitted by the student (a list of name => value pairs) that lead to the state stateid. This replaces the old question_states.answer field.		This stores the data submitted by the student (a list of name => value pairs) that lead to the state stateid. This replaces the old question_states.answer field.

	There will be a convention that ordinary names like 'myvariable' should be used for submitted data belonging to the question type; names prefixed with a !, like '!myaction' should be used for data belonging to the question ~~interaction model~~; and names prefixed with a _ can be used for internal things, for example, the random question might store '_realquestionid' attached to the 'open' state, or a question type that does a lot of expensive processing might store a '_cachedresult' value, so the expensive calculation does not need to be repeated when reviewing the attempt.		There will be a convention that ordinary names like 'myvariable' should be used for submitted data belonging to the question type; names prefixed with a :, like ':myaction' should be used for data belonging to the question behaviour; and names prefixed with a _ can be used for internal things, for example, the random question might store '_realquestionid' attached to the 'open' state, or a question type that does a lot of expensive processing might store a '_cachedresult' value, so the expensive calculation does not need to be repeated when reviewing the attempt.

	Note that, the old question_states.answer field used to save a lot of repetitive information from one state to the next, for example the other questionid for random questions, and the choices order for multiple-choice questions with shuffle-answers on. In future, this sort of repetitive information will not be saved. Instead, during question processing, the question types will be given access to the full state history.		Note that, the old question_states.answer field used to save a lot of repetitive information from one state to the next, for example the other questionid for random questions, and the choices order for multiple-choice questions with shuffle-answers on. In future, this sort of repetitive information will not be saved. Instead, during question processing, the question types will be given access to the full state history.
Line 165:		Line 165:
	$tf->maxgrade = 2;		$tf->maxgrade = 2;
	$quba = question_engine::make_questions_usage_by_activity('unit_test');		$quba = question_engine::make_questions_usage_by_activity('unit_test');
	$quba->~~set_preferred_interaction_model~~('delayedfeedback');		$quba->set_preferred_behaviour('delayedfeedback');
	$qnumber = $quba->add_question($tf);		$qnumber = $quba->add_question($tf);
	// Different from $tf->id since the same question may be used twice in		// Different from $tf->id since the same question may be used twice in
Line 329:		Line 329:


	===~~question_interaction_model~~===		===question_behaviour===

	Will have subclasses like		Will have subclasses like
	* ~~question_delayedfeedback_model~~		* qbehaviour_delayedfeedback
	* ~~question_interactive_model~~		* qbehaviour_interactive
	* ...		* ...

	Question ~~interaction models~~ control exactly what happens when as a question_attempt is started, a submission is processed, or finished, etc.		Question behaviours control exactly what happens when as a question_attempt is started, a submission is processed, or finished, etc.


	===core_question_renderer===		===core_question_renderer===

	Renderers are responsible for generating the HTML to display a question in a particular state. The core_question_renderer it responsible for all the bits that do not depend on the current question type or ~~interaction model~~.		Renderers are responsible for generating the HTML to display a question in a particular state. The core_question_renderer it responsible for all the bits that do not depend on the current question type or behaviour.


Line 354:		Line 354:


	===~~qim_renderer~~===		===qbehaviour_renderer===

	Base class for		Base class for
	* ~~qim_delayedfeedback_renderer~~		* qbehaviour_delayedfeedback_renderer
	* ~~qim_interactive_renderer~~		* qbehaviour _interactive_renderer
	* ...		* ...

	Responsible for generating the bits of HTML that depend on the ~~interaction model~~. For example the submit button in adaptive mode.		Responsible for generating the bits of HTML that depend on the behaviour. For example the submit button in adaptive mode.

	==Changes to the question type API==		==Changes to the question type API==
Line 370:		Line 370:
	==Proposed robustness and performance testing system==		==Proposed robustness and performance testing system==

	A major change to the question engine should really only be contemplated in combination with the introduction of a test harness that makes it easy to run correctness, performance and ~~reliablitity~~ tests.		A major change to the question engine should really only be contemplated in combination with the introduction of a test harness that makes it easy to run correctness, performance and reliability tests.

	One ~~adavntage~~ of the way data will be stored in the new system is that everything originally submitted by the user will be stored in the database in a format very close to the one in which it was originally received by the web server. Therefore, it should be easy to write a script that replays saved quiz attempts. This is the basis of a test harness. I will create such a test script as part of this work.		One advantage of the way data will be stored in the new system is that everything originally submitted by the user will be stored in the database in a format very close to the one in which it was originally received by the web server. Therefore, it should be easy to write a script that replays saved quiz attempts. This is the basis of a test harness. I will create such a test script as part of this work.

	==Huge class diagram==		==Huge class diagram==

← Older revision		Revision as of 19:26, 26 February 2010
Line 382:		Line 382:
	==See also==		==See also==

	In the next section, [[~~Developing a Question Interaction Model~~\|~~Developing a Question Interaction Model~~]] ~~I describe what a~~ developer ~~will need to do to create a Question Interaction Model plugin~~ for the new system.		In the next section, [[Overview_of_the_Moodle_question_engine\|Overview_of_the_Moodle_question_engine]] summarises the new system. It is intended to be the developer documentation for the new system once it is finished.

	* Back to [[Question_Engine_2\|Question Engine 2]]		* Back to [[Question_Engine_2\|Question Engine 2]]

← Older revision		Revision as of 10:12, 8 December 2009
Line 1:		Line 1:
			{{Template:Question_engine_2}}
	This page explains how I think the question engine should work in Moodle 2.0 or 2.1.		This page explains how I think the question engine should work in Moodle 2.0 or 2.1.

Line 384:		Line 385:

	* Back to [[Question_Engine_2\|Question Engine 2]]		* Back to [[Question_Engine_2\|Question Engine 2]]

	~~{{CategoryDeveloper}}~~
	~~[[Category:Quiz]]~~

← Older revision		Revision as of 17:02, 27 November 2009
Line 373:		Line 373:
	One adavntage of the way data will be stored in the new system is that everything originally submitted by the user will be stored in the database in a format very close to the one in which it was originally received by the web server. Therefore, it should be easy to write a script that replays saved quiz attempts. This is the basis of a test harness. I will create such a test script as part of this work.		One adavntage of the way data will be stored in the new system is that everything originally submitted by the user will be stored in the database in a format very close to the one in which it was originally received by the web server. Therefore, it should be easy to write a script that replays saved quiz attempts. This is the basis of a test harness. I will create such a test script as part of this work.

			==Huge class diagram==

			This diagram shows all the classes in the question code (no including specific plugins), with most of the core of my new proposal implemented.

			[[Image:Question_classes.png]]

	==See also==		==See also==

← Older revision		Revision as of 11:30, 25 November 2009
Line 376:		Line 376:
	==See also==		==See also==

	In the next section, [[Question ~~Engine 2:Implementation plan~~\|~~Implementation plan~~]] ~~outlines how~~ I will ~~implement this~~.		In the next section, [[Developing a Question Interaction Model\|Developing a Question Interaction Model]] I describe what a developer will need to do to create a Question Interaction Model plugin for the new system.

	* Back to [[Question_Engine_2\|Question Engine 2]]		* Back to [[Question_Engine_2\|Question Engine 2]]