Vote (VotingAPI on steroids)

Sorry, I forgot one screenshot ;)

The documentation is following asap (laying my hands on that right now). The basic data handling of this module seems to be nearly finished now so I am going to document that and afterwards start working on the frontend (node, fields, views and rules implementation).

Documentation for vote.module is done (which covers most of the functions that are of interest ;) ) .... except some extended explanation on the hooks, but thats going into vote.api.php anyhow!

UPDATE:

I created a drupal.org sandbox and a associated git repository.

SANDBOX: http://drupal.org/sandbox/sumsi/1074206
GIT: http://drupalcode.org/sandbox/sumsi/1074206.git

I just spoke with eaton. He had to leave again and we couldn't finish our conversation but will look into this and it seems like we are gonna end up with some sort of collaboration.

Concerning development: The admin UI also supports result overview pages for every function. Custom functions can reuse the functionality of the default result pages to create custom overviews. (I already did that for the score overview for pools of type "options"). All in all its going really well!

I set up a fresh drupal installation on one of my servers and installed this module. If you want to play with it just text me on IRC (sumsi). I will give you the URL + Login.

Removed.

Thanks joachim! Also, you really brought something up there. How would we migrate the old data (which is stored slightly different than it used to be stored with VotingAPI) into "Vote". Pretty easily I say! It should be quite easy to create a batch process that fetches all data from the old VotingAPI (votes) table and groups them into pools (and automaticaly creates those pools -> pools = tags). The only thing that could get us into trouble there would be the fact that with the old VotingAPI one tag name could be used for multiple value types ("Vote" has a unique relationship between "pool" and "value type"). This would mean that we would have to also group the old votes by value type and make sure that we assign a new pool name in case a tag is being used for multiple vote types. I think I am going to create that migration tool later tonight. Should be done by tomorrow if nothing gets in my way :).

Aaaah, nevermind. It doesn't even lead into a problem that a tag could server multiple value types in the old VotingAPI. I can just name the pools that I generate from the old data with "%tag-%value_type" and throw a notice to the user that he might want to change the machine-name after the migration (machine-name changing is supported by "Vote"). I guess that makes it even easier. Shouldn't be a problem to figure that out today.

Okay.. One more update: We basically just need one simple function for this:

• Get all tag <-> value type pairs from the old vote table and save them as pools with machine-name = "tag-value_type" and all functions enabled with default settings
• Get all votes from the old vote table and insert them into the new vote table using "tag-value_type" as pool name
• Schedule all vote content for recalculation (already part of the program)
• Done

Because of the new scheduling / recalculation concept I dont need to port the results at all (just the votes) and when the migration is finished the user would just have to press the "Schedule everything for recalculation" button on the "Settings" page and wait for the vote results to be recalculated. Easy!

You mean Fivestar and such? I will create a few widgets for fields on my own. However I wont adopt the -in my opinion- hacky approach of using the output of the formatter as an AJAX input "widget".

Fields are going to be used for casting vote DURING creation of a node / comment, etc ONLY! However, I also have a solution / idea for casting votes on the frontend. It will be possible to attach votes to entites directly (for example a node type can be configured to allow frontend voting like -at the moment- the fivestar formatters do). Those will be configured on the node type settings (under the "edit" inside of the vertical tabs). In the future that functionality will be applied to user profiles, taxonomy vocabularies and so on.

For an example of similiar functionality you can use the Flags module. Flags can also be attached to nodes directly (by configuring them for a node type for example).

REVOKED

I just asked the Fivestar guys - Awesome: No more hacky field formatters for frontend voting in the D7 branch. So my entire previous statement is revoked: I will try to wrap my head around their code and see how we can make it work together. But from the glimps I took right now its really not hard at all! Actually it should make a big part of the Fivestar code so much easier. We will see, we will see.

Hello again!

Done:

• Support for alternate databases (vote storage / result querying now pluggable),
• Migrating votes from VotingAPI to Vote by simply clicking a button in the admin UI
• Talked to ericduran (Fivestar)

