To be concrete, I am attempting to write a plugin that will allow students to fill in a propositional logic truth table, which when submitted will be checked for accuracy. The first entry point must be when the course instructor sets up an instance of the truth table, providing a logic expression for evaluation. The second entry point is when the student provides the values corresponding to each combination of truth table variables for the logic expression, which will be evaluated for accuracy.
I can't find any documentation that indicates where are these two entry points for a particular mod type plugin. If someone can point me in the right direction for documentation, I would appreciate it. Also, I would like the plugin to support logic problems other than truth tables (e.g. truth trees). I assume the first entry point is the appropriate place for the plugin to present to the course instructor the choice to use one out of a selection of problems. Is this correct?
There are some minimum required fields in mod_form for name and description. You will need to provide for these fields, and any extra fields you wish to define, in the db/install.xml file.
Students typically view or participate in the activity from the view.php page.
Additionally, the lib.php provides extra information to Moodle about the features of your plugin.
Have a look at existing plugins for examples, and download the Skeleton plugin (https://moodle.org/plugins/tool_pluginskel ) which can be a good starting point.
I assume the core Moodle code will call some class function when a student encounters the plugin in a particular setting. For example, the course instructor may have set up the plugin for a homework or quiz entry (not sure what is the right terminology). When the function is called, there must be enough information provided by the core code for the function to retrieve the correct DB entry to get the specific instantiation of the plugin. For example, there may be many homework entries created over time that use the plugin. When the student accesses one of these entries, the core Moodle code, I would assume, would provide the identify of the instantiation being accessed, the student id and the course id. This would allow the plugin to access the correct DB information to display the correct truth table and then allow it to record in the database what input the student made (i.e., the truth values associated with the propositional logic expression). It seems to me this requires two class function calls, one to display the unfilled truth table and another when a submit button is clicked, which allows the plugin to record the results in the DB.
I could not find any classes or class functions in view.php that correspond to these events. Do I have to create a class for this interaction with the core Moodle code and if so, is there documentation about it? Or have I completely misunderstood how the core Moodle code interacts with mod plugins.
Moodle isn't such a strict framework as what you are describing. When you enter an instance of a activity from the course page, you are taken to the view.php page in that plugin, with the course module ID (the specific instance of the plugin on that course) as a URL parameter, and the current user available from the session (via the $USER
global). How you implement the plugin from there is largely up to you. It would certainly make sense to do as you say, create a function that fetches the defined task for that instance then display it to the user (look at the DML and Output APIs), and another that receives the submission and stores it in the database. You may also find the Forms API useful for handling the user submission, but it may not fit the UI you are thinking of.
This is a sample of code of a plugin I do, the best it's to read the code of similar plugin and go step by step.
You'll have backup/restore, security (capability), RGPD etc to manage in a plugin.
In view php, I've this code to get info about the current course and current module. Where a user has click on it.
require(__DIR__.'/../../config.php');
require_once(__DIR__.'/lib.php');
global $USER;
...
// Course_module ID, or.
$id = optional_param('id', 0, PARAM_INT);
// Module instance id.
// Default tab is the Result -> global view.
$d = optional_param('d', 0, PARAM_INT);
if ($id) {
$cm = get_coursemodule_from_id('dynamo', $id, 0, false, MUST_EXIST);
$course = $DB->get_record('course', array('id' => $cm->course), '*', MUST_EXIST);
$dynamo = $DB->get_record('dynamo', array('id' => $cm->instance), '*', MUST_EXIST);
$dynamo = $DB->get_record('dynamo', array('id' => $d), '*', MUST_EXIST);
$course = $DB->get_record('course', array('id' => $dynamo->course), '*', MUST_EXIST);
$cm = get_coursemodule_from_instance('dynamo', $dynamo->id, $course->id, false, MUST_EXIST);
} else {
print_error(get_string('missingidandcmid', dynamo));
}
....
// a Basic security check.
require_login($course, true, $cm);
$modulecontext = context_module::instance($cm->id);
if (has_capability('mod/dynamo:create', $modulecontext)) {
$mode = 'teacher';
} else {
require_capability('mod/dynamo:respond', $modulecontext);
$mode = 'student';
}
....
if ($mode == '') {
redirect(new moodle_url('/my'));
die();
}
...
$PAGE->set_url('/mod/dynamo/view.php', array('id' => $cm->id));
$PAGE->set_title(format_string($dynamo->name));
$PAGE->set_heading(format_string($course->fullname));
$PAGE->set_context($modulecontext);
echo $OUTPUT->header();
...
if ($mode == 'student') {
require_once(__DIR__.'/student.php');
}
if ($mode == 'teacher') {
require_once(__DIR__.'/teacher.php');
}
echo $OUTPUT->footer();
Depending on capabilities of the user that is on the activity I have different 'mode' for student or teacher. One to let them do the activity the second to display a report like in an assign or quiz.
It's probably not the best and doesn't use any mustache but I hope it will help you to do ahead.
Dominique.