Jump to:
| Project: | Voting API |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
I'm writing some integration code for votingAPI and Radioactivity. It already has general VotingAPI integration, but to be truly useful the integration modules need to be specific to the voting widget. When Vote_updown votes a 1 that means something totally different than a "20" vote from fivestar (i.e. 1 star, i.e. not good).
So, the integration is done using hook_votingapi_insert and then testing for the $vote['value'] and doing different things based on those values. That will work fine until someone installs two voting widgets on a site that both send in the same vote values but which have different meanings.
My proposal is that we have something like a "widget_type" or "context" or something that is a new argument to votingapi_set_votes (and it's friend votingapi_add_votes) which identifies whether the vote is from fivestar or voteupdown or whatever. This would then get passed along to hook_votingapi_insert. I guess for consistency we'd want it in the votingapi_vote table as well so we know which context the vote came from.
Comments
#1
I have you tried using "tag" ? I believe that this is what its for.
And just a small note, I wrote a quick and real simple 'hotness' metric based on Reddit. It is simpler in implementation: http://drupal.org/node/683090
#2
I'm not sure it does. The two modules I'm using are Fivestar and vote_up_down and both of those use a tag of "vote" though Fivestar has a value_type of percent and vote_up_down has a value_type of points. I considered value_type but I'm worried that some other module might also use the same value_type with a different scale and then I am back to having to code specific value_type/point combinations as an indicator of the widget.
I agree the hotness metric you've got is a good one - unfortunately ours has to take into account lots of other characteristics beyond votes which makes radioactivity a good choice (BTW, radioactivity is a pretty cool module to do what it does - worth checking out if you haven't seen it before).
#3
Well i guess what Im getting at is, this is what tag is already there for. Whether or not the other modules use it that way is a different story. You have your "widget_type" or "context" by using tag. And it gets written to the database.
Smackdown module for instance, uses tag in just this way. See this issue for an interesting discussion #335668: Add system for registering voting tags (axes) on tags
#4
Interesting, but uggh. If this is what tag is there for I'm not sure how to go back and fix all the old votes so that they have the right tag.
#5
probably pretty simple. edit the votingapi_vote table, where type = 'points', set tag = 'updown'. Where votingapi_vote where type = 'percent' set tag = 'fivestar'.
Then run your script: #382866: provide script and documentation to rebuild the votingapi cache or my batch api patch. and your right on track. But Im assuming that is how our votingapi vote table and your site is setup.
#6
The purpose of the 'value_type' is to allow calculations to be performed accurately -- so, for example, 'percentage' votes can be totalled differently than 'points' votes. I THINK that should work for your use case, as long as you don't have multiple percentage-votes being cast with different meanings, or multiple points-votes being cast with different meanings. In THAT situation, the modules in question should use the 'tag' field to distinguish between the different meaningful votes. I'm not sure all of them are that customizable, but that's also a bit of a gap in the design of VotingAPI -- it was originally intended to allow interoperability between vote widgets and modules, so it doesn't really account for multiple modules all casting different percentage votes against the same content.
If neither of those columns (value type and vote tag) can be leveraged it might be useful to have some sort of 'module that created this vote' information, but I'm nervous about what the ripple effects might be. the API already stores a relatively large pool of assorted flags on each vote, and while data storage isn't a problem keeping the use cases for the different fields is already tricky for a lot of API implementors...