http://docs.moodle.org/en/Development:Plans_for_enhancing_import/export_in_questiontype_plugins
Please excuse the snappy title
I've roughed something out...
http://docs.moodle.org/en/Development:Plans_for_enhancing_import/export_in_questiontype_plugins
Please excuse the snappy title
I think it needs a bit of fleshing out and some examples, but I think my direction is clear enough (I hope). Tim in particular, but anybody with an interest, could you take a look and comment? I've tried to keep it all as simple as I can.
http://docs.moodle.org/en/Development:Plans_for_enhancing_import/export_in_questiontype_plugins
Please excuse the snappy title
I think your proposal will work, but I don't think it is very pretty.
My main worry is that it will encourage people to write import and export methods that are huge case statements.
Also, it does not take advantage of the fact that question types are classes, that might inherit from each other, which is one way to reduce code duplication. (About the only example of this in Moodle core is that the numerical question type is a subclass of shortanswer).
I've got an alternate proposal, which may be overcomplicated, but I will add it to the wiki when I get back from the meeting I am about to go to.
My main worry is that it will encourage people to write import and export methods that are huge case statements.
Also, it does not take advantage of the fact that question types are classes, that might inherit from each other, which is one way to reduce code duplication. (About the only example of this in Moodle core is that the numerical question type is a subclass of shortanswer).
I've got an alternate proposal, which may be overcomplicated, but I will add it to the wiki when I get back from the meeting I am about to go to.
My theory was that most people will either not implement it at all or will just implement for one or perhaps two formats.
I was going for as simple as possible but, anyway, I look forward to your thoughts.
I was going for as simple as possible but, anyway, I look forward to your thoughts.
I'm afraid it turned into more of a ramble, than a coherent design, but http://docs.moodle.org/en/Development:Plans_for_enhancing_import/export_in_questiontype_plugins#Alternate_proposal_from_Tim.
I think my proposal looks pretty in theory, but you probably know lots more gruesome details about the existing formats that may break my pretty idealised picture. Anyway, see what you think.
I think my proposal looks pretty in theory, but you probably know lots more gruesome details about the existing formats that may break my pretty idealised picture. Anyway, see what you think.
I need to read this more carefully, but my first knee-jerk reaction is to do with the issue of splitting up the process into methods on a number of formats multiplied by the number of questiontypes basis. Export is fair enough, but import (remember, that nearly all the formats *are* import only so that's what actually matters) is tricky.
I also had this conversation with Gustav ages ago. The requirement here is that you can establish the questiontype within the import file trivially. This is the case for the XML format sure but decidedly not the case for (for example) GIFT format. GIFT format does a lot of work to split up the question text and more-or-less right at the end deduces what type of question it is. For me, this has always blown this refactoring plan right out of the water. It would also be a lot of (probably error fraught work) to refactor all that stuff.
Of course, the latter is equally problematic for questiontype plugins supporting import. However, I think with enough flexibility it could still be possible but the standard format needs to "decide" how much to tell the questiontype plugin. Again using the example of GIFT, I guess it would have to pass the whole questiontext over to the questiontype plugin, but it wouldn't work at all if it had to 'know' the questiontype to call. Hence my polling the types idea - even though it *is* inelegant and wasteful it gives each questiontype a chance to do whatever it needs to do to accept or reject the question.
In fact I think I would ammend my proposal to take out the questiontype name from the parameters (for import) altogether because in the general case you may not know. And this is where it all fell down last time around
I also had this conversation with Gustav ages ago. The requirement here is that you can establish the questiontype within the import file trivially. This is the case for the XML format sure but decidedly not the case for (for example) GIFT format. GIFT format does a lot of work to split up the question text and more-or-less right at the end deduces what type of question it is. For me, this has always blown this refactoring plan right out of the water. It would also be a lot of (probably error fraught work) to refactor all that stuff.
Of course, the latter is equally problematic for questiontype plugins supporting import. However, I think with enough flexibility it could still be possible but the standard format needs to "decide" how much to tell the questiontype plugin. Again using the example of GIFT, I guess it would have to pass the whole questiontext over to the questiontype plugin, but it wouldn't work at all if it had to 'know' the questiontype to call. Hence my polling the types idea - even though it *is* inelegant and wasteful it gives each questiontype a chance to do whatever it needs to do to accept or reject the question.
In fact I think I would ammend my proposal to take out the questiontype name from the parameters (for import) altogether because in the general case you may not know. And this is where it all fell down last time around
OK, it seems that as I feared, I was being too naive because I do not really know how import works at the moment.
So let's go back to something closer to your original proposal (especially with polling on import).
I still think that you should have separate functions import_formatname, export_formatname for each format that the question type wants to support. And in the format class, where you loop over question types to see if they can handle a import a question that has not been dealt with yet, just put in something like
if (method_exists($QTYPE[$qtype], 'import_' . $this->name())) { // ...
So let's go back to something closer to your original proposal (especially with polling on import).
I still think that you should have separate functions import_formatname, export_formatname for each format that the question type wants to support. And in the format class, where you loop over question types to see if they can handle a import a question that has not been dealt with yet, just put in something like
if (method_exists($QTYPE[$qtype], 'import_' . $this->name())) { // ...
Yes, agreed. I will ammend my proposal and see what you think about it then.
Great, thanks. And feel free to delete my proposal.
Two minor quibbles.
For the sake of grammar, the functions in the question type classes should be import_from_... (but still export_to_...).
I don't like the method names import_plugin and export_plugin. The import_plugin method sounds like it intends to import a plugin. What would be a better name? import_via_qtypes? That is not great, but it is better. see_if_there_is_a_qtype_that_can_import_this - Hmm, probably a bit too long.
But, apart from that, I think this looks great.
Adriane, Joseph, anyone else who has written a question type, does this proposal look good from your point of view?
For the sake of grammar, the functions in the question type classes should be import_from_... (but still export_to_...).
I don't like the method names import_plugin and export_plugin. The import_plugin method sounds like it intends to import a plugin. What would be a better name? import_via_qtypes? That is not great, but it is better. see_if_there_is_a_qtype_that_can_import_this - Hmm, probably a bit too long.
But, apart from that, I think this looks great.
Adriane, Joseph, anyone else who has written a question type, does this proposal look good from your point of view?
Yeh - I struggled with those method names. The import_from is a very good point though. I'll change that.
What about simply(ish)...
import_from_questiontype_plugin()
export_to_questiontype_plugin()
??
I think that the question type import_from_xml and export_to_xml functions sound great.
I don't know that much about import/export, so maybe these aren't problems, but I had a couple questions:
1) Would import_plugin (whatever it gets called) re-try all the core qtypes? I thought that core types were handled separately and if it got to import_plugin, we would know that the core qtypes have all failed (which is why it's import_plugin, not import_qtypes). Is this not the case? (I guess core qtypes wouldn't have the import function, so they'd get skipped anyway. Maybe this isn't really a problem.)
2) I'm a little concerned about how failure in the various cases can be detected consistently, especially if one question type is an extension of another. What if one question type finds all the subfields it's expecting and thinks it's successful, but another question type is really the right one and handles all the subfields?
Maybe import_plugin could get named something like attempt_import_for_plugin_qtypes?
Mmm....
(1) I'm going to answer this with a question. I thought that as the methods would not exist for standard question types then it would quickly skip over them (the last drop of performance is not a big deal as in the big scheme of things these routines will hardly ever be called). I did mean to try and find out if there is a really easy way of checking which are standard question types and which are plugins?
(2) Even if one question *is* an extension of another they still must be different question types in some way. They both can't be right. The plugins must detect which one is the correct one to handle the question type. If this was not the case, import would be the least of the problems IMHO.
Thanks for your comments and interest
(1) I'm going to answer this with a question. I thought that as the methods would not exist for standard question types then it would quickly skip over them (the last drop of performance is not a big deal as in the big scheme of things these routines will hardly ever be called). I did mean to try and find out if there is a really easy way of checking which are standard question types and which are plugins?
(2) Even if one question *is* an extension of another they still must be different question types in some way. They both can't be right. The plugins must detect which one is the correct one to handle the question type. If this was not the case, import would be the least of the problems IMHO.
Thanks for your comments and interest
1) As you say, it will not be a big drop in performance. But if we cared, you could move the method_exists checks outside the main loop over questions - just create a list (array) of those qtypes that implement the method, then iterate over just that list when trying to import each question.
2) Howard is right, as long as each question type obeys the contract for import_from_xxx, (in particular, the return false if the data isn't you) then it will work. It will even work if someone subclasses a question type, and forgets to override import_from_xxx. Importing questions of the subclass type won't work, but importing questions of the superclass type will sill work, as long as the import method sets $question->qtype to the right thing.
Thinking about method names, the best I have come up with so far is: try_importing_using_qtypes(...) (and similarly for exporting).
2) Howard is right, as long as each question type obeys the contract for import_from_xxx, (in particular, the return false if the data isn't you) then it will work. It will even work if someone subclasses a question type, and forgets to override import_from_xxx. Importing questions of the subclass type won't work, but importing questions of the superclass type will sill work, as long as the import method sets $question->qtype to the right thing.
Thinking about method names, the best I have come up with so far is: try_importing_using_qtypes(...) (and similarly for exporting).
Tim and Howard,
As far as I can tell from the documentation in http://docs.moodle.org/en/Development:Plans_for_enhancing_import/export_in_questiontype_plugins
the proposal looks OK to me, and I am ready to test the import and export on my regexp question type as soon as it is made available in HEAD. As I think I stated before I am only interested in the Moodle XML format.
Joseph
As far as I can tell from the documentation in http://docs.moodle.org/en/Development:Plans_for_enhancing_import/export_in_questiontype_plugins
the proposal looks OK to me, and I am ready to test the import and export on my regexp question type as soon as it is made available in HEAD. As I think I stated before I am only interested in the Moodle XML format.
Joseph
Thanks Joseph.
I think we're at the point that I can add the code to HEAD and we can have a play around with it.
I'll let you know when it's done!
I think we're at the point that I can add the code to HEAD and we can have a play around with it.
I'll let you know when it's done!
Hi Howard,
I have started to play with the new import/export format for plugin question types in HEAD, with my REGEXP question type. So far I have implemented the export_to_xml method and am glad to report that it was quite easy to implement and that it does work fine! In file question/type/regexp/questiontype.php, inside class question_regexp_qtype extends default_questiontype {} I simply added the following:
function export_to_xml( $question, $format, $extra=null ) {
$expout = " <usehint>{$question->options->usehint}</usehint>\n ";
foreach($question->options->answers as $answer) {
$percent = 100 * $answer->fraction;
$expout .= " <answer fraction=\"$percent\">\n";
$expout .= $this->writetext( $answer->answer,3,false );
$expout .= " <feedback>\n";
$expout .= $this->writetext( $answer->feedback,4,false );
$expout .= " </feedback>\n";
$expout .= " </answer>\n";
}
return $expout;
}
I also needed to copy from question/format/xml/format.php function writetext( $raw, $ilev=0, $short=true) {} because it seems I cannot link to that file from my own question type, but it's only a few lines.
I will now work on the import_from_xml method, and test backup/restore and then report here. I hope the recent changes by Jamie Pratt to the question bank will not interfere too much with your import/export methods. If you want to take a look at my REGEXP question type you can download it (version 1.8 is OK for 1.9/HEAD) from the plugins download here.
Many thanks for making these methods available to "plugin question types".
Joseph
Doesn't $format->writetext(...) work?
Yes it does! Thanks Tim. Does this mean that the function function writetext( $raw, $ilev=0, $short=true) {} in question/format/xml/format.php is no longer needed?
Joseph
It is needed. That is the funciton you are calling. I was just giving you the code to call it from the question type.
OK, I had not noticed that function try_importing_using_qtypes( $data, $question=null, $extra=null ) in $qtype->$methodname( $data, $question, $this, $extra )) actually makes its own functions available to the plugin question type through the $this parameter. I had never come across this way of "sharing" functions yet. How different is it from a require_once call ?
By the way, what is the $extra parameter for?
Joseph
By the way, what is the $extra parameter for?
Joseph
It's completely different, because it is passing the instantiated object complete with all it's data and its overridden methods for the particular format type. This is one of those rare occasions when Object Oriented programming makes something potentially complicated dead easy. Without it, all those functions would be completely out of scope.
The $extra parameter is not used by xml for a start. I put it in because I was vaguely aware that Blackboard (for example) loads a lot of stuff outside of the question object. This gives a (format defined) option to pass data additional to the question data that may be needed to complete the import or export.
The $extra parameter is not used by xml for a start. I put it in because I was vaguely aware that Blackboard (for example) loads a lot of stuff outside of the question object. This gives a (format defined) option to pass data additional to the question data that may be needed to complete the import or export.
That's why format is passed as a parameter. You can use it to call *anything* in the import/export class. It's almost clever
Yes, very clever.
On a clean Moodle 1.9 HEAD installed from CVS and just upgraded (2007080800) I can't the the questions import to work. I have only one course on this Moodle site, I am admin, I go to default category and click on Import, I get the message: Category ID is invalid
If I turn debugggin on I get more PHP warnings:
Warning: array_keys() [function.array-keys]: The first argument should be an array in C:\moodle\www\moodle19\moodle\lib\questionlib.php on line 1620
Warning: Invalid argument supplied for foreach() in C:\moodle\www\moodle19\moodle\lib\questionlib.php on line 1620
Warning: array_keys() [function.array-keys]: The first argument should be an array in C:\moodle\www\moodle19\moodle\lib\questionlib.php on line 1628
Warning: Invalid argument supplied for foreach() in C:\moodle\www\moodle19\moodle\lib\questionlib.php on line 1628
Any idea anyone?
Joseph
If I turn debugggin on I get more PHP warnings:
Warning: array_keys() [function.array-keys]: The first argument should be an array in C:\moodle\www\moodle19\moodle\lib\questionlib.php on line 1620
Warning: Invalid argument supplied for foreach() in C:\moodle\www\moodle19\moodle\lib\questionlib.php on line 1620
Warning: array_keys() [function.array-keys]: The first argument should be an array in C:\moodle\www\moodle19\moodle\lib\questionlib.php on line 1628
Warning: Invalid argument supplied for foreach() in C:\moodle\www\moodle19\moodle\lib\questionlib.php on line 1628
Any idea anyone?
Joseph
I'm assuming Adriane's code works, but I'm just going to check it myself.
Can you post your import code please?
EDIT:
Just to confirm that Adriane's code works nicely. That bit of library code that is throwing the errors is the one that formats the list of categories (worryling, it's a nasty hack I wrote years ago). I don't *think* it's anything to do with import/export unless you are calling something weird in the functions.
I'm at a loss basically.
Can you post your import code please?
EDIT:
Just to confirm that Adriane's code works nicely. That bit of library code that is throwing the errors is the one that formats the list of categories (worryling, it's a nasty hack I wrote years ago). I don't *think* it's anything to do with import/export unless you are calling something weird in the functions.
I'm at a loss basically.
I think that the cause of the problem is the 'Freash head install' but. The 'Default' category for a course is not created when the course is created, but only when you first go to the category or questions editing screen. So it may be possible to get to the import or export screen before the 'Default' category is created, and that would explain those errors. If so, it is a bug.
Howard,
The problem with Import has nothing to do with my own import code for my regexp question type. I have just now downloaded a fresh (from CVS) moodle head version 2007080900 and installed it on my local machine. I have added nothing to it.
I create just one course, one Admin user, when I go to that course, go to the Questions database and click on Import I get the error message I mentioned in my previous post. If I set debugging to max. reporting I get this extra warning:
Stack trace:
* line 5154 of lib\weblib.php: call to debugging()
* line 5215 of lib\weblib.php: call to error()
* line 73 of question\import.php: call to print_error()
There must be something wrong with the questions category handling in the current head version of Moodle, no?
Joseph
The problem with Import has nothing to do with my own import code for my regexp question type. I have just now downloaded a fresh (from CVS) moodle head version 2007080900 and installed it on my local machine. I have added nothing to it.
I create just one course, one Admin user, when I go to that course, go to the Questions database and click on Import I get the error message I mentioned in my previous post. If I set debugging to max. reporting I get this extra warning:
Stack trace:
* line 5154 of lib\weblib.php: call to debugging()
* line 5215 of lib\weblib.php: call to error()
* line 73 of question\import.php: call to print_error()
There must be something wrong with the questions category handling in the current head version of Moodle, no?
Joseph
Either Tim is right or the links are wrong on the tabs.
I had some bother with and (I *think*) fixed some mistakes in this new URL library stuff that appeared, but I didn't really understand it fully.
I had some bother with and (I *think*) fixed some mistakes in this new URL library stuff that appeared, but I didn't really understand it fully.
Another possibility is as follows. In question/import.php line 71 if I replace:
$validcats = question_category_options( $cmid, false, true );
with
$validcats = question_category_options( $courseid, false, true );
everything is working fine...
what is $cmid doing in 1.9 instead of $courseid (as in 1.8)?
Joseph
Yes, that's this Moodle_URL thing. It's some library that was added (I'm not sure who I'm insulting here, so better be careful) for constructing URLs for keeping state between pages (like the Quiz tabs). It had broken import and export completely though and I spent a morning shouting and swearing at the computer trying to make it work. There's no documentation (grrr!) that I can see and I don't want to have anything more to do with it.
Help!!
See:
http://docs.moodle.org/en/Development:lib/weblib.php_moodle_url
and lib/weblib.php around line 300.
In fact, I would like to see it put back how it was (in 1.8) because that worked and it was easy to understand.
Rant, rant, rant.
Help!!
See:
http://docs.moodle.org/en/Development:lib/weblib.php_moodle_url
and lib/weblib.php around line 300.
In fact, I would like to see it put back how it was (in 1.8) because that worked and it was easy to understand.
Rant, rant, rant.
Howard, if I compare question/import.php and question/export.php in 1.9 latest version, both have this line:
list($thispageurl, $courseid, $cmid, $cm, $module, $pagevars) = question_edit_setup();
If I try to echo or notify $thispageurl I get a blank page and no error message. What on earth is this $thispageurl meant to be like?
Anyway, in both question/import.php and question/export.php, the value of $cmid is 0. In export.php you do not use $cmid at all when testing the validity of category, so export works fine:
// check category is valid
$validcats = question_category_options( $course->id, true, false );
if (!array_key_exists( $categoryid, $validcats)) {
print_error( 'invalidcategory','quiz' );
}In import.php, however, as mentioned in my previous post, you do use $cmid: // check category is valid (against THIS courseid, before we change it)
$validcats = question_category_options( $cmid, false, true );
if (!array_key_exists( $params->category, $validcats )) {
print_error( 'invalidcategory', 'quiz' );
}
And of course, because $cmid = 0, the category is never valid, hence the error. Although I do not understand the relationship between this error and the "library for constructing URLs" mentioned in your post, I suggest doing the simple replacement mentioned in my post in import.php, i.e. using $courseid instead of $cmid in the category validity test. What do you think?
Joseph
PS.- Better swear at your computer than at real people. He/she?/it won't mind.
Keep up the good work.
Not for me it's not - $cmid comes through as the correct category.
Strange...
I haven't done an update for a couple of days, so I'll just run that in case something has changed somewhere.
EDIT:
Nope, still works for me!
Strange...
I haven't done an update for a couple of days, so I'll just run that in case something has changed somewhere.
EDIT:
Nope, still works for me!
The person to swear at about moodle_url is Jamie.
However, when you say 'the old way used to work', well yes, but only because I fixed a lot of bugs with it. It was a total nightmare to maintain. I think the new way is better, once you get your head round it. There are still bugs with some of the quiz reports that do things the old way, and at some point after the 1.9 release, I am looking forwards to switching them to moodle_url too.
But please do go on swearing about the lack of documentation. It should not really be that difficult to understand if explained properly.
However, when you say 'the old way used to work', well yes, but only because I fixed a lot of bugs with it. It was a total nightmare to maintain. I think the new way is better, once you get your head round it. There are still bugs with some of the quiz reports that do things the old way, and at some point after the 1.9 release, I am looking forwards to switching them to moodle_url too.
But please do go on swearing about the lack of documentation. It should not really be that difficult to understand if explained properly.
Yeh - at the risk of going on and on about it. Something reasonably fundamental like that needs proper documentation. It's not a "nice to have". It wasted a whole load of my time, and looks like I may still have not got it right.
To be fair, when Gustav moved everything to /question ages ago I spent weeks and weeks coming across broken links, so I do hope this is progress
To be fair, when Gustav moved everything to /question ages ago I spent weeks and weeks coming across broken links, so I do hope this is progress
Hmm... Not for me... I am conducting my tests on a clean new 1.9 install, where I create a couple of courses, a couple of quizzes in each, a couple of categories and a couple of questions in each category.
In import.php, right after
list($thispageurl, $courseid, $cmid, $cm, $module, $pagevars) = question_edit_setup(false, false);I add this line:
echo("HERE IS IMPORT.PHP courseid = $courseid; cmid = $cmid");In course ID 2, if I go directly to the questions bank and click on Import, then import.php echoes "HERE IS IMPORT PHP courseid = 2; cmid = 0".
In course ID 2, if I edit quiz ID 6, and, on the editing quiz screen I click on Import, , then import.php echoes "HERE IS IMPORT PHP courseid = 2; cmid = 6".
As far as I can gather, $cmid contains the id of the quiz being currently edited, not the course id. So in import.php, the test $validcats = question_category_options( $cmid, false, true ) can't return a correct list of categories in the actual course. I maintain that it does work however with $validcats = question_category_options( $courseid, false, true );
Can anyone confirm this?
Joseph
OK, with the recent changes to the question bank and category handling made by Jamie Pratt, my problem has disappeared. All is fine now using version 1.9 DEV 2007081001.
Joseph
Joseph
Can anybody point me at a questiontype plugin that works with HEAD?
I have committed the code, but it is largely untested as I am struggling to find a suitable test question.
I have committed the code, but it is largely untested as I am struggling to find a suitable test question.
How about Adriane's oderinging and ddmatching question types, posted to this forum recently?
The matching question probably doesn't need it (but of course still be fine for testing), since there is already import/export for it. I'll take a stab at the ordering question.
Another question type that works with HEAD is the file response question. It only has one extra database table, so the XML would be relatively simple.
I've attached the updated ordering question with XML import/export added. Because it is very similar to the matching question, it was very easy to do.
One question: I added a sanity check to make sure the answers are indeed a sequence of numbers. If the check fails, I'd rather have a different error message than "order is not supported in xml", but I wasn't sure what the best way to handle that would be. Would it be okay to add an error() instead of return false?
Oh cool... I'd started working on it myself. I'll not bother then
This is starting to sound like a moderate success!!
Let me have a think about the error thing tomorrow. There's a few things that needed sorted out in that department, but if you are in a hurry calling error yourself shouldn't break anything.
This is starting to sound like a moderate success!!
Let me have a think about the error thing tomorrow. There's a few things that needed sorted out in that department, but if you are in a hurry calling error yourself shouldn't break anything.
There's no hurry. Is there a defined GIFT format for ordering questions? I've looked around a little without finding one.
I don't know what you mean, sorry.
Adriane,
I expect the GIFT format only exists for existing, standard Moodle question types. For new, plugin types, you have to make your own. This may be easy for fairly simple question types and very difficult or even "dangerous" for complicated question types. Since I never ever use the GIFT format myself, I can't help. But are you sure it is needed anyway?
Joseph
I expect the GIFT format only exists for existing, standard Moodle question types. For new, plugin types, you have to make your own. This may be easy for fairly simple question types and very difficult or even "dangerous" for complicated question types. Since I never ever use the GIFT format myself, I can't help. But are you sure it is needed anyway?
Joseph
Oh I get it now!!
No, what-you-see-is-what-you-get with GIFT. I haven't added the hooks in yet for plugins but you would have to come up with your own format which was not incompatible with the existing ones.
The big hassle with GIFT is that the question type is "inferred" rather than nicely specified like XML. This has always been something of a challenge when adding new question types.
No, what-you-see-is-what-you-get with GIFT. I haven't added the hooks in yet for plugins but you would have to come up with your own format which was not incompatible with the existing ones.
The big hassle with GIFT is that the question type is "inferred" rather than nicely specified like XML. This has always been something of a challenge when adding new question types.
I thought that some people were still using GIFT to write and import questions since it's relatively simple to do in a text editor. The only proposal I've seen for ordering questions was for an ordering question written for 1.6 (post here, but I haven't actually tried to use it) and it was basically:
Question text. {>Item 1, Item 2, Item 3}
I think lots of people use GIFT.
Well if you want to have a go I have just added in the hooks to GIFT format. For import, you should expect the whole question text to come as $data, $question should have all the 'header' stuff done and $extra should contain all the stuff between the braces.
Well if you want to have a go I have just added in the hooks to GIFT format. For import, you should expect the whole question text to come as $data, $question should have all the 'header' stuff done and $extra should contain all the stuff between the braces.
Can I just say thanks Howard, Joseph and Adriane, for getting this system designed and implemented, and then adding it to your questions types.
I'll be down at your place of work on the 28th and 29th - you can buy me a Cappuccino 
The question type detecting in gift/format.php seems to default to SHORTANSWER, so I can't get it to fall through to the plugin method (at least not without modifying gift/format.php).
Ahh... you can see how well I tested that
I'll take a look!
I'll take a look!
I think what I need to do is for GIFT, pass the option to the plugins FIRST. You would have to promise not to grab any of the builtin question types though.
Obviously what I'm going to have to do is to document how it works for each format type and what exactly will be in the parameters passed.
I want to have a look through Jamie's category stuff before I change anything else though - so I'll let you know when it's done.
Obviously what I'm going to have to do is to document how it works for each format type and what exactly will be in the parameters passed.
I want to have a look through Jamie's category stuff before I change anything else though - so I'll let you know when it's done.
Howard - As you work on Jamie's new category stuff (excellent work IMO) as it seems pretty intuitive and flexible, were you going to include in the GIFT examples and documentation how to set the category of a question. I took a quick look at a GIFT export of questions and it gives a pretty good idea of what is happening. I was thinking of documenting some of that but if you are already in there I will let you do it but don't hesitate to let me know if you need a hand. Peace - Anthony
It's actually in the online help but, yes, it could do to be in the docs too.
Stuff that was identical to the help used to get deleted, I'm not sure if that has changed.
Stuff that was identical to the help used to get deleted, I'm not sure if that has changed.
Adriane,
That's the check moved to the beginning of the GIFT question type checks, so you have first try.
Obviously, it is vital that you return a false unless the question is *definitely* for you.
That's the check moved to the beginning of the GIFT question type checks, so you have first try.
Obviously, it is vital that you return a false unless the question is *definitely* for you.
I decided to use the following format. Since '>' is a special character, it should be escaped if it's used as part of the text somewhere. I check for the '>' at the very beginning and for at least three items, which are separated by '='.
::Ordering Question Name::This is an ordering question. {>
=aaa
=bbb
=ccc
}
I've attached the updated ordering question so you can try it out. I found a small bug in the updated gift/format.php due to the moved check, which is reported here. The existing question types fail right and left as it stands, but the plugin type works!
In reply to Howard Miller
Re: Proposal: Import and Export in Question Plugins
by Jean-Michel Védrine -
Hello Tim and howard,
I am trying to add xml import/export to the renderedmatch qtype in contrib CVS.
Of course as this qtype is very similar to core match qtype this is very easy, I have coded :
I see that in order qtype the test done is :
if (array_key_exists('horizontal', $data['#'])) {
Why is it done that way ?
Thanks a lot for your responses
By the way I never understood why renderedmatch was done as a new qtype rather than an option to core match qtype because it seems that it is only the same questiontype with a tabular view and the possibility to add distractors. But maybe I am missing something ?
I am trying to add xml import/export to the renderedmatch qtype in contrib CVS.
Of course as this qtype is very similar to core match qtype this is very easy, I have coded :
function import_from_xml($data, $question, $format, $extra=null) {
// get common parts
$question = $format->import_headers($data);
// header parts particular to matching
$question->qtype = 'renderedmatch';
$question->shuffleanswers = $format->getpath( $data, array( '#','shuffleanswers',0,'#' ), 1 );
// get subquestions
$subquestions = $data['#']['subquestion'];
$question->subquestions = array();
$question->subanswers = array();
// run through subquestions
foreach ($subquestions as $subquestion) {
$question->subquestions[] = $format->getpath( $subquestion, array('#','text',0,'#'), '', true );
$question->subanswers[] = $format->getpath( $subquestion, array('#','answer',0,'#','text',0,'#'), '', true);
}
return $question;
}
function export_to_xml($question, $format, $extra=null) {
$expout = '';
foreach($question->options->subquestions as $subquestion) {
$expout .= "<subquestion>\n";
$expout .= $format->writetext( $subquestion->questiontext );
$expout .= "<answer>".$format->writetext( $subquestion->answertext )."</answer>\n";
$expout .= "</subquestion>\n";
}
return $expout;
}
It works but I want to add a check to the import function to be sure to only parse the question if it is a renderedmatch question. What is the better vay to do this ? Can I test $question because I think qtype is already parsed when my import function is called ? Am I right ? Do you see a better way ? I see that in order qtype the test done is :
if (array_key_exists('horizontal', $data['#'])) {
Why is it done that way ?
Thanks a lot for your responses
By the way I never understood why renderedmatch was done as a new qtype rather than an option to core match qtype because it seems that it is only the same questiontype with a tabular view and the possibility to add distractors. But maybe I am missing something ?
In reply to Jean-Michel Védrine
Re: Proposal: Import and Export in Question Plugins
by Adriane Boyd -
I was thinking about it in terms of looking at the question data without knowing the type and horizontal was a distinguishing option, but I just looked again and (unsurprisingly) $data contains the type in $data['@']['type'], so it would have more sense to check that. (Dumb mistake on my part. Nothing to do with anything Howard or Tim has done.) I think I'll change it.
Adriane,
When I added the new Import/Export methods to my own REGEXP question type recently and looked at your own work I had indeed wondered why you were testing the horizontal parameter!
Joseph
When I added the new Import/Export methods to my own REGEXP question type recently and looked at your own work I had indeed wondered why you were testing the horizontal parameter!
Joseph
I've added some stuff to the documentation (see first post) to explain how to use properly for XML and GIFT.