Shortanswer question development - Revision history

Oasychev: /* Interface */

2008-11-28T18:23:21Z

Interface

← Older revision		Revision as of 18:23, 28 November 2008
Line 31:		Line 31:
	*validation of the answer that use wildcards will be somewhat problematic, the only way we can validate it is assuming wilcard to be literally , and validate this option only (but removing any escapes before *).		*validation of the answer that use wildcards will be somewhat problematic, the only way we can validate it is assuming wilcard to be literally , and validate this option only (but removing any escapes before *).
	** I would happily drop using wildcard syntax in answer field at least in non-compatibility mode to allow better validation, but it may cause some inconvenience to the teachers, who use wildcards but didn't know about regexes for now (thought current syntax cause inconvenience for the people, that doesn't know what wilcard (and escaping) is and whant to have * in their answers, and this may be more common situation). In non-compatibility mode answer field changes it's meaning and wildcards are no longer welcome there; to avoid any troubles they can be left to themselves in compatibility mode.		** I would happily drop using wildcard syntax in answer field at least in non-compatibility mode to allow better validation, but it may cause some inconvenience to the teachers, who use wildcards but didn't know about regexes for now (thought current syntax cause inconvenience for the people, that doesn't know what wilcard (and escaping) is and whant to have * in their answers, and this may be more common situation). In non-compatibility mode answer field changes it's meaning and wildcards are no longer welcome there; to avoid any troubles they can be left to themselves in compatibility mode.


			Well, all this fuss about several modes and different working fields will probably be quite confusing to the users. An alternative is to always use rules field, but, for the sake of compatibility, upgrade all questions to the new form, and give a call to create/edit question compatibility mode, so that questions in old format will be automatically translated to the new format. The only possible problem there may be with close question, if it try to reconstruct the question syntax from database fields, this needs further investignation.

	== Syntax ==		== Syntax ==

Oasychev at 22:28, 27 November 2008

2008-11-27T22:28:49Z

← Older revision		Revision as of 22:28, 27 November 2008
Line 1:		Line 1:
			{{Moodle 2.0}}

	Following discussion about regular expressions question types in Moodle Tim Hunt suggested a development of short answer question that allows the teacher to use a number of rules with different types (matches string, not matches string, contains the words, matches regexp an so on). The idea is good, though it needs further discussion.		Following discussion about regular expressions question types in Moodle Tim Hunt suggested a development of short answer question that allows the teacher to use a number of rules with different types (matches string, not matches string, contains the words, matches regexp an so on). The idea is good, though it needs further discussion.

Oasychev: /* Interface */

2008-11-27T19:41:04Z

Interface

← Older revision		Revision as of 19:41, 27 November 2008
Line 28:		Line 28:
	*answer filled, rules filled - rules used to test response, answer used to display the correct answer (there must be at least one such answer with 100% grade in question in order to display the correct answer); there is possibility of validation of the answer against rules		*answer filled, rules filled - rules used to test response, answer used to display the correct answer (there must be at least one such answer with 100% grade in question in order to display the correct answer); there is possibility of validation of the answer against rules
	*validation of the answer that use wildcards will be somewhat problematic, the only way we can validate it is assuming wilcard to be literally , and validate this option only (but removing any escapes before *).		*validation of the answer that use wildcards will be somewhat problematic, the only way we can validate it is assuming wilcard to be literally , and validate this option only (but removing any escapes before *).
	** I would happily drop using wildcard syntax in answer ~~at all (~~at least in non-compatibility mode~~) in favour of regexes, and writing an upgrade script would be easy~~, but it may cause some inconvenience to the teachers, who use wildcards but didn't know about regexes for now (thought current syntax cause inconvenience for the people, that doesn't know what wilcard (and escaping) is and whant to have * in their answers, and this may be more common situation)		** I would happily drop using wildcard syntax in answer field at least in non-compatibility mode to allow better validation, but it may cause some inconvenience to the teachers, who use wildcards but didn't know about regexes for now (thought current syntax cause inconvenience for the people, that doesn't know what wilcard (and escaping) is and whant to have * in their answers, and this may be more common situation). In non-compatibility mode answer field changes it's meaning and wildcards are no longer welcome there; to avoid any troubles they can be left to themselves in compatibility mode.

	== Syntax ==		== Syntax ==

Oasychev: /* Implementation */

2008-11-22T10:06:26Z

Implementation

