Moodle
  1. Moodle
  2. MDL-2727

META - Question type plugins are not completely pluginable

    Details

    • Affected Branches:
      MOODLE_19_STABLE
    • Rank:
      1584

      Description

      Adding an optional question type should be a matter of simply dropping the files in the right location. Currently it is not quite that simple. See the subtasks for specifics.

      (Note that this bug was started in the Moodle 1.5 days, so some of the comments are no longer relevant.)

        Issue Links

          Activity

          Hide
          Martin Dougiamas added a comment -

          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.

          Show
          Martin Dougiamas added a comment - 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.
          Hide
          Tim Hunt added a comment -

          quizquestiontrackingbug

          Show
          Tim Hunt added a comment - quizquestiontrackingbug
          Hide
          Pierre Pichet added a comment - - edited

          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?

          Show
          Pierre Pichet added a comment - - edited 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?
          Hide
          Tim Hunt added a comment -

          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.

          Show
          Tim Hunt added a comment - 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.
          Hide
          Tim Hunt added a comment -

          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.

          Show
          Tim Hunt added a comment - 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.
          Hide
          Tim Hunt added a comment -

          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).

          Show
          Tim Hunt added a comment - 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).
          Hide
          Michael de Raadt added a comment -

          Thanks for reporting this issue.

          We have detected that this issue has been inactive for over a year has been recorded as affecting versions that are no longer supported.

          If you believe that this issue is still relevant to current versions (2.3 and beyond), please comment on the issue. Issues left inactive for a further month will be closed.

          Michael d;

          4d6f6f646c6521

          Show
          Michael de Raadt added a comment - Thanks for reporting this issue. We have detected that this issue has been inactive for over a year has been recorded as affecting versions that are no longer supported. If you believe that this issue is still relevant to current versions (2.3 and beyond), please comment on the issue. Issues left inactive for a further month will be closed. Michael d; 4d6f6f646c6521
          Hide
          Joseph Rézeau added a comment -

          MDL-6371 is still valid.

          Show
          Joseph Rézeau added a comment - MDL-6371 is still valid.
          Hide
          Anthony Borrow added a comment -

          Tim indicated that most of these issues are resolved. I would say that anything not resolved should be created as a new issue and go ahead and close this issue as Won't fix or Fixed. Peace - Anthony

          Show
          Anthony Borrow added a comment - Tim indicated that most of these issues are resolved. I would say that anything not resolved should be created as a new issue and go ahead and close this issue as Won't fix or Fixed. Peace - Anthony
          Hide
          Tim Hunt added a comment -

          Anthony, this is a META but, with a list of relevant sub-tasks, one of which is still open. Joseph's comment was spot-on, which is why I did not comment myself. This issue should remain open.

          Show
          Tim Hunt added a comment - Anthony, this is a META but, with a list of relevant sub-tasks, one of which is still open. Joseph's comment was spot-on, which is why I did not comment myself. This issue should remain open.
          Hide
          Tim Hunt added a comment -

          This issue was assigned to me automatically, however I will not be able to work on this issue in the immediate future. In order to create a truer sense of the state of this issue and to allow other developers to have chance to become involved, I am removing myself as the assignee of this issue.

          For more information, see http://docs.moodle.org/dev/Changes_to_issue_assignment

          Show
          Tim Hunt added a comment - This issue was assigned to me automatically, however I will not be able to work on this issue in the immediate future. In order to create a truer sense of the state of this issue and to allow other developers to have chance to become involved, I am removing myself as the assignee of this issue. For more information, see http://docs.moodle.org/dev/Changes_to_issue_assignment

            People

            • Votes:
              14 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated: