[development] Rating module quality

Jeff Eaton jeff at viapositiva.net
Fri Jan 27 14:03:31 UTC 2006


> My problem with the  
> VotingAPI module is this: it addresses an _extremely_ _trivial_  
> problem.  It saves us 10 lines of code and 20 minutes of  
> implementation work at the cost of an extra layer of code  
> (performance cost), an additional module to monitor/track/audit  
> before upgrades (extra dependencies, time overhead) and install  
> (usability).  Maybe the added value becomes clear after I spent some  
> more time looking at it but right now, I prefer to go with a single,  
> dedicated module.

I can definitely understand those objections. I think 10 lines/20
minutes is a bit of an understatement considering the more complex
voting scenerios it's capable of handling, but the real benefit of it is
the potential for cross-module consistency and sharing of voting data.

Dedicated voting modules have a strong tendency to do the same thing in
a dozen different ways. Some in contrib have a great UI, others
calculate the statistics a given user needs, others are capable of
working with the moderation queue. None work together. If I want to
moderate nodes and comments, track the most popular pictures, and allow
users to rate downloads on my site, I have to install four separate
modules with four wildly different UIs and four completely different
silos of data.

The same objections could be raised about taxonomy: why use a complex,
topheavy API when all we need to do is assign a 'category' to a node?
I'll be the first to say that my skills are not equal to those who
crafted Taxonomy.module, and the VotingAPI is a lot less mature. I do
think that the need for a consistent way of storing and accessing voting
data across modules will enable a broader range of tools for working
with it, in the same way that we have loads of taxonomy-related helper
modules. Frustration with those silos of voting data is what prompted me
to dive into the project in the first place.

Of course, whether drupal.org and project.module is the correct place to
champion this is another question entirely. If folks feel it would be a
bad use of resources or would add unecessary complexity to the site,
that's that.

--Jeff




More information about the development mailing list