← Older revision		Revision as of 10:06, 22 November 2008
Line 90:		Line 90:

	== Implementation ==		== Implementation ==
	The database - there is a need to add new field to question_answers table, a text field 'rules'. It must probably be an empty string by default, to retain compatibility with another questions that use this table.		The database - there is a need to add new field to question_answers table, a text field 'rules'. It must probably be an empty string by default, to retain compatibility with another questions that use this table. If plan 1 for test_response function will be accepted (see below), than new field in db must probably have some more generic name, any question may need something more than an answer, grade and feedback. Text field is a good choice for any additional information field.

	Question editing form must get a new field to enter this, and more complicated validation too - if both answer (without wildcard) and rules is filled we can test an answer against the rules.		Question editing form must get a new field to enter this, and more complicated validation too - if both answer (without wildcard) and rules is filled we can test an answer against the rules.

Oasychev: /* Interface */

2008-11-18T13:31:24Z

Interface

← Older revision		Revision as of 13:31, 18 November 2008
Line 26:		Line 26:
	*answer filled, rules empty - compatibility mode, works just as now;		*answer filled, rules empty - compatibility mode, works just as now;
	*answer empty, rules filled - rules used to test response;		*answer empty, rules filled - rules used to test response;
	*answer filled, rules filled - rules used to test response, answer used to display the correct answer (there must be at least one such answer with 100% grade in question in order to display the correct answer); there is possibility of validation if the answer against rules		*answer filled, rules filled - rules used to test response, answer used to display the correct answer (there must be at least one such answer with 100% grade in question in order to display the correct answer); there is possibility of validation of the answer against rules
	*validation of the answer that use wildcards will be somewhat problematic, the only way we can validate it is assuming wilcard to be literally , and validate this option only (but removing any escapes before *).		*validation of the answer that use wildcards will be somewhat problematic, the only way we can validate it is assuming wilcard to be literally , and validate this option only (but removing any escapes before *).
			** I would happily drop using wildcard syntax in answer at all (at least in non-compatibility mode) in favour of regexes, and writing an upgrade script would be easy, but it may cause some inconvenience to the teachers, who use wildcards but didn't know about regexes for now (thought current syntax cause inconvenience for the people, that doesn't know what wilcard (and escaping) is and whant to have * in their answers, and this may be more common situation)

	== Syntax ==		== Syntax ==

Oasychev: /* Implementation */

2008-11-18T13:26:19Z

Implementation

