Entitypoll

This module is moving poll functionality into entities. For now it should be mostly usable for developers, which may enjoy that a poll is an entity and choices are also entities (so they can have fields!). Poll types, widgets, results displays are abstracted, so you can make your own. I tried to make it in a way that should allow you to relatively easily implement any voting system you wish.

Simplest poll functionality that sums all votes per choice and displays their number should be working, but probably needs testing. What is also notable is that module should be already compatible with inline_entity_form with some limitations (multiple entitypolls in one inline entity formed field probably doesn't work, but I will fix it soon).

I need co-maintainers to move this forward because there is a lot of work needed to make this module production ready.

How does it work

I will try to describe the internal structure of the module, so you will have easier time when start working on it.

• Poll is an entity (entitypoll),
• Choice is an entity (entitypoll_choice),
• Choices are attached to polls obviously,
• Polls and choices can have their own types,
• Entitypoll have two different extra fields representing widget and results display,
  the same applies to entitypoll_choice .
• Extra fields for widget and results display can be individually configured per view mode (so you can display single poll in many ways, for example using different widgets). Configuration is accessible on given view mode page, in the extra field row.
  In configuration of widget you can choose a view mode for results - it is a view mode that a poll will switch to, if user already voted. So basically you can assume that one chosen view mode will be for voting widget and you will hide results extrafield there. And another will be for results, where you will hide widget extra field, and in configuration of widget in the first view mode - you will decide which it will be.
• When creating a type of poll you need to choose a voting type, a voting type is basically a convention for storing votes, and because all callbacks are on a widget/results display side, it can be treated like a category. So basically if one voting type has been chosen, administrator will be able to use only widgets and results displays which declares that they follow convention defined by a chosen voting type. This way in one type of a poll all votes will be gathered in the same way by different widgets and represented in the best way possible by available result displays. It should allow for some statistics gathering also.
• So if you want to have your own widget/results display you may define: hook_entitypoll_widget_info() , hook_entitypoll_results_display_info() and hook_entitypoll_voting_type_info() . More documentation on this will appear soon (hopefully).
• The last interesting element is that you have widget and result displays extra field on both levels - entitypoll and entitypoll_choice. It means that widget/results display can define a callbacks for both levels. For example it can have an overall callback rendering a rows of choices, and an element callback which will render single widget per choice (for example checkbox), which will be "movable" on choice view mode configuration page.

Not everything is yet decided but I believe that this method can be developed more to make a pretty complete Drupal voting solution. Any help (testing/patches) will be appreciated.

PS. I know there is not much documentation already, but I will work on it, and in meantime - I'm a living documentation so you can freely ask me about anything regarding this module. I will gladly help anyone who is willing to help pushing this module forward.