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.

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?

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.