← Older revision		Revision as of 13:26, 18 November 2008
Line 97:		Line 97:
	*'''test_response''' and '''check_response''' - to make new functionality work		*'''test_response''' and '''check_response''' - to make new functionality work
	**there is a bug in shortanswer compare_responses function now (see MDL-17247); it need to be fixed and dependence of check_response on compare_responses removed to make all functions work as intended; I can do it if Tim is busy. check_response should call test_response, not compare_responses		**there is a bug in shortanswer compare_responses function now (see MDL-17247); it need to be fixed and dependence of check_response on compare_responses removed to make all functions work as intended; I can do it if Tim is busy. check_response should call test_response, not compare_responses
	**the most obnoxious thing is an interface of '''test_responce''', which is based on the assumption, that answer is enought to test response (which leave us without rules). There are two ways to deal with this: ~~either introduce new argument (breaking the interface~~ of ~~question type with need to~~ change (~~thought simple~~) ~~all questiontypes using it - not~~ very ~~good option really) or try~~ to ~~get rules via $question or $state, if this is possible unambiguously. There is a third way thought~~ - ~~actually well may be the best - question type class can add~~ rules to an answer (separating them with line break) before ~~calling~~ test_response.		**the most obnoxious thing is an interface of '''test_responce''', which is based on the assumption, that answer is enought to test response (which leave us without rules). There are actually two ways to deal with this (this decision is for Tim probably):
			**# change asnwer to full subquestion object - this will cause breakage for 3d-party modules, but it is sort of expected thing on major version change (this development probably must be targeted to 2.0 anyway) and will be very easy to fix - but leave us very broad possibilities for future development
			**# append rules to an answer (separating them with line break) before the call - this would be some sort of workaround, but we still need to modify all calls (and ensure that close doesn't create answers with line breaks), and our options for future will be still narrowed be test_response interface

	There are also two functions that need modification in backup/restore libs: '''question_backup_answers''' and '''question_restore_answers''', so they can handle a new field.		There are also two functions that need modification in backup/restore libs: '''question_backup_answers''' and '''question_restore_answers''', so they can handle a new field.

	New function, that'll test response against the rules must, probably, be static function of '''question_shortanswer_qtype''' class so validator can use it without duplicating code. test_response will internally call this function.		New function, that'll test response against the rules must, probably, be static function of '''question_shortanswer_qtype''' class so validator can use it without duplicating code. test_response will internally call this function.

Oasychev: /* Syntax */ -first proposal

2008-11-17T19:31:09Z

Syntax: -first proposal

@@ Line 31: / Line 31: @@
 == Syntax ==
 The syntax of pseudocode should be simple, both for entering and parsing, and allows shorthands for quick typing (maybe these shorthands should automatically be changed on saving question). For example full negation should be 'not' and shorthand just '!'
 == Compatibility issues ==

Oasychev: /* Implementation */ - test_response issue

2008-11-17T19:20:29Z

Implementation: - test_response issue

← Older revision		Revision as of 19:20, 17 November 2008
Line 80:		Line 80:
	*'''test_response''' and '''check_response''' - to make new functionality work		*'''test_response''' and '''check_response''' - to make new functionality work
	**there is a bug in shortanswer compare_responses function now (see MDL-17247); it need to be fixed and dependence of check_response on compare_responses removed to make all functions work as intended; I can do it if Tim is busy. check_response should call test_response, not compare_responses		**there is a bug in shortanswer compare_responses function now (see MDL-17247); it need to be fixed and dependence of check_response on compare_responses removed to make all functions work as intended; I can do it if Tim is busy. check_response should call test_response, not compare_responses
			**the most obnoxious thing is an interface of '''test_responce''', which is based on the assumption, that answer is enought to test response (which leave us without rules). There are two ways to deal with this: either introduce new argument (breaking the interface of question type with need to change (thought simple) all questiontypes using it - not very good option really) or try to get rules via $question or $state, if this is possible unambiguously. There is a third way thought - actually well may be the best - question type class can add rules to an answer (separating them with line break) before calling test_response.

	There are also two functions that need modification in backup/restore libs: '''question_backup_answers''' and '''question_restore_answers''', so they can handle a new field.		There are also two functions that need modification in backup/restore libs: '''question_backup_answers''' and '''question_restore_answers''', so they can handle a new field.

	New function, that'll test response against the rules must, probably, be static function of '''question_shortanswer_qtype''' class so validator can use it without duplicating code. test_response will internally call this function.		New function, that'll test response against the rules must, probably, be static function of '''question_shortanswer_qtype''' class so validator can use it without duplicating code. test_response will internally call this function.

Oasychev: /* Syntax */

2008-11-17T13:43:53Z

Syntax

← Older revision		Revision as of 13:43, 17 November 2008
Line 30:		Line 30:

	== Syntax ==		== Syntax ==
	The ~~place~~ for ~~syntax proposals~~.		The syntax of pseudocode should be simple, both for entering and parsing, and allows shorthands for quick typing (maybe these shorthands should automatically be changed on saving question). For example full negation should be 'not' and shorthand just '!'

	== Compatibility issues ==		== Compatibility issues ==

Oasychev: /* Interface */

2008-11-17T13:30:07Z

Interface

← Older revision		Revision as of 13:30, 17 November 2008
Line 27:		Line 27:
	*answer empty, rules filled - rules used to test response;		*answer empty, rules filled - rules used to test response;
	*answer filled, rules filled - rules used to test response, answer used to display the correct answer (there must be at least one such answer with 100% grade in question in order to display the correct answer); there is possibility of validation if the answer against rules		*answer filled, rules filled - rules used to test response, answer used to display the correct answer (there must be at least one such answer with 100% grade in question in order to display the correct answer); there is possibility of validation if the answer against rules
	*validation of the answer that use wildcards will be somewhat problematic, ~~maybe there will~~ be ~~no validation for them right now - or maybe there must be no wildcards at all if rules is defined~~, ~~so that answer can be safely displayed to the student~~ (~~right now there is a potential leak if some students know about wildcards in answer, as they always displayed as~~ ~~in correct answers~~)		*validation of the answer that use wildcards will be somewhat problematic, the only way we can validate it is assuming wilcard to be literally , and validate this option only (but removing any escapes before *).

	== Syntax ==		== Syntax ==