Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Talk:Question Engine 2:Design: Difference between revisions

From MoodleDocs
(→‎Some thoughts: - new thought added)
No edit summary
Line 4: Line 4:
# question_states table store state as an Integer. However, some complex qtypes (like our planned training) may want to have custom sub-states (especially for Incomplete state). They can be stored in question_responses but that is somewhat inconsistent. What do you think about adding a field for substate in questions_states or making state field a float, so substates can be after comma while states before?
# question_states table store state as an Integer. However, some complex qtypes (like our planned training) may want to have custom sub-states (especially for Incomplete state). They can be stored in question_responses but that is somewhat inconsistent. What do you think about adding a field for substate in questions_states or making state field a float, so substates can be after comma while states before?
# question_responses table structure is generic and can be used by many other modules (like assignment). I think that it will may be good to have a library of functions that work with such tables.
# question_responses table structure is generic and can be used by many other modules (like assignment). I think that it will may be good to have a library of functions that work with such tables.
# Also I wonder is naming convention (!, _) a good way to resolve conflicts in the names in question_responses table, or an additional field for the source of data (i.e. qtype, interaction model etc) would be better. The later is definitely more scalable IMHO.


Also I wonder is naming convention (!, _) a good way to resolve conflicts in the names in question_responses table, or an additional field for the source of data (i.e. qtype, interaction model etc) would be better. The later is definitely more scalable IMHO.
--[[User:Oleg Sychev|Oleg Sychev]] 12:48, 3 October 2009 (UTC)
 
: 1. The purpose of the state field in the the question_states table is for communication. Communication between particular question types/interaction modules, and whatever is using the question engine. That is why I tried to have the smallest possible number of states. The less the outside world knows, the more freedom the question engine has.
 
: So, I expect particular questions will do different things with the complete and incomplete states. For example a maths question that needed the student to type a complex syntax might use the Incomplete state for both the initial situation where the answer is blank, but also if the student types an answer that cannot be validated. However, all the quiz needs to know (for the navigation and the summary page in 2.0) is to tell the student that they have not finished working on that question.
 
: Similarly, in the new Interactive mode, you might image in needs a 'Try again' state, but actually that is another Incomplete state.
 
: So, actually, fewer states are more flexible.
 
: 2. That structure is indeed generic. In fact Moodle already has similar other structures, for example in the config and config_plugins tables. The they key point about this instance of this table is that it is linked to the question states, and the way it will be used. By the way, this table will have a lot of rows. It is essential that the API for accessing it is optimised for the kind of access that is done during large quiz attempts.
 
: 3. The reasons for this simple approach to naming is that when the data is loaded from the database, the responses become a PHP array on the state. (I hope you realise that this design page is still incomplete, which is why this is not yet explained.) Obviously arrays can only have keys and values, which is why the only way to avoid collisions is a naming convention. The other reason is, as I said, question_responses is critical for performance. Therefore, the fewer columns there, the better.
 
: Also, student input, extra info from the question type, and extra information from the interaction model are the only things that should be storing things in this table, and it is easy to distinguish three things with a prefix.
 
: --[[User:Tim Hunt|Tim Hunt]] 19:05, 3 October 2009 (UTC)


Also some ideas that may not be directly related to it:
Also some ideas that may not be directly related to it:
# I'm long dreaming about an ability to tag question categories (maybe quesitons too), and then filter them by that tags on various occasions (from listing and editing trought random questions to import/export). Tree hierarchy isn't sufficient. I have a category tree organizied by topic in the course, but then on the each topic I have one demo, several training and many control categories. And sometimes I need something to be done with all demo categories or something like that.
# I'm long dreaming about an ability to tag question categories (maybe quesitons too), and then filter them by that tags on various occasions (from listing and editing trought random questions to import/export). Tree hierarchy isn't sufficient. I have a category tree organizied by topic in the course, but then on the each topic I have one demo, several training and many control categories. And sometimes I need something to be done with all demo categories or something like that.
# there are several questions (in core and not) - shortanswer, numerical, calculated - that shares a model of having several answers, with finding a matching one by some rules (multichoice partialy fits there in  single choice mode). What do you think about abstracting it in abstract_multianswer qtype (oh, existing multianswer probably better to be known as multiquestion)? It isn't really good to place functions, that similar to all them, in root question type class.
# there are several questions (in core and not) - shortanswer, numerical, calculated - that shares a model of having several answers, with finding a matching one by some rules (multichoice partialy fits there in  single choice mode). What do you think about abstracting it in abstract_multianswer qtype (oh, existing multianswer probably better to be known as multiquestion)? It isn't really good to place functions, that similar to all them, in root question type class.
# Also I'm wondering, for questions with sub-states in Incomplete state, would it be easy to create a Replay on reviewing? This should be taken into consideration too IMHO.


