I am in the process of setting up a voting mechanism on my website. I have brainstormed three different methods for implementation and would appreciate your input.
The goal is to allow users to vote on various types of user-generated content related to gaming in a micro Q&A format similar to sites like Stack Overflow, but on a smaller and more specialized scale.
After exploring the following methods, I am struggling to determine which one is most effective.
Method 1: Involves using URL parameters and forms.
Method 2: Involves utilizing URL parameters and jQuery.
Method 3: Utilizes either of the above methods but retrieves information from the database.
The schema assumes that both questions (Q's) and answers (A's) are considered as post objects with distinct postTypeIds, along with the following two tables:
voteTypes(id, voteTypeId, voteName)
votes(id, postId, parentId, userId, ownerUserId, voteTypeId)
- The parentId field represents the id of the parent post. It ensures that a question post (postTypeId=1) can only have one accepted answer if the post being voted on is an answer post.
- The ownerUserId field corresponds to the userId of the post's owner who is being voted on. This comparison prevents a user from voting on their own posts by verifying it against the session's userId.
- The userId field originates from the session and signifies the voter's identity.
Method 1: Create a voting form within the view while iterating over each post in a query. Use hidden fields to capture necessary data.
<input type="hidden" value="@voteTypeId" etc...
The postId, parentId, and ownerUserId will be extracted from the query output in the view, whereas the userId will derive from the session.
Disadvantages: 1. Users may manipulate data and accept answers to questions they did not ask due to ownerUserId being defined at the view level. 2. Cumbersome: Multiple forms need to be created corresponding to the number of posts displayed in the view. Each post entails four forms, leading to a potentially large number of forms on a single page.
Advantages: 1. Simplicity.
Method 2: Implement anchor tags with custom data attributes alongside jQuery to construct the vote URL.
<a data-vote-type-id="@voteTypeId" data-post-id="@postId" etc...
The ownerUserId, postId, parentId, and voteTypeId will be derived through the URL, while the userId will be fetched from the session.
Advantages: 1. Lightweight design without the necessity for numerous forms. A single jQuery call facilitates submission of any vote via AJAX.
Disadvantages: 1. Disabling JavaScript results in inability to cast votes. 2. Vulnerability to data manipulation since data is transmitted via the URL.
Method 3: Submit solely the voteTypeId and postId via the URL, employing either Method 1 or Method 2. Utilize the postId to interrogate the database, ensuring existence of the post object under consideration as well as validating its ownerUserId and parentId.
If the post exists as an object, establish a newVote entity.
The userId arises from the session, while postId and voteTypeId originate from the URL. The parentId and ownerUserId stem from the retrieved post object.
Advantages: 1. Data integrity maintained to prevent unauthorized modifications by confirming existence of the post object along with its associated details.
Disadvantages: 1. Labour-intensive approach necessitating database queries for retrieving information already available at the view level seems redundant. 2. Denormalized data representation in certain scenarios calls for additional database interactions after successful vote submissions to update relevant tables based on object callbacks, despite the details being accessible at view and controller stages.
Unaddressed aspects: 1. Identifying existing votes to toggle them, requiring further queries. 2. Complicated validation combinations.
I welcome any feedback or alternative suggestions. Thank you!