Add an abstracted widget API for presentation [#335530]

Hello guys,

I just want to put something to discuss here, so don't blame me for poor coding ;) I have a client who wants to have a slider instead of stars as rating/voting widget. I thought this couldn't be so difficult, since Fivestars is a mature module for voting which also supports user-defined widget styles.
But soon I realized, a slider cannot be done with pure css-styling, since the fivestar.js always activates all the stars below the rate value when doing a vote. So it seems I need to touch the fivestar.js.

At first I tried to overlay another element (a sliding-picker) which would be positioned over the current value. Problem here is that the jquery plugin listens for mouseover events on stars which means an overlay between the mouse and the stars would block the mouseover-event. I tried some z-index crap, when I finally came to conclusion that this is actually way easier to do: Just alter the fill and reset methods to activate the value-index-star only. This is intended to work for widgets that have a small bars for non-activated stars (the sliding range) and tall bars for the activated one (the sliding picker). I have a patch for this available below (based on 1.13) which changes the drawing behaviour globally for all widgets (quick and dirty hack there).

I know this can be way better done and I want to ask YOU how you would go about a more general solution to different "rating widget" handlers. Maybe splitting the fivestar-plugin into a model- and a view-handler whereas the model-handler will define and control the dataflow, but widgets can provide their own view-handlers (widgets without a custom handler get the default one) ... This way no GUI-additions in the administration is needed, everything will work the same, but now widgets can define a far more customized representation or interaction if needed.

Comment	File	Size	Author
	fivestar-6--1-13-sliding-mod.patch	1.38 KB	japanitrat

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

quicksketch

he/him

CreditAttribution: quicksketch commented 17 November 2008 at 21:50

It's a bit of an odd request I think, since Fivestar isn't really made to handle things other than the "star" representation of voting. The voting mechanism is already abstracted, since i tallying and storage is handled by the VotingAPI module. All the Fivestar configuration is allowing you to do is configure HOW you want to place these ratings. So I'm not entirely sure abstracting Fivestar is a good approach, when it seems like you might need to create an entirely separate voting widget.

Comment #2

japanitrat CreditAttribution: japanitrat commented 18 November 2008 at 07:24

Hm yeah I see what you're saying, fivestars is about stars.

On the other hand I really don't feel like to reimplement all the stuff for drupal that fivestars makes nice. I mean, there is a lot of code in fivestars that actually doesnt rely on "stars", like the cck-definition, admin- and node-forms, basic wrapper positioning and theming, the JS client, and so on.
The only code that actually builds the stars and their behaviour is the jquery plugin which means that the rest of fivestars is already abstracted to "a pluggable widget for voting" (through the Voting API). It seems like fivestars began its life with a small scope but has been constantly grown in the past to implement more general features.
I mean, even now its neither five nor stars anymore. I can have a scale of 10 or i can put seamless blocks instead of stars if I like to. Wouldn't it be just one more step in the evolution to detach the widget (and VotingAPI linking) functionality from the jquery representation? It's not even a huge one due to the generalization already found in fivestars...

Comment #3

a25i CreditAttribution: a25i commented 24 November 2008 at 08:29

Title:

fivestar.js "sliding star" mod

» Adding support for non-star (e.g. sliders) voting widgets

Maybe fivestar is a victim of its own success here.

It seems there is some fivestar code that could be leveraged by other modules wishing to implement something like a slider. Also, it would be a shame to have repeat so much of what fivestar already does well, just to get a non star rating widget. Maybe some of this functionality (ie setting where/when a widget is exposed) could be pushed into voting api, or???

Just throwing some thoughts out there.

EDITED TO ASK:
I haven't looked closely, but I was wondering if the OP's original request could be achieve through theme (or module) overriding?

Comment #4

mitchell CreditAttribution: mitchell commented 5 April 2009 at 01:29

Title:	Adding support for non-star (e.g. sliders) voting widgets	» Abstract fivestar into a voting widgets api
Version:	6.x-1.13	» 6.x-1.x-dev
Category:	support	» task
Status:	Needs review	» Needs work
Issue tags:		+abstration

Fivestar is such a good voting module that other voting module developers are beginning to copy some of its code. A better approach would be to help other "voting style" modules to easily depend on the codebase that was developed for the fivestar voting style.

Comment #5

mitchell CreditAttribution: mitchell commented 5 April 2009 at 01:36

Marked #297903: Create widget API ala fivestar as a duplicate.

Comment #6

mitchell CreditAttribution: mitchell commented 5 April 2009 at 02:29

After googling for various voting styles, I was able to expand this near-exhaustive list of the modules that could benefit from this abstraction:

- Fivestar (by far seems like the most popular voting widget around the web)
- Vote Up/Down
- Advanced Poll (I was surprised to find polls categorized as voting widgets, but it's actually based on Voting API)
- Decisions (ditto)
- Dudel (I don't think this module is currently integrated with Voting API)
- Quiz (ditto) (and coincidentally is struggling with Views integration)

Comment #7

eaton CreditAttribution: eaton commented 5 April 2009 at 04:42

Title:	Abstract fivestar into a voting widgets api	» Add an abstracted widget API for presentation
Project:	Fivestar	» Voting API
Version:	6.x-1.x-dev	» 6.x-2.x-dev

mitchel, I'm not yet convinced that adding abstraction to fivestar will help any of the modules you mention; I've moved the discussion to the VotingAPI queue, as it would really be the responsibility of VotingAPI to handle this kind of centralization; making Vote Up Down require VotingAPI AND FiveStar would be a bit awkward. ;-)

Are there specific pieces of code in Fivestar that you see being duplicated that aren't extremely tailored to the specifics of its use case? Floating the stars at the proper position, configuring how many stars to show, etc are really very fivestar-specific, and I'm not sure there would be much gain adding lots of code to make those settings forms generic: that's what CCK in d6 and FieldAPI in D7 already do...

If there isn't specific duplicate fivestar code already out there in the other modules, what specific functionality could be abstracted? And how would the other modules make use of it? Advanced Poll and Decisions wouldn't have much overlap with Fivestar due to their far more complex configuration mechanisms, and Quiz isn't based on VotingAPI at all -- it's not about submitting ratings but rather about creating complex quizzes with word/picture/multiple choices questions and so on.

Can we get to more specifics to see if this has merit?

Comment #8

dmitrig01 CreditAttribution: dmitrig01 commented 5 April 2009 at 06:00

Speaking from the persctive of UpDown and Vote Up/Down, the really nice feature Fivestar has that we want is the Widget API, which can be generalized. It could, as you said, be moved into VotingAPI. However, it'd be a shame to rip code out of Fivestar when it could be generalized. One thing that could also be generalized that's not yet supported is to have widgets able to define .tpl.php files which may or may not be a lot of work.

Comment #9

eaton CreditAttribution: eaton commented 5 April 2009 at 08:13

OK, I'm not sure what exactly is being discussed at this point. What WidgetAPI does Fivestar have? At present, it does several things:

1) It provides a FormAPI element designed for representing a numerical range or a single-value select list as a set of stars.
2) It provides an extensive set of customization forms specifically for the fivestar form element. (What star graphics to use, whether to show all votes, the user's vote, both, etc. This is basically just a switcher between several canned stylesheets.)
3) It provides a CCK field type, editing widget, and formatter for attaching a numerical value to a node and representing it as stars
4) It provides the ability to attach a "star rating" form element to comments or nodes, and saves submitted votes as VotingAPI records.

It sounds like you might be saying that #2 -- the configuration scheme that lets a user switch between multiple stylesheets to pick between different 'stars' -- should be turned into a generic API that sits alongside VotingAPI. I'm not sure how that would be implemented in a way that makes sense; some voting modules don't need that kind of customization, others leave it completely up to the themer, and others (like Quiz and Advanced Poll) have their own very specific UI conventions that don't correlate very well to other voting modules.

What specific code is being talked about when the 'Widget API' is being discussed in the context of this thread? And how would that specific code, or some permutation of it, be utilized in other modules? I'm trying to talk through the specifics now. Without them, I can't see how this is any different than the theming layer or CCK.

it'd be a shame to rip code out of Fivestar when it could be generalized

If it's generalized for use in all VotingAPI voting modules, I'm not sure why it would stay in fivestar. That's the point of generalizing something. :-)