The GT review program is pretty basic, it doesn't come close to all the expectations posted in:
http://gossamer-threads.com/...w=collapsed&sb=5
I think tonight, to clear my head, I'll look at the review plug-in from GT and the one mentioned here, and see how they fit together. I'll try to release one combined line of code to get people started on.
But, remember, in a group project there can be no "hacks". Any "custom" solution has to be generalized so it can work for everyone.
One big thing will be to come up with a database format. Some ideas were posed in the other thread mentioned above.
While I'm only cautious about adding new fields to the link record (to keep it as small as reasonable), I'm less likely to want to fiddle with the Users table, due to the large number of potential plug-ins that will try to make use of it. Much better is a "Users_Extra" table, that is keyed to the Username, and holds all the "extra" information this program, and any other, would want to store about the user.
I think that is much safer in the long run. If the Username/Username fields are linked, the tables should be automatically updated if a record is deleted from the Users table.
Some information needs to be stored in the User record, other information in the Links record, and others in the Review table.
What information do people want in the Users/Users_Extra tables? And why?
The Link record really only needs a "Reviews" field that contains the number of reviews, for performance reasons. In doing the category builds, and "link.html" template parsing, there is no need to look up all the review data. HOPEFULLY!! - there is a hook to repair_tables that will allow us to add in the "update reviews" as well as new/etc flags. (I also want to use that sort of hook for attachments).
If the reviews system keeps "summary" data, such as score, ranking, last rated, number of each type of review, etc, this should be in a separate table, indexed by the LinkID, and _NO_ field needs to be added to the Link record. A look up is done on this table whenever a call to display link data is made (link.html, detailed.html, etc). The "repair" function would run against _this_ table, and take the reviews from the reviews table(s), and tabulate them in this table.
The Reviews Table(s) is where we need to put the most thought. What information does this need to hold? What is the MINIMUM information a review record needs to have?
ID(unique), LinkID, Username, Comment, Date.
What else?
Numerical rating?
What about sites that don't want to leave comments, just numerical ratings. Should this be an option during set up? If so, what other options? Range of numerical value? Length of comment? Short_Comment + Long_Comment. Should a "Long_Comment" be a "value added" feture so that only a certain type of user can leave them? What criteria should this be based on?
(as you can see it gets complicated very, very quickly!!)
In thinking about this, the Users_Extra table should hold user demographic information, or stats, but since the Review is a plug-in, maybe the User_Review_Stats should be in it's own table, like the Review_Stats data? That way, during a repair, the User_Review_Stats table is updated with the same information as in the Review_Stats data, but keyed to Username, not LinkID.
Have I bored everyone? s everyone asleep?
PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
http://gossamer-threads.com/...w=collapsed&sb=5
I think tonight, to clear my head, I'll look at the review plug-in from GT and the one mentioned here, and see how they fit together. I'll try to release one combined line of code to get people started on.
But, remember, in a group project there can be no "hacks". Any "custom" solution has to be generalized so it can work for everyone.
One big thing will be to come up with a database format. Some ideas were posed in the other thread mentioned above.
While I'm only cautious about adding new fields to the link record (to keep it as small as reasonable), I'm less likely to want to fiddle with the Users table, due to the large number of potential plug-ins that will try to make use of it. Much better is a "Users_Extra" table, that is keyed to the Username, and holds all the "extra" information this program, and any other, would want to store about the user.
I think that is much safer in the long run. If the Username/Username fields are linked, the tables should be automatically updated if a record is deleted from the Users table.
Some information needs to be stored in the User record, other information in the Links record, and others in the Review table.
What information do people want in the Users/Users_Extra tables? And why?
The Link record really only needs a "Reviews" field that contains the number of reviews, for performance reasons. In doing the category builds, and "link.html" template parsing, there is no need to look up all the review data. HOPEFULLY!! - there is a hook to repair_tables that will allow us to add in the "update reviews" as well as new/etc flags. (I also want to use that sort of hook for attachments).
If the reviews system keeps "summary" data, such as score, ranking, last rated, number of each type of review, etc, this should be in a separate table, indexed by the LinkID, and _NO_ field needs to be added to the Link record. A look up is done on this table whenever a call to display link data is made (link.html, detailed.html, etc). The "repair" function would run against _this_ table, and take the reviews from the reviews table(s), and tabulate them in this table.
The Reviews Table(s) is where we need to put the most thought. What information does this need to hold? What is the MINIMUM information a review record needs to have?
ID(unique), LinkID, Username, Comment, Date.
What else?
Numerical rating?
What about sites that don't want to leave comments, just numerical ratings. Should this be an option during set up? If so, what other options? Range of numerical value? Length of comment? Short_Comment + Long_Comment. Should a "Long_Comment" be a "value added" feture so that only a certain type of user can leave them? What criteria should this be based on?
(as you can see it gets complicated very, very quickly!!)
In thinking about this, the Users_Extra table should hold user demographic information, or stats, but since the Review is a plug-in, maybe the User_Review_Stats should be in it's own table, like the Review_Stats data? That way, during a repair, the User_Review_Stats table is updated with the same information as in the Review_Stats data, but keyed to Username, not LinkID.
Have I bored everyone? s everyone asleep?
PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
