Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Ok, this is just a suggestion!
qcollection and quiz has a lot in common, but are separate modules. One of the original reasons was not to interfere with GSOC AFAIK.
Now GSOC is over. Should we merge qcollection and quiz?
qcollection could handle the view of the quiz. We have a separate take quiz tab, export tab, import tab etc.
Any thoughts?
As I said this is just a suggestion. I haven't studied qcollection, and I do think there are many good reasons to keep quiz and qcollection separate that I'm not aware about, but there are also many good reasons to combine them. And if we should combine them we should do it now before ppl install qcollection as a separate module.
I hope we can discuss this issue here. If for no other purpose then to document why we should keep qcollection and quiz separate.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | qcollection_last.tar_.gz | 5.97 KB | falcon |
Comments
Comment #1
turadg commentedGSoC was the impetus for the new qcollection type, but it's still useful. I think we should explore the relationship of these two types though.
'quiz' does lots of stuff that 'qcollection' isn't concerned with and it has data overhead for that. E.g. availability start and stop date. For that reason, they should at least have different data tables. We could make them the same node type and let the code manage those extra data based on parameters of the node. I'm willing to consider that.
I think we should consider other collection types, like homework. Homework could be implemented as a quiz with certain settings, but like the quiz questions, I think we'd be better off with some inheritance. We could have a qcollection superclass, with quiz and homework as subclasses.
Whether we do any of this, I think it should come after 4.0. Let's get 4.0 out since it has so many new features and 3.x is having some stability issues. It won't be hard to convert qcollection and quiz nodes to whatever else.
Comment #2
falcon commentedRe: "It won't be hard to convert qcollection and quiz nodes to whatever else."
To some extent I agree. It is easy to make quiz work if we rename the modules. By renaming modules we might create some unexpected issues for our users though, and those issues are hard if not impossible for us to fix although they might be very easy for the users to fix
A couple of examples I can think of:
- form_alter and nodeapi hooks changing the behavior of the renamed modules will stop working if the hooks depend on the name of the module(Impossible for us to fix.)
- url aliases based on the name of the module might become meaningless. Some urls might even stop working.
We should try to avoid renaming the modules.
Re: "I think we'd be better off with some inheritance. We could have a qcollection superclass, with quiz and homework as subclasses."
I don't have a strong opinion about this, but I do think that if we are to put as much code as possible into classes we should do that when converting to D7.
We can do kind of inheritance the "drupal OO way" as well by using hooks for instance. Using classes and interfaces are of course cleaner, but I think the drupal way performs better. At least in D6.
Temporary conclusion: We won't merge quiz and qCollection. We do want to refactor quiz and qCollection in some other way, but not for quiz 4.x?
Comment #3
turadg commentedI agree with your conclusion. I'll mark this as postponed.
For when we do pick this up again:
Don't we already break form_alter() with changes to the forms? breaking API compatibility in a major version release is okay, as long as we provide an upgrade path. that is the Drupal norm, I believe.
Url aliases based on the name of the module, you mean with a module token in the url? I haven't seen that, only type tokens. We can change the module names without changing the type names. Module names are independent of node type names.
We can also refactor the organization of the module and type implementations without breaking their contracts.
I don't understand with the "Drupal way" would perform better than using classes and interfaces. I also don't see them as mutually exclusive. We may have different conceptions of this in mind. When we pick this up again, let's make sure we're on the same page.
Comment #4
falcon commentedRe #13:
form_alter often don't care about the content of the form. It often just adds something to it, removes something from it..
I'm aware that node type names are defined in the code, but I don't think we should have a node type name with a different meaning than the module name if it can be avoided.
The point with these two examples was to show that we causes trouble to other developers by changing module names. If we could have avoided it it would be good. There are several more examples. For instance if someone is using some of our tables directly they will have to do extra work when the tables changes names(and gets refactored). (Even though we could keep the table names it wouldn't manke much sense to do it) Also we would save ourselves alot of work if we did the merge now because if we are to do it later we will have to make update functions in addition to the other work.
The drupal way performs better because the drupal way have to be followed anyway, and the classes and instances are an extra layer of abstraction on top of drupal adding extra overhead. It could probably be reduced by using static references to the instances or something, but it still adds extra overhead. I don't know how big the overhead is as I don't know how efficient php is at instantiating classes.
Still, I don't think we will have any overwhelming problems merging qCollection and quiz. For the time beeing my employer are not planning to make use of qCollection so I won't be able to offer much help merging it into quiz, but I do think it would have been great to have all question collections as one node type with both export, import and quiz taking features.
Comment #5
falcon commentedComment #6
turadg commentedI'm beginning to rethink the necessity of a qcollection node type. Most of the requirements I made it for could be achieved by some settings on the quiz node. Basically then "quiz" would be any list of questions/items. Options on it would specify whether it can be taken directly or serves only as a simple list.
Other reasons I'm inclined to consider getting rid of qcollection as a separate type:
- developments on 'quiz' that 'qcollection' didn't get
- views still not working on 'qcollection' and I don't have the expertise with Views to do it
- other qcollection use cases I have can be achieved with taxonomies and a view on questions (#627058: View for questions)
Comment #7
falcon commentedI hope you are able to find the time needed to do this. I don't think I can. I only have one day to work on Quiz this week, and no signs indicates that next week will be any better :/
Comment #8
turadg commentedI have zero days to work on Quiz this week. I may find it next week or the week after.
The first issue is how this should work. Anyone who is using qcollection now, please speak up.
The reasons I made qcollection were:
1) avoid conflicting with Sivaji's work on 'quiz' type during his GSoC
2) have a view of a list of questions that doesn't assess those questions
3) allow different permissions on qcollection usage
4) have a simplified editing UI and database storage without all the quiz-taking parameters
#1 is no longer applicable.
#2 can be implemented with new default views and tabs on 'quiz'. E.g. default view shows information about the quiz. The quiz-taking would move into another tab "Take". "Manage questions" would stay as is. A new tab "View questions" would show the questions in a list, as qcollection "List items" does now. Listing items and taking a quiz would be different permissions (e.g. for a teacher and student role).
#3 would be lost, but maybe it's not important?
#4 could be handled through theming and a new field for the mode of editing, e.g. "interactive quiz", "printed quiz", "homework assignment", "collaborative question list", ??
Comment #9
falcon commentedqcollection has been deleted.
For our own convenience if and when we need to add it back again, or need some of the code, I have attached the last version here.