I just finished the vote migration from votingapi -> vote (its a sub-module) and rewrote the functions which are involved in creating the results queries (fetching vote data in order to calculate results) to be pluggable (support for alternate db's like mongodb). However, since votes are entities the alternate databases need to support the basic entity storage features like entity_load() aswell (I have no clue if the mongodb modules does that).

Also, I spoke with ericduran (maintainer of Fivestar). Like eaton, he is interested and will look into this. He also mentioned, that he is planning a rewrite of Fivestar (I hope this is not top-secret :P). We basically share the same ideas. I am really looking forward to working on this when things arent as busy as now (before DrupalCon).

Eric had plans for reworking the Fivestar concept. We didn't talk much because he had to leave but it sounded really great and we should definatly coordinate this because I sense that there might be a way to create a whole voting suite with an API for storing votes and calculating results (this one) plus an API / frontend for handling widgets for votes with a) Fields support and b) direct entity support for voting on the frontend. It seems like your "vote up/down" could be a part (a widget) inside of this suite.

Hello everyone. I've worked on this for some more hours and ended up with something that is actually worth sharing. Remember: This is only the API, no Fields / Widgets to actually use in the frontend. In order to add votes you simply need to create a pool and play with the vote_init() function in order to store some random votes. Recalculation is set to real-time (can be set to cron too) so you will be able to see the results immediatly (remember to activate (checkboxes) functions for the pool).

The storage layer is now completly pluggable (the default storage method already is a sub-module).

There was a minor bug with the definition hooks... Fixed that in the attached file.

I am now implementing two different types of DrupalQueueInterface implementaions. One for the case in which the caching is set to "real-time" and one for the case in which the caching is set to "cron".

The first one doesnt use the database to queue the updated constellations for caching (and thus reduces the ammount of required insert queries when adding a new vote) the second one uses the database for queueing the constellations for recalculation during cron.

Cron will always check for db queue entries in case the recalculation method is being set to "real-time" even though there are still items in the db queue. However, if a constellation is being recalculated by the real-time queuing method (because it overlaps with one of the items in the db queue) those items are being removed from the cron queue.

Makes sense in my head.. :P

Update

Implemented DrupalQueueInterface and started with implementing views.

Views implementation done and changed the vote result storage so that it now stores the result values seperatly for each function (vote_result_count, vote_result_sum, ...).

I started a discussion on the fivestar project page to talk about the next layer (frontend) for this stuff.

http://drupal.org/node/1098638

Hey sun,

Regarding 1) Yes I think we should close the fivestar issue for now since first of all we need to figure out how the API itself will work in the future. Discussions about frontend implementations like fivestar can follow. I might have been a bit too fast there.

Regarding 2) This issue is basically the project application so it should not be moved.

Regarding 3) This approach of voting is based on the ideas that eaton introduced with VotingAPI but every single line is newly written code. I could surely write a documentation to show the differences between both APIs and also provide some pro con from my point of view (although both, you and eaton, see one of my big "Pros" as a "Con" -> Pools).

Regarding 4) Yes, that post was created in order to talk about the architecture of the code without abusing this issue.

Regarding 5) The approach is fundamentally different, thats right. However its still just an API that doesn't provide any Field API functionality (the entity type "vote" doesn't use Fields either). The API that I wrote does all the stuff that eaton's API does while also providing a administrative interface for creating vote pools and configuring them and other major enhancements like:

1. Queueing of newly added votes with DrupalQueueInterface (either in a static or as a "reliable" (db) queue).

2. Storing vote results in seperate tables in order to allow custom result functions to handle data differently ("score" for example needs an additional db column).

3. Definition hooks for everything:
- vote storage,
- vote types (defaults: "percent", "points", "options"),
- functions (defaults: "sum", "score", "average", "count")
- result queries (for optimizing the performance by reusing queries across different functions - e.g. sum, average and count can use one query together)

4. Custom and extendable configuration options for pools and for functions, provided by the module that introduces them.

5. Potential support for external database storage (mongodb, etc).

6. Votes are entities

7. Pools are bundles for entities and can be configured on the admin UI. Functions can be activated / deactivated for each pool seperatly. (This is what you guys evaluated as a con... I see it as a pro. The argument that other modules should have full control over the settings is reasonable and supported by me but this can still be achieved by providing functionality for this in the background. (Take "Fields" module as an example... "field_create_field" could be "vote_create_pool" for us.