Choosing a correct plugin type.

Choosing a correct plugin type.

by Dalin Williams -
Number of replies: 15

Hello all,

Per the usual, I am a new-to-the-community developer, and I was wondering if you all could assist me in narrowing down which category my proposed plugin be placed.


For a description, this plugin, developed for my masters project, will provide detailed grade progression information and statistics for students. These statistics would include class progression, current assignment difficulty/weight, and assignmyent completion. I at first assumed that these graphs could be included in a block, but now I am wondering if I am at all correct in my assumptions. I can provide more detains if this description is not quite succinct. Thank you all in advance.

Below, you will see an example of what the graphs currently look like, the top being the users progression within a course, the bottom being a type of heat-map showing the current difficulty of the course assignment to assignment.

Attachment A seak peak....png
Average of ratings: -
In reply to Dalin Williams

Re: Choosing a correct plugin type.

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Sounds like a report to me.

Average of ratings: -
In reply to Marcus Green

Re: Choosing a correct plugin type.

by Gareth Barnard -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

Also sounds like a report to me.  But... can students see reports normally?  Perhaps I've spent too much time in course formats and themes to remember off the top of my head.

It might be Dalin that you want to avoid the extra click and have students 'remember' to look at it, so for more 'in your face' then go with a block.  Or if you want it big at the top / bottom of the course then can either be a part of a theme or a within a new course format.

Average of ratings: -
In reply to Gareth Barnard

Re: Choosing a correct plugin type.

by Dalin Williams -

Alright, so lets speculate and say I go with the block, which does present the student with the more 'in your face' presentation. Should the graphs then be split into multiple blocks, as to allow the student to view the data more succinctly?

As for the reports, I thought that should be the case, however I have dabbled on my personal test moodle server, and have found that students have no inherent method viewing reports, unless of course I am mistaken! Have you any resource that I could take a look at?

Average of ratings: -
In reply to Dalin Williams

Re: Choosing a correct plugin type.

by lior gil -
Picture of Core developers

I personally think a small block would be too limiting. A better approach (in my opinion at least) would be writing this as a local plugin with access link either from the navigation block of the top menu.

This way you'll have a whole page to play with and design instead of limiting yourself to a small block, not to mention a better view on smaller platforms such as mobile.

However, there's a much more serious issue here. As Gareth mentioned above, students don't have access to reports, at least not as detailed as yours. The reason is that any report requires some level of data mining. The more detailed the report the heavier the process is. And unless you have a dedicated server, giving all students access to the reports 24/7 might slow your whole site and in the worst scenario - crash it.

One way around it is to allow students to create one report per day or so, but this still leaves the possibility of a few hundreds students trying to create a report in the same day.

Average of ratings: Useful (1)
In reply to lior gil

Re: Choosing a correct plugin type.

by Dalin Williams -

Thank you for the advice lior gil, but I do have one question. What exactly would be the difference between the dedicated page and a block with a like to a dedicated page? As for the data usage, how would students "all be accessing the grades 24/7," if this is an optional report. Some students would view the report, others would not. I can see a scenario where students would 'kill' the server. If you would mind expounding on the catastrophic worst case scenario, I would appreciate it.

Average of ratings: -
In reply to Dalin Williams

Re: Choosing a correct plugin type.

by lior gil -
Picture of Core developers

The local plugin approach is purely opinion based of course. The way I see it, while a block is course based, a local plugin does not need a new instance for each course, and if you use the block only to open a dedicated page then the whole purpose of the block is somewhat diminished.

On the other hand, if you want the plugin to be enabled only on selected courses then using a block is the best way and it makes all my other arguments irrelevant.

As for performance, I have no idea how your report works so I can only talk from experience.

I once wrote a component that produced a (much less pretty) report for a selected course with detailed statistics about the usage of its components along with some other statistical information. Depending on the course and its content, each report could take anywhere between a few seconds and a few minutes.

In the end we abandoned the original plan to open it to all editing teachers and instead restricted it to a small group that produced reports by request.

The bigger the database, the longer the queries will run. Just sifting through all the tables takes its toll. As for "24/7", what I meant is that you have no control over how many students will use it at any given time.

Suppose a report takes around 10 seconds and four students decide to use it at the same time, you get about 20-40 seconds of hard processing time that might slow the whole site.

Now let's say it's the end of a semester and a hundred students want to create a report, all in one day. Even if it all spreads over several hours there's still the possibility of a bottleneck in the SQL server that could slow it down significantly or even freeze it.

I know it sounds very pessimistic, especially when I have no knowledge about your code performance-wise, but this possibility should be considered.

Average of ratings: -
In reply to lior gil

Re: Choosing a correct plugin type.

by Dalin Williams -

Ah, I see why you would think a plugin such as mine would be cause for great concern. For the time being, my queries are limited to the user's profile (of coerces [teachers, managers, and students only]) . This limitation of 'no global scope' should, I think, prevent severe performance bottleneck. Should this be a problem, we will engineer a solution addressing that problem promptly. Thank you for  the advice.

Average of ratings: -
In reply to lior gil

Re: Choosing a correct plugin type.

by Dalin Williams -

