Native importer engine doesn't handle 'multichoice'
turadg - July 14, 2009 - 19:46
| Project: | Quiz |
| Version: | 6.x-4.x-dev |
| Component: | Code - Import/Export |
| Category: | bug report |
| Priority: | normal |
| Assigned: | turadg |
| Status: | postponed |
Jump to:
Description
At some point the "choice" module will be blessed and "multichoice" will be deprecated. At that point we'll need the importer to be updated to make choice nodes instead of multichoice nodes.
Also, the example files and test code will have to be updated.
Before then, the CSV importer could be made to handle both choice and multichoice since we define that format.
#1
Our importer has two engines, a custom one and one from Moodle.
Per http://drupal.org/node/535900, the Moodle engine now uses NEW 'multichoice' as the node it generates during question import, but the 'native' engine doesn't. The native engine handles the Aiken and our custom CSV formats.
For Aiken, we could switch to the Moodle engine.
For CSV, we have to have a spec for the format using 'choice' nodes. This might first be implemented by the exporter, http://drupal.org/node/536134#comment-1896494
#2
#3
turadg?
#4
I advocate dropping the "native" engine to use the engine I ported from Moodle instead. The Moodle engine provides an Aiken importer so it can replace the "native" Aiken importer.
The CSV format would be dropped. I think this is a good thing as the CSV format is not really a format. It poses difficulties whenever new features are added to the content types, such this issue with the *new* multichoice.
So I'm inclined to this "won't fix" and advising use of the formats provided by the Moodle engine instead. I'll leave it to falcon to make the call. If we do drop the native/non-Moodle importer then we at least need to take it out of the UI.
Alternately, we can make a simple XML to handle all our quiz question types, as I proposed in discussion. Basically a "Drupal Quiz XML" like the "Moodle XML" format, with all the data that the questions have in the database. I think this would be a better use of efforts that would go into a CSV format. I may have time in a couple weeks to implement this but I'm not sure.
#5
I vote for dropping it then. We might lose some backwards compatibility, but hopefully that won't be a problem.
Could you remove it from the UI turadg?
#6
Ok, I'll drop it when I get time late next week.
Anyone who objects, chime in before then.
#7
I have now removed the native importer from the UI. Will wait until I have spoke to the other maintainers and then remove the native importer and qcollection completely