Moodle

From Martin Dougiamas (martin at moodle.com) Saturday, 12 March 2005, 03:36 PM:

Not so urgent because there are not many of these and they can be added to the main distribution quite easily ...

From Gustav Delius (gwd2 at york.ac.uk) Saturday, 12 March 2005, 04:37 PM:

Hi Martin,

I was just prioritizing things for myself here. As far as feature requests go this one is high in priority exactly because there are not so many question types yet but it looks like there soon will be so now is the time to improve the architecture.

I am not quite what the conventions are on this bug tracker. I was prioritizing within the Feature Requests but that is probably not how it works. Should this be an overall prioritization (in which case of course bugs would always have higher priority than feature requests)?

From Gustav Delius (gwd2 at york.ac.uk) Tuesday, 14 February 2006, 01:06 AM:

I think this mechanism should work exactly like that for modules. That way we don't need to reinvent the wheel. Here are the details:

1) create a table 'questiontype' with fields 'id', 'name', 'version'. The first 12 entries should be created so that the ids match the current qtype ids.

2) the Moodle update script should check the versions of the question types and trigger a database update in the same way as it currently does for modules and blocks. Each questiontype will have a directory 'db' with the database sql and php scripts.

3) the import/export code should have the questionype specific code in a separate file for each questiontype. This code should extend the questiontype class to provide extra methods needed by the import/export code. Questiontype authors will be required to provide these files for their questiontype if they want their questions to participate in import/export.

4) the same applies to the backup/restore code and the report plug-ins. Again questiontypes that don't provide the required files will be ignored by these scripts.

5) each questiontype will get its own language file to be named 'qtype_...' where ... is the questiontype name. The questiontype code can use these strings as usual with get_string('stringname', 'qtype_...') once these files have been dropped into the right language directory.

Did I forget anything?

From Howard Miller (howard.miller at udcf.gla.ac.uk) Tuesday, 14 February 2006, 06:09 PM:

Comment on (3):

My only worry is that some of the import/export routines are considerably knotted up code wise. The different question types are not established until a considerable amount if parsing is acheived. I'm hazy on an elegant way to do this. You could easily end up with a huge library function to do the parsing and the questiontype classes would just be a stub. This seems rather pointless. All this applies to import really. Export is much easier.

From Gustav Delius (gwd2 at york.ac.uk) Tuesday, 14 February 2006, 06:58 PM:

Good point Howard. New question types can not participate in the import of these convoluted import formats. But they could certainly participate in some formats, in particular the xml format. They could even participate in the GIFT format which just needs to be extended to allow for question that say upfront what type they are. The questiontype is then free to define an extension of the GIFT format that is most convenient for that question type.

quizquestiontrackingbug

Tim,
Could you order the unresolved tasks so that in January a plan can be set to finish this in the best delay.
Our recent discussions pinpoint that this plug-in feature is essential to question development.
I can work readily on multianswer and submit a code proposal on docs as usual.
For the other points, you could set a general shematic on how to implement each of them.

One additional point is how the help files will get the language translation support?
Should we set an official plug-in support policy with various grades of support?

Well, 5. (MDL-6371) is the only one left that is causing current inconvenience to anyone, as you know. I won't have any time to do anything about in in the foreseeable future, so I was hoping that your investigations would lead to a solution.

6. (MDL-6751) No-one seems to be missing this yet, but it would be really nice to have, especially as people start to experiment with plugins from contrib. I hope it will make it into the OU's priority list for the first half of 2008 so I can do it.

8. (MDL-5106) is trivial, and will probably get knocked on the head the moment I have a few hours with nothing more important to do.

4. (MDL-6370) is a performance improvement, but no-one has reported difficulty from the theoretical performance problem that this solves. So we could live without this for a while, or it may actually be possible to solve it while working on 6.

I want to create subtasks of MDL-6751, so I had to change it from being a subtask of this bug, into being an issue in its own right.

Apparently someone got confused by this.

The point of this issue is as a central place to track all the issues that restrict what third-partly question types can do, as opposed to what the question types built into the standard Moodle release can do.

As you can see, over the years, we have fixed almost all the issues. Currently, the only limitation on third-party question types is that they cannot be used in multianswer questions (and some people would like to be able to use the regex question type in the multianswer question type).