Ah, I see why you would think a plugin such as mine would be cause for great concern. For the time being, my queries are limited to the user's profile (of coerces [teachers, managers, and students only]) . This limitation of 'no global scope' should, I think, prevent severe performance bottleneck. Should this be a problem, we will engineer a solution addressing that problem promptly. Thank you for  the advice.

Average of ratings: -
In reply to lior gil

Re: Choosing a correct plugin type.

by Paul Nicholls -

Although it's technically a report (of sorts), a block is probably a good way to go if you want it to be available to (and actually used by) students.  There are other blocks out there already which generate and link to other reports/pages, so it's certainly not forbidden wink

If you build a block, there's nothing stopping you from adding a separate PHP file in your plugin which generates a full-page display, and linking to it from the block's content.  You could use an eye-catching image, or even a small (but quick to generate and/or cached) representation of one of the charts - perhaps you could generate and cache the course difficulty chart (since that's presumably the same for all students) and display a small version in the block, with a link through to a page which shows both full charts (or two links - one to each chart).

As far as performance goes, if it takes much work to generate the charts (which I imagine it will, looking at the complexity and the type of data involved), make sure you cache them - perhaps for an hour, to allow a balance between performance and the data being up-to-date.  If you think it necessary to ensure that students can see the most up-to-date data at any time, you may be able to use an event handler to listen for completion-related events and invalidate the relevant cache items, or you might find a light-weight way to determine whether there have been any changes to the student's completion status since their chart was last generated.


-Paul

Average of ratings: Useful (1)
In reply to Paul Nicholls

Re: Choosing a correct plugin type.

by Dalin Williams -

Thank you for the helpful advice there, I will probably go with this solution, and evolve the project as needed. Is there a specific reference that you can point me to referencing moodle's method of caching, or is this a form of using session? Pardon my ignorance.

Average of ratings: -
In reply to Dalin Williams

Re: Choosing a correct plugin type.

by Paul Nicholls -
There's a page on the Cache API in the docs, plus a Quick Reference.  Give those a look and try it out; if you encounter any issues not covered by the docs (or existing posts here in the forums), feel free to start a new thread outlining the issue(s) and what you've tried.  As I'm sure you're already aware, the more information you can give us, the more readily somebody will be able to help you smile
Average of ratings: -
In reply to Dalin Williams

Re: Choosing a correct plugin type.

by Marina Glancy -
Picture of Core developers Picture of Moodle Workplace team Picture of Peer reviewers Picture of Plugin developers Picture of Testers
I would suggest either grade report or .... admin tool

Admin tools can insert items in the navigation tree anywhere and also they (as any plugin types) can insert data on the user dashboard (Moodle 2.9). Your plugin will need to define callback pluginname_myprofile_navigation (search for examples in 2.9 code)
Average of ratings: -
In reply to Marina Glancy

Re: Choosing a correct plugin type.

by Dalin Williams -

Thank you for the suggestion, but is there a method to allow students to view a report plugin? 

Average of ratings: -
In reply to Dalin Williams

Re: Choosing a correct plugin type.

by Marina Glancy -
Picture of Core developers Picture of Moodle Workplace team Picture of Peer reviewers Picture of Plugin developers Picture of Testers

there is no such thing as "student" or "teacher" in moodle backend. There are capabilities. Your report plugin should define capability to view the report. Your plugin can recommend to add this capability to roles with teacher or student archetypes. The administrator of the site can give or revoke any capability to/from any role regardless of the plugin's recommendation.

Most of the reports in moodle are not available to students by default but it does not mean it's a law. Look at the report "user sessions" (2.9), it is visible by default to all registered users: https://github.com/moodle/moodle/blob/MOODLE_29_STABLE/report/usersessions/db/access.php

Then to check permission of the user to access your report you call:

require_login($course); // or without $course if it is a side-wide report
require_capability('report/myreport:view', $context); // where $context is either course or system or user context

In lib.php you also define callbacks such as report_myreport_extend_navigation_user() and/or report_myreport_myprofile_navigation() to add the link to the report in navigation and on my profile page. Inside those callbacks you again check the capability to view the report.


One more tip: keep in mind parents/mentors functionality. Think of parents who are allowed to view reports about their children. In moodle it is implemented by assigning capabilities in the context of another user. There is usually the same capability 'moodle/user:viewuseractivitiesreport', search for its usages in the code

Average of ratings: -
In reply to Marina Glancy

Re: Choosing a correct plugin type.

by Dalin Williams -

Ah I see, quite the coincidence that as I was previously reading the Access API and its capabilities when you should mention this! Thank you for all the excellent points as well as references, as they will be quite useful!  smile I think just for this first moodle project, I'll wrap it up with a block implementation, then move it on over to a report. Sure, one could say do it 'right' the first time, but I want to become relatively comfortable become diving into the sea of worms! Plus, it also helps that this block needs to be completed within one month. I will, however, use the permissions checking for the displaying of different graphs to different users of the system.

As for the addition of parent views, what type of user would they be? Would not they be recognized as a guest? As for as I have researched, guest roles are a no no, unless you are stating something that I am blundering about in my understanding!

Average of ratings: -