Moodle quiz view php

Documentation

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

Quiz reports

Quiz report sub-plugins can not only be used to display custom reports on the quiz data, but can also be used to plugin other functionality into the quiz module.

Contents

Overview

Theses sub-plugins have frankenstyle prefix quiz_, and live inside mod/quiz/report. (The prefix was a historical mistake. It would have been much better to use quizreport_, but it is too late to change now.)

A quiz report plugins just needs to implement one class

class quiz_name_report extends quiz_default_report < public function display($cm, $course, $quiz) < // Generate and display the report, or // other functionality. >>

The base class is defined in mod/quiz/report/default.php and you just need to implement the display method. This gets called from mod/quiz/report.php after some basic set-up has been done.

What files make up a quiz report

mod/quiz/report/name/ report.php - Contains the implementation of the quiz_name_report class. version.php - Normal Moodle plugin version.php file. lang/en/quiz_name.php - Language strings for your plugin. db/* - lets you define db tables, capabilities, etc. simpletest/* - Unit tests.

• It is possible to make a working plugin with only the first three of these.
• The only lang strings you need to define are pluginname, reportname and namereport. (This should probably be simplified in the future.)

When a user view the report

There are some useful helper classes in mod/quiz/report/attemptsreport.php. This is basically the common functionality that is used by both the overview and responses reports. If you want to make a similar report (with one row for each quiz attempt) you should probably build on these classes.

There are also useful helper functions in mod/quiz/report/reportlib.php.

See also

Источник

Documentation

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

Quiz

The quiz is a complex module, although attempts have been made to re-organise the code to keep things managable.

This page is only intended to give a high level overview. To really understand the quiz, you will have to look at the code, much of which should be clear and well commented.

Contents

What the quiz does and does not do

The quiz module uses the Question bank to manage the questions that teachers create, and the Question engine to display and process questions when students attempt them. You are particularly advised to read Using the question engine from module.

The quiz module itself is only responsible for

1. letting teachers assemble questions into quizzes.
2. controlling which students can attempt the quiz when.
3. providing access so that students can review their past attempts and the feedback (if the teacher permits it).
4. providing reports on the outcomes for teachers.

Displaying the results is delegated to quiz report sub-plugins. Note that some fairly core functionality is implemented in the reports. For example deleting and regrading attempts is handled by quiz_overview report, and bulk manual grading is handled by quiz_grading.

A lot of the details of when and if students can access the quiz are handled by quiz access rule sub-plugins.

Code overview

All the code has PHPdoc comments which provides a lot of detailed explanation. That is not repeated here.

This is a standard Moodle activity module, so inside mod/quiz there are all the things you would expect to see like db/, lib.php, locallib.php, view.php, version.php and so on.

The scripts that are directly accessed by the user are listed on Quiz user interface overview, and I will not list them again here. It would probably also help to look at the Quiz database structure before trying to understand the back-end code.

The back-end code is organised thus:

lib.php All the functions that are called by the Moodle core. For performance reasons it is important that this does not include any other files. locallib.php This contains all the other quiz library functions that do not have a more specific home. Including this file also includes all the other quiz libraries that you might need. mod_form.php The module settings form, as you would expect for any Moodle activity module. editlib.php This defines the functions that are used when at teacher edits the quiz. Thus, they are mostly called from edit.php. attemptlib.php This defines the quiz and quiz_attempt classes. These are all about what happens when a student (or other user) is looking at the quiz, so they provide a personalised view of the quiz data from the point of view of that user. Thus these classes are mainly used by the view.php, startattempt.php, attempt.php, processattempt.php, summary.php and review.php scripts. accessmanager.php This provides the interface point that the rest of the quiz code uses to access the quiz access rule sub-plugins. renderer.php the quiz uses the Moodle 2.x renderer system to generate the HTML for all the student-visible parts of the UI. This means that theme designer have a lot of freedom as to how the quiz is displayed to students. Perhaps one day the editing UI will also be re-factored. As is standard for a Moodle plug-in, this file defines the renderer class. settings.php & settingslib.php define the admin settings for the quiz. accessmanager_form.php, addrandomform.php & override_form.php Used by accessmanager.php, addrandom.php and overridedit.php respectively. module.js JavaScript used by attempt.php and to a lesser extent view.php, summary.php and review.php. edit.js JavaScript used by edit.php.

Quiz navigation fake block

During the quiz attempt (so, on attempt.php, summary,php (from Moodle 2.2 onwards) and review.php) we display a navigation UI that looks like a block. This uses the block_manager::add_fake_block feature.

The block contents is produce by classes in attemptlib.php working with methods in the renderer. The navigation relies on some JavaScript in module.js because it is vitally important that every time the user moves from one page of the quiz attempt to another, we save their answers. The javascript turns click on the navigation links into form submissions.

Quiz layout

Information about the structure of a quiz is stored in the quiz.qestions column and the quiz_question_instances table. The layout is a comma-separated list of question ids, with 0s to represent page-breaks.

There are methods in locallib.php and editlib.php to manipulate this structure.

When a quiz attempt is stared, the questions are added to a question_usage_by_activity object ($quba) that is managed by the question bank. The $quba indexes things by ‘slot’ rather than question.id, so the quiz layout gets rewritten and stored in quiz_attempts.layout. This is done in startattempt.php.

One of the options is to randomise the order of the question in the quiz. This is done by shuffling quiz_attempts.layout.

startattempt.php also handles selecting a real question to go in each place where the teacher has added a ‘Random question from category X’ to the quiz.

See also

• Goals of an online assessment system — a summary of what the quiz is trying to achieve, and the developments that might be done in the future.
• Question bank
• Question engine — also Question_Engine_2, which needs to be merged into it. In particular, see Using the question engine from module.
• Quiz Usability portal — docs from the project to re-design the editing interface in Moodle 2.1.
• Quiz support in the Mobile app — Quiz support in the Mobile app is one of the most requested features by users

Источник

Documentation

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

Quiz access rules

There are various checks that can be imposed before a student is allowed to attempt the quiz. For example the open and close dates, the time-limit, requiring the student to enter a password before starting, and so on. Since Moodle 2.2, these rules are implemented as a type of sub-plugin.

Contents

Overview

Theses sub-plugins have frankenstyle prefix quizaccess_, and live inside mod/quiz/accessrule.

An access rule basically just has to implement one class

class quizaccess_name extends quiz_access_rule_base

The base class is defined in mod/quiz/accessrule/accessrulebase.php documents all the methods you can override. The methods have a default implementation that does nothing, so you only need to override the methods for the hooks you want.

The standard plugins that come with Moodle may not be the best examples to look at, because for historical reasons all their settings are stored in the quiz table. It is probably more helpful to use https://github.com/moodleou/moodle-quizaccess_honestycheck as an example to copy.

The rest of the quiz interacts with the access rules through the quiz_access_manager class defined in mod/quiz/accessmanager.php, The unit tests for all the example rules are worth looking at. The should help you understand what arguments each method takes, and what the return values mean.

What files make up a quiz access rule

mod/quiz/accessrule/name/ rule.php - Contains the implementation of the quizaccess_name class. version.php - Normal Moodle plugin version.php file. lang/en/quizaccess_name.php - Language strings for your plugin. db/* - lets you define db tables, capabilities, etc. backup/moodle2/ - code to backup and restore any data. backup_quizaccess_name_subplugin.class.php restore_quizaccess_name_subplugin.class.php tests/* - Unit tests.

• It is possible to make a working plugin with only the first three of these, but you will probably need more than that.
• The only lang string that required is 'pluginname'.

Handling settings

If your access rule needs additional settings for each quiz, then you need to:

• create a database table to store them in using db/install.xml.
• add the settings to the quiz settings form. Use add_settings_form_fields and/or get_browser_security_choices.
• save those settings when the quiz form is saved. Use save_settings
• load the settings efficiently, along with the other quiz data, when a student views the quiz. Use get_settings_sql and get_extra_settings — but try to avoid the second of those for performance reasons.
• Ensure that the extra settings are backed up and restored, by creating the two files in backup/moodle2. You need to subclass the backup|restore_mod_quiz_access_subplugin classes. These base classes are defined in mod/quiz/backup/moodle2/backup|restore_mod_quiz_access_subplugin.class.php.

https://github.com/moodleou/moodle-quizaccess_honestycheck is a good example of all of this. The standard plugins do not have to do this because their settings are stored in the quiz table (for historical and performance reasons).

When a student view/attempts a quiz

When a student goes into a quiz, we need to create an instance of the quizaccess_name class for each rule that is relevant to this quiz.

Implement the make static factory method to do this. That gets passed the quiz object, which include any extra settings loaded by get_settings_sql or get_extra_settings, and should return an instance of the rule class if the rule is relevant, or return null if it is not.

The description method displays information about the rule on the quiz view.php page. Consider whether this is really necessary. The standard rules provide some good examples of how much information to give.

is_finished reports whether, because of this rule, no more attempts are possible. numattempts is an example of this. delaybetweenattempts is a more subtle example.

The prevent_new_attempt and prevent_access block access to either new attempts or any attempts. They work by returning nothing if access is OK, or returning a list of reasons explaining why if access should be blocked.

is_preflight_check_required, add_preflight_check_form_fields and validate_preflight_check methods are to do with rules like the password or honestycheck that need to present a challenge to the student when they try to attempt the quiz.

notify_preflight_check_passed and current_attempt_finished lets the rule do things when the student starts or finishes attempting the quiz.

time_left is used to initialise the countdown timer during the attempt. The openclosdedate and timelimit rules use this.

attempt_must_be_in_popup, get_popup_options, setup_attempt_page are used by the securewindow rule.

get_superceded_rules lets you make a custom rule that replaces one of the standard ones. There is no example of this yet, but see MDL-13592 for why you might want to use this.

Remember that for more detailed documentation of all these methods, see the PHP docs.

See also

Источник