Flow of mod plugin

Flow of mod plugin

by Dan Nessett -
Number of replies: 6
I have been watching videos about Moodle and looking at the documentation, but I am still puzzled about the flow of control of a mod plugin. In particular, there seems to be two places when the plugin code is called. The first is when the plugin is instantiated and set up for use. The second is when a user uses this instantiation to achieve some objective. 

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?
Average of ratings: -
In reply to Dan Nessett

Re: Flow of mod plugin

by Mark Sharp -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers
For activities (mod plugins) there is usually a settings page, where the tutor will fill out whatever is required by the plugin. This information is a form, and is provided by mod_form.php in your plugin. Moodle will automatically load that on the settings page, you don't need to specifically create a settings page.

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.
Average of ratings:Useful (2)
In reply to Mark Sharp

Re: Flow of mod plugin

by Dan Nessett -
Thanks for the information. I have a follow up question. (Note: I have created a skeleton using the plugin skeleton generator in manual mode)

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.
In reply to Dan Nessett

Re: Flow of mod plugin

by Mark Johnson -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

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.

Average of ratings:Useful (2)
In reply to Dan Nessett

Re: Flow of mod plugin

by Dominique Palumbo -
Picture of Plugin developers
Hi,

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);
} else if ($d) {
     $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.
Average of ratings:Useful (2)
In reply to Dominique Palumbo

Re: Flow of mod plugin

by Dan Nessett -
Thanks very much Dominique. Having some code to study is a great way to learn how to write code myself.