I have a feeling we won't be seeing Jerry until after school lets out. I never got a copy of his mod, so I don't have it to hack on for the graphics. But, if anyone is really interested, I can start laying out the ratings mod I started before Christmas, and if someone is interested in spiffing it up feel free.
Basically, I used the ratings track database, to prevent multiple votes by the same IP in 24 hours... not hard to do.
I set up a new table to track all votes that were accepted by IP/USER, LinkID and Value.
I had a 1 thru 10 scale, so I had another table set up with ID (so I could use DBSQL.pm without problems), LinkID, TVotes, TRating, and R01-R10 fields.
Each time a vote was cast, it was logged in the rate-track and table I was tracking on (I did that so I could reconstruct my ratings table if I changed my mind later-- it's not really necessary unless you want to track which users are rating, and their stats.)
It then "Updated" the TVotes=+1 and the appropriate R01-R10 field+1, then it did a recalculation of the votes (R01*value)+(R02*value)+..+(R10*value)/TVotes=TRating.
It's a little CPU intensive on high traffic sites, but you can leave the "recalc" until the next rebuild also.
What this does is allow you to build graphs of the actual votes, not just the total -- so you know if the link is getting 10's or just 8, etc.
The second tracking table will allow you to build another table of the users, their votes, their average ratings, etc.
This is not very complicated, but the _graphics_ are. Also, what data you really want to track on the links and users, etc.
You can track a heck of a lot! You can tie a rating/review into the registered user status, then use the UserID to link the tables. A user can get their history, and a summary of all their comments, etc.
Again, CPU intensive, but it's all straight database calls, and nothing more intensive than generating the site dynamically.
By structuring the tables properly, all the calls can go through DBSQL.pm and all the writes go out through HTML_Templates.pm, so you have full access to the templates.
You can add a routine to nph-build.cgi to generate the static pages, and update them only when you rebuild, or you can do it purely dynmically as I indicated at first -- or even a combination.
Comments? If I get a bit of feedback, on what you want, I'll doctor the code a bit before I release it. But, it's bare bones! No graphics. Just a numerical breakdown and rating. But it did track user data, votes, etc.
Basically, I used the ratings track database, to prevent multiple votes by the same IP in 24 hours... not hard to do.
I set up a new table to track all votes that were accepted by IP/USER, LinkID and Value.
I had a 1 thru 10 scale, so I had another table set up with ID (so I could use DBSQL.pm without problems), LinkID, TVotes, TRating, and R01-R10 fields.
Each time a vote was cast, it was logged in the rate-track and table I was tracking on (I did that so I could reconstruct my ratings table if I changed my mind later-- it's not really necessary unless you want to track which users are rating, and their stats.)
It then "Updated" the TVotes=+1 and the appropriate R01-R10 field+1, then it did a recalculation of the votes (R01*value)+(R02*value)+..+(R10*value)/TVotes=TRating.
It's a little CPU intensive on high traffic sites, but you can leave the "recalc" until the next rebuild also.
What this does is allow you to build graphs of the actual votes, not just the total -- so you know if the link is getting 10's or just 8, etc.
The second tracking table will allow you to build another table of the users, their votes, their average ratings, etc.
This is not very complicated, but the _graphics_ are. Also, what data you really want to track on the links and users, etc.
You can track a heck of a lot! You can tie a rating/review into the registered user status, then use the UserID to link the tables. A user can get their history, and a summary of all their comments, etc.
Again, CPU intensive, but it's all straight database calls, and nothing more intensive than generating the site dynamically.
By structuring the tables properly, all the calls can go through DBSQL.pm and all the writes go out through HTML_Templates.pm, so you have full access to the templates.
You can add a routine to nph-build.cgi to generate the static pages, and update them only when you rebuild, or you can do it purely dynmically as I indicated at first -- or even a combination.
Comments? If I get a bit of feedback, on what you want, I'll doctor the code a bit before I release it. But, it's bare bones! No graphics. Just a numerical breakdown and rating. But it did track user data, votes, etc.