Note: You are currently viewing documentation for Moodle 2.2. Up-to-date documentation for the latest stable version is available here: Developing a Question Type.

Development:Developing a Question Type

From MoodleDocs
Revision as of 16:31, 25 November 2009 by Tim Hunt (talk | contribs)

This page explains how to go about writing a new Question Type for the new Moodle question engine.

For instructions on making a question type for current versions of Moodle, see Development:Question_type_plugin_how_to.

Previous section: Developing a Question Interaction Model

Note: This article is a work in progress. Please use the page comments or an appropriate moodle.org forum for any recommendations/suggestions for improvement.



File layout

Question types live in a folder in question/type. The layout inside this folder follows the typical layout for a Moodle plugin. For example, inside the question/type/mytype/ folder we would have:

questiontype.php
Defines the description_qtype class (this may be renamed to qtype_mytype at some point). This must extend default_questiontype (which may get renamed to question_type).
question.php
This contains the definition of the qtype_mytype_question class, which should extend the question_definition base class.
renderer.php
This contains the definition of the qtype_mytype_renderer class, which should extend the qtype_renderer base class.
simpletest/...
Contains the unit tests for this interaction model. You are strongly encouraged to write thorough unit tests to ensure the correctness of your interaction model.
lang/en_utf8/qim_mymodel.php
English language strings for this interaction model. You can, of course, include other languages too. The language file must define at least the string giving the model a name, for example $string['mymodel'] = 'My model';; dm/install.xml, db/upgrade.php : For creating any database tables required, as normal. See [[]#Database_tables]] below.
db/access.php


Database tables

Note that question types should only have database tables for the question definition. All runtime data is managed by the question engine.

Question definitions should use the core table question, and can use the core table question_answers. You only need to define database tables if your question definition requires extra information that cannot be stored in either of these.


Question type class

This class represents the question type. It is responsible for loading and saving instances of questions of this class. It is also responsible for backing them up and restoring them. It also provides meta-data about the question type.


TODO

Question class

This holds the definition of a particular question of this type. There may also be some methods to perform processing. For example grade_responses.


TODO

Renderer class

Renderers are all about generating HTML output. The overall output of questions is controlled by the core_question_renderer::question(...), which in turn calls other methods of itself, the question type renderer and the interaction model renderer, to generate the various bits of output. See this overview of the parts of a question.

Once again, in what follows, I only list the methods your are most likely to want to override.


TODO

See also

In the next section, Implementation plan outlines how I will implement this proposal.

Template:CategoryDeveloper