Refactor quiz content as entities

+1 Subscribed.

I would like to point out though, that there are instances where I attach custom fields to the actual quiz questions. Would this still be possible through entities?

Quiz maintainers - thoughts on this?

This is a pretty substantial change, but it would have some benefits.

ECK module would be a good starting point, new entities can be easily created with no coding

This is related to #1795014: no way to respond to quiz questions being added to a quiz

Reworking Questions to be its own entity type is definitely the way to go long term. That would make the questions much easier to extend in the future.

It would also probably make sense to drop the quiz_node_relationship table and instead integrate with http://drupal.org/project/entityreference module instead. This would also make things much more extensible.

Obviously those are both huge architectural changes.

This would be huge for quiz! Having quiz content as entities would make this module a little more manageable. I'm hoping to integrate this module on a site later this summer and this feature is a must, so I'll be watching this and hopefully I'll be able to contribute.

Marking as major as I agree with @michaelk that this is definitely the way to go and another major release of this module really shouldn't go without this architectural restructuring. I would be interested to hear what the maintainers have to say about this.

Given the changes that are coming in D8, I would be surprised to see any major refactoring that targeted D7.

I am not in any way associated with development on this project, but in assessing the resources required to refactor the code, if I was making decisions around this I would defer any refactoring for the D8 update.

*sigh* @bonobo You are probably right. This is a change that makes more sense for a Drupal 8 release.

@bonobo agree with you. several features introduced in Drupal 8 are backported to Drupal 7 (xautoload, backports, ...), leveraging them makes upgrading the module to drupal 8 much easier. also note that entities are first class citizens in Drupal 8 which makes this refactoring even more important.
Relying on EFQ is also another important change, as you may know Drupal 8 comes with EFQ2 which is much more flexible than EFQ1

What's the advantage of using entities instead of simply having quizzes and quiz questions be node content types with fields defined by the Fields API? I agree that the module shouldn't define its own schema, but I don't see the advantage of creating a new entity rather than using the pre-eisting node entity. It's already fully supported and integrates with Views, etc..

@colan There would be a ton of improvements that could be made by switching to Entities and Fields API. A lot of these improvements are things that will just automatically work once the module switches to Entities and Fields because all of Drupal 7 and beyond is based on Entities and Fields. Here are just a few things I can think of right now:

1. Views support out of the box for all Entities and Fields
2. More modular question system allowing for greater customization and reusability of components. Right now it is extremely difficult to do things like add an extra field to a question that displays when a student takes the quiz. This would be much easier if Entities and View Modes were used instead of content types and custom theme alters.
3. Eliminate custom code that is already handled by existing modules. The best example here is using the http://drupal.org/project/entityreference module (or a similar module) to handle associating questions with a Quiz.
4. More sustainable architecture. Everything else in Drupal has made the switch to using Entities and Fields. This module should be no different.

This definitely isn't a small change, but this is definitely the way to go for the next major release of this module.

@michaelk: Everything you say is true with nodes and fields so you didn't answer my question. Why bother creating custom entities, when we can simply add fields (through the Fields API) to nodes? Everyone seems to want to create custom entities when it's generally not necessary, and you're losing a lot of the native node functionality. You can add fields to the "node" entity. You don't have to build your own. If you do, you're going to waste a lot of time re-implementing functionality that nodes with fields gives you.

So yes, switch the data over to fields, but keep using nodes, not custom entities.

There are two important reasons,
- Performance, if all modules use nodes for storage even on small sites we will have serious performance issues. In Drupal 6 we didn't have much choices. But in Drupal 7 we have. We will also face a huge number of node types
- Forward compatibility, in Drupal 8 everything is entities even comments. So why didn't they make comments also nodes? it's possible there is in fact some modules that do that. There is also a module that turn taxonomies into nodes because of the limitation of taxonomies.
So nodes will be only used for generic site contents.
- Extensibility : quiz can provide some special characteristics to its entities like new properties without causing any interference to node . It can't be done on nodes because node is a generic entity if all modules add their own changes to nodes table it will be filled with lots of unrelated columns.

The whole thing is a design decision both works, but the approach is different. there is always workaround for everything the question are we doing it in the right way
It's like using EFQ or the old db_query, using namespaces or using prefix , Drupal introduces new API using it makes the code cleaner and more flexible. using entities opens up new possibilities for further development.

There are many good examples for this like the famous commerce module

Note that it's possible to access node entity via entity api as well, i've done it before. So the code can still work with nodes but makes it possible to switch to new entity type easily it transition can happen several stages. the main advantage as you mentioned is possibility of using Drupal fields

I hope i answered your quesiton

@colan OK, so let's set the Fields aspect of this aside since we agree on that.

You are definitely right that all of this can be done with nodes. That is what is happening right now, and it works OK. However, the question is not can it be done but rather should it be done that way or is there a better more maintainable and extensible way to do it. Right now the D7 version of this module is just a direct port of the D6 version of the module. It makes almost no use of any of the new architecture that was added in D7.

I am not entirely sure what you mean by "you're losing a lot of the native node functionality". Pretty much all of the functionality of nodes is based purely on the fact that they are Entities in D7, so anything that is an Entity will have basically the same capabilities as a node. Just look at Users in D7, that are fieldable and have largely the same functionality as nodes. Do you have specific examples of capabilities that would be lost with a migration from nodes to Entities?

I definitely agree that it will take a lot of time to make this migration. I suspect that is the only reason it hasn't happened already. However, that time will not be spent "re-implementing functionality that nodes with fields gives you". That time will mostly be spent reworking the Question architecture to be built on top of Entities instead of nodes. This has huge advantages for the future as this is the way the entire Drupal architecture is going. There is a reason why basically every other module out there has made the switch to being built on top of Entities instead of Nodes.

A lot of the things I described would be much easier with an Entity type for Questions because you could implement things once for that Question Entity type. This would greatly simplify a lot of the crazy code in the Question Types with all of the different classes that it has for defining different things related to the Question content types. This code is a maintenance and extensiblity nightmare. This code is all just a direct port from D6 which didn't have the benefits of Entity types. A lot of this code can just be completely eliminated as it just replicates existing functionality of Entities and Fields.

View Modes is a good example of something that would not work well when built on top of nodes. You really don't want to add View Modes for Quiz Taking and Quiz Feedback to the node entity because then all nodes will have these View Modes that don't really apply to them. You can definitely do this using nodes (I know because I just had to do it for a project with Quiz module), but it is far from ideal. Also, Quiz module doesn't even make proper use of View modes currently. It has a ton of hacky code that makes Questions completely unextensible without hacking the module itself to fix the issue. I have submitted a patch that attempts to mitigate this issue (http://drupal.org/node/1120016), but making full use of the Entity architecture would solve this issue much better.

There are so many bugs that would be fixed just by switching to an Entities and Fields architecture instead of all of the custom code that is currently in the module. The less code you have to maintain the less bugs there will be in that code, and the more you build on top of the core Drupal architecture the more contrib modules will be compatible with your module. Here are just a couple bugs I have specifically run into that would be solved purely by making proper use of Entities and Fields:

• http://drupal.org/node/1843128
• http://drupal.org/node/1845208
• http://drupal.org/node/1857648

Gentlemen,

Those are good points; I"m convinced. Thank you.

I was worried that we'd have to reimplement functions like "node_save()" in out new entity, but even if we do, this seems to be minor compared to the benefits.

how can i make entities in my object orient programming project for making quiz contester??

Duplicate to #2355375

Proper Drupal internal link: #2355375: Convert Quiz to D7 Entity API.