Vote | Drupal.org

Experimental project

This is a sandbox project, which contains experimental code for developer use only.

Description

Vote defines a new entity type (vote). Votes can be cast on ANY entity type that "your drupal" knows (even on "vote" itself).

Vote provides "functions" and "voting types":

A function basically provides a handler which defines how and where a function stores its result values. Each function can have its own db table to store the results in order to allow more complex functions to break the INTEGER barrier which the default result table uses for its results.

A voting type basically combines a group of functions. For example a voting type "percent" would combine the functions "average" and "count" while "points" would also use the "sum" function.

Voting types and functions both use a set of classes as handlers to provide custom option forms and advanced (and individual) functionality for each function / voting type. The functions handler -for example- makes it possible to store function result values in seperate db tables with different table structures.

Votes are being organized by voting pools (analogous to node types). A voting pool could for example be overall or fish. Each voting pool uses one of the voting types (for example a voting pool named overall could be of type percent) and thus is allowed to use whatever functions that voting type provides. Since overall is of type percent it would -for example- be allowed to use count and average. In the administrative UI the user is now able to check / uncheck those functions and (if checked) chose from the custom settings that those functions provide with their handler classes (the UI is similiar to the Text Formats UI in core).

Adding new votes causes the module to add (or update) an entry to a "schedule" table in the database which handles the recalculation of results. Those entries contain the information about the "constellation" that was changed. A constellation is a pool and the entity_type and entity_id that we voted on. When cron is run (if recalculation is set to cron) or on hook_exit (if set to real-time calculation) the schedule is being worked (beginning with the oldest entry) using a looping mechanism and some more functionality to make sure the page doesn't time out during recalculation. When a "constellation" of votes ("pool", "entity_type", "entity_id") have been recalculated the entry is being removed from the schedule.

The vote storage is 100% pluggable. Contrib modules can add custom storage methods (for example for mongodb) by providing all the functions that act on the vote table (for example vote_save => vote_save_mongodb). However, the vote entity handling needs to be covered by the custom storage method too (custom entity controller class with -at least- ::load and ::buildQuery methods).