2703ICT - Assignment 2
Introduction
In assignment 2, we will create a new version of the review application. This time, our review application will be implemented using the full Laravel framework, in addition it will contain more features including user authentication etc (as covered in weeks 8 to 10 lectures).
Details
Your implementation must use Laravel’s migrations, seeders, models, ORM/Eloquent, route, controllers, validator, and view/blade. You have some freedom in designing the functionality of your website, however, it must satisfy the following requirements:
Your web application now provides user authentication. So it provides facility for user registration and user login. The following data for a user must be stored:
Email (which will also be their username)
Password
Fullname
Date of birth
Type (regular user or moderator)
The user should be able to login (or get to the login page) from any page. A logged in user should be able to log out. After register, login, or logout, appropriate redirection should be provided. E.g. if user logs in from the details page, then after user completes the login, s/he should be redirected back to that page.
There are two types of users: moderator, and regular users. Moderators can perform CRUD
operations on all items and reviews. Regular users have restricted access as described below. Also see the permission tables (below) for a summary of permissions.
The basis for the review website is item and review. You are free to decide if you would like to focus your review application for a particular type of product/services/website etc. But you need to satisfy the following:
Create
An item can be created by any user (no log in is required). An item must contain the item name, manufacture/business name, and description for that item. The item name must be unique. An URL can be stored for an item (users have the option of entering the URL or not). Only valid URL will be accepted.
A review is for an item and posted by a logged in user. A review must contain a creation date, a rating (e.g. a number between 1 to 5), and the review (text). A user can only post at most one review per item. After a new review is posted, the user will be redirected to the page containing the newly posted review.
Retrieve
There should be a page that lists all items, and allow user to click on an item to show the detail page for that item.
The details page should show all the information for that item, in addition it also displays all reviews for that item. When displaying review, all information for that
review should be displayed. In addition, the name of the user who posted that review must also be displayed.
Users can select to display reviews order by date (i.e. the latest review at the top of the page), or order by rating (i.e. the review with the highest rating is at the top of the page).
Update
An item can only be edited by moderators.
A review can only be edited by the poster and moderators.
Delete
Only moderators can delete items. When an item is deleted, all reviews for that item should also be deleted.
A review can only be deleted by the poster and moderators.
You are free to store any extra data (even using additional tables – if appropriate) for your application.
Other features related to CRUD you must implement are:
Input validation must be performed. If invalid input is detected, the appropriate error message must be displayed, along with the previous entered value.
Access control: actions that cannot be performed by user should not be displayed (e.g. if a user is not logged in, s/he should not see the form for posting a review, and a user
should not see the edit button/link for the reviews they cannot edit etc). Appropriate access control checks should also be implemented on the server before performing an operation.
Pagination must be used to paginate reviews; where there are more than 5 reviews for an item
(at least one item must have more than 5 reviews).
Users can upload their photos of an item. An item may have many photos uploaded by different users. These photos will be displayed in the details pages for that item. When displaying a photo the name of the user who uploaded the photo should also be displayed. Only logged in user can upload item photos. (Note: partial mark will be awarded if you allow only ONE photo per item.)
Users can vote to like or dislike reviews. Reviews that have more dislike than like would be displayed differently than the reviews with more likes than dislikes (you can decide how to display them differently). A user can only vote for a review once. As reviews are often retrieved, the implementation should be optimised for efficiency of retrieval of review (possibly at the expense of using more storage space).
A user can “follow” and “unfollow” reviewers/users. By following other reviewers, the currently logged in users can:
See a list of people the s/he has followed, and
See a list of reviews posted by the reviewer s/he has followed. For each review, the item which the review is for should also be indicated.
A recommendation feature, such as provide recommendation of:
Items the current logged in user may like.
Reviewers the current logged in user may want to follow.
You have the freedom to design and implement this feature. You will be judged on creativity/innovation, usefulness, and also technical competence.
Permissions tables
Items | Not logged in | Regular user | Moderator |
Create | Yes | Yes | Yes |
Retrieve | Yes | Yes | Yes |
Update | No | No | Yes |
Delete | No | No | Yes |
Reviews | Not logged in | Regular user | Moderator |
Create | No | Yes | Yes |
Retrieve | Yes | Yes | Yes |
Update | No | Own | Yes |
Delete | No | Own | Yes |
Technical requirements
Use Laravel’s migration for database table creation.
Use Laravel’s seeder to insert default test data into the database. There should be enough initial data to thoroughly test the retrieval, update, and deletion functionalities you have implemented.
Use Laravel’s ORM/Eloquent to perform database operations. Only partial mark will be awarded for implementations using SQL or query builder.
Proper security measures must be implemented.
Good coding practice is expected. This includes:
Naming: using consistent, readable, and descriptive names for files, functions, variables etc.
Readability: correct indenting/spacing of code.
Commenting: there should at least be a short description for each function.
View: proper use of template and template inheritance.
For further details of the requirements, refer to the marking rubric. All requirements from both the assignment specification and marking rubric must be satisfied.
Submission Requirements
You must submit the following items for the assignment:
A short document describing what you were able to complete, what you were not able to complete, any interesting approaches you took, and any extra that was implemented. If you have implemented the recommendation feature, briefly describe the algorithm you’ve used to determine what recommendation to make.
An ER diagram for the database.
The above documentation should be provided as a page (or pages) in the website and linked to from the navigation menu. The ER diagram can be provided as an image (PNG) or SVG.
A compressed file containing ALL the files in your submission (including all PHP code, SQL to create the database, and documentations as described above).
This file can be obtained from Cloud9 by right click on your assignment directory then select download.
This file must be submitted via Learning@Griffith through the assignment 2 link.
Note: You are responsible for regularly backing up your work. Hence, if you lose your file due to not backing up, then expect to be heavily penalised.
Peer Assessment
Assignments will be marked by your tutor in the lab following the due date of the assignment. Before you attend your laboratory class for assignment marking, you must complete Peer Assessment for your submission.
The peer assessment activity requires you to demonstrate and explain your work to a fellow student (peer) that have already submitted their assignment (you should check their L@G submission page to make sure of this). Your peer will mark your assignment using a print out of the rubric and indicate on the rubric the achievement for each requirement. To indicate the completion of peer assessment, your peer need to record the date and time of peer assessment and sign the rubric (form).
Assignment Demonstration and Marking
After you have completed your peer assessment, you must demonstrate and explain your work to your tutor in Week 12 lab to have your submission marked by your tutor.
If you don’t do Peer Assessment and then demonstrate your assignment to your tutor, your submission will be regarding as incomplete, hence you will not receive a mark for this assessment item!
During the demonstration, you need to show the last modified date of your file (on Cloud9, run the command: ls -la in your routes directory. Cloud9 is 10 hours behind Brisbane/Gold Coast time).