Also I'm wondering, for questions with sub-states in Incomplete state, would it be easy to create a Replay on reviewing? This should be taken into consideration too IMHO.
--[[User:Oleg Sychev|Oleg Sychev]] 12:48, 3 October 2009 (UTC)
--[[User:Oleg Sychev|Oleg Sychev]] 12:48, 3 October 2009 (UTC)
: 1. The question bank is indeed a completely different issue.
: 2. I hope the new code will make it easier to make good use of inheritance between question types. Yes, more abstract classes is probably good. Both the one you suggest, and also a base class for t/f and multichoice.
: 3. Yes, with the new question engine, anything can be replayed. (Just replay the sequence of student input, which is all in the database.)
: --[[User:Tim Hunt|Tim Hunt]] 19:05, 3 October 2009 (UTC)

Revision as of 19:05, 3 October 2009

Some thoughts

Some ideas from reading this proposal:

  1. question_states table store state as an Integer. However, some complex qtypes (like our planned training) may want to have custom sub-states (especially for Incomplete state). They can be stored in question_responses but that is somewhat inconsistent. What do you think about adding a field for substate in questions_states or making state field a float, so substates can be after comma while states before?
  2. question_responses table structure is generic and can be used by many other modules (like assignment). I think that it will may be good to have a library of functions that work with such tables.
  3. Also I wonder is naming convention (!, _) a good way to resolve conflicts in the names in question_responses table, or an additional field for the source of data (i.e. qtype, interaction model etc) would be better. The later is definitely more scalable IMHO.

--Oleg Sychev 12:48, 3 October 2009 (UTC)

1. The purpose of the state field in the the question_states table is for communication. Communication between particular question types/interaction modules, and whatever is using the question engine. That is why I tried to have the smallest possible number of states. The less the outside world knows, the more freedom the question engine has.
So, I expect particular questions will do different things with the complete and incomplete states. For example a maths question that needed the student to type a complex syntax might use the Incomplete state for both the initial situation where the answer is blank, but also if the student types an answer that cannot be validated. However, all the quiz needs to know (for the navigation and the summary page in 2.0) is to tell the student that they have not finished working on that question.
Similarly, in the new Interactive mode, you might image in needs a 'Try again' state, but actually that is another Incomplete state.
So, actually, fewer states are more flexible.
2. That structure is indeed generic. In fact Moodle already has similar other structures, for example in the config and config_plugins tables. The they key point about this instance of this table is that it is linked to the question states, and the way it will be used. By the way, this table will have a lot of rows. It is essential that the API for accessing it is optimised for the kind of access that is done during large quiz attempts.
3. The reasons for this simple approach to naming is that when the data is loaded from the database, the responses become a PHP array on the state. (I hope you realise that this design page is still incomplete, which is why this is not yet explained.) Obviously arrays can only have keys and values, which is why the only way to avoid collisions is a naming convention. The other reason is, as I said, question_responses is critical for performance. Therefore, the fewer columns there, the better.
Also, student input, extra info from the question type, and extra information from the interaction model are the only things that should be storing things in this table, and it is easy to distinguish three things with a prefix.
--Tim Hunt 19:05, 3 October 2009 (UTC)

Also some ideas that may not be directly related to it:

  1. I'm long dreaming about an ability to tag question categories (maybe quesitons too), and then filter them by that tags on various occasions (from listing and editing trought random questions to import/export). Tree hierarchy isn't sufficient. I have a category tree organizied by topic in the course, but then on the each topic I have one demo, several training and many control categories. And sometimes I need something to be done with all demo categories or something like that.
  2. there are several questions (in core and not) - shortanswer, numerical, calculated - that shares a model of having several answers, with finding a matching one by some rules (multichoice partialy fits there in single choice mode). What do you think about abstracting it in abstract_multianswer qtype (oh, existing multianswer probably better to be known as multiquestion)? It isn't really good to place functions, that similar to all them, in root question type class.
  3. Also I'm wondering, for questions with sub-states in Incomplete state, would it be easy to create a Replay on reviewing? This should be taken into consideration too IMHO.

--Oleg Sychev 12:48, 3 October 2009 (UTC)

1. The question bank is indeed a completely different issue.
2. I hope the new code will make it easier to make good use of inheritance between question types. Yes, more abstract classes is probably good. Both the one you suggest, and also a base class for t/f and multichoice.
3. Yes, with the new question engine, anything can be replayed. (Just replay the sequence of student input, which is all in the database.)
--Tim Hunt 19:05, 3 October 2009 (UTC)