Building a Car Rental Website

Web Application Development:

Building a Car Rental Website

Summer 2024Allocation

This coursework is worth 100% ofthe marks for module

You will also need skills from the following modules:

• (Python Programming)
• (Design reporting)
• (Database design)
• (Secure implementation)

Objective:

The objective ofthis coursework is to design and develop a fully functional car rental website. Students

will use HTML, CSS, JavaScript + DOM (or jQuery), Flask, and MySQL to create a responsive and

dynamic web application for a single car rental company.

Coursework Description:

Students will create a web application that allows users to rent cars from a single company. The

application should include user registration and login, searching for available cars, making reservations,

and an admin panel for managing cars and reservations.

The following is the basic functionality to implement for each type of users:

Regular Users:

1. User Registration:

o Fo

r

m for new users to sign up, including username, real name, date ofbirth, adress

a

nd

p

asswor

d

.

o Form validation and secure password storage (using encryption).

2. User Login:

o Login form for existing users.

o Session management to keep users logged in.

3. View Available Cars:

o Page displaying all available cars.

4. Car Detail View:

o D

e

tai

l

ed information about selected car: Make (e.g., BYD, Toyota…), Model, Year,

C

olou

r

.

o Car images and specifications.

5. Make a Reservation:

o F

o

rm to book a ca

r

wi

t

h date select

i

on, custome

r

c

a

n r

e

n

t

one o

nl

y ca

r

per

r

eserv

at

ion,

n

ot

a

llowed hav

i

ng mu

l

tiple reserva

t

ions at

t

he sam

e

t

i

me,

inf

o

r

mation

ne

eded a

r

e:

Start date/time, End date/time and calculated duration in hours and days.

o Validation to prevent booking conflicts.

6. View and Manage Reservations:

o Page for users to see their reservations.

o Option to cancel upcoming reservations.Admin:

1. Admin Login:

o Secure login for admin users.

o Separate from regular userlogin.

2. Manage Cars:

o Admin panel for adding, updating, and deleting car records.

o Form validation and confirmation prompts.

3. Manage Reservations:

o

Ad

m

in

view of

a

ll re

s

ervations.

o

Opt

i

ons to

e

d

i

t or can

c

e

l

reservations.

The marks available for each of these areas of functionality are divided based on the sections ofthe

coursework, as described below. Simply writing code to meet the specification by any means will not

earn full marks.

Restrictions

Your web site must run in a Python virtual environment built by running the following commands

from a Command Prompt in a suitable working directory:

pip install virtualenv

virtualenv webtest

cd webtest

scripts\activate

pip install flask mysql-connector-python

It is recommended that you also use this virtual environment for development. Regardless, you must

test your site within the virtual environment before submitting it. This is the virtual environment in

which your code will be tested by the assessor. If it does not work, marks will not be awarded.

In addition to the libraries in the above virtual environment, you may use the jQuery library for

JavaScript, but may not use any other frameworks or libraries. This means that you may not use

libraries that are “Flask extensions” ifthey are not installed with Flask.

(Please do not send e-mails asking if you can use other extension libraries; the answer is no. The

purpose of the coursework is to understand how JavaScript and server interaction work at the lowest

level possible, not in terms of abstractions created by higher level code.)

Your website must be built using HTML 5 and ECMAscript 6 on the client, and Flask, MySQL and

Python 3 on the server.Plagiarism

This is individual work. You must not copy or share code with other students. Do not copy code from

online sources, answers, tutorials or existing open-source software. Copied code will result in the

plagiarism process being invoked and you maybe asked to attend an online meeting to verify that your

understanding of your code is consistent with you having written it.

You must be very careful with the use of online tutorials on this module. Your primary learning

source should be the module notes and the lecturer and tutorial staff. There are a very large number of

online tutorials on the topic of web development, but many are incorrect, out-of-date, or badly written.

Sites which present code and then explain it are often cheating sites, not tutorials. Retroactively

explaining large amounts of code is not an effective learning method, but is often used as a trick to

“justify” presenting code actually intended to be cut and pasted. Often the explanations are extremely

poor or even incorrect and will confuse your understanding further.

Submission

Submission is in two stages:

• The website documentation report.
• The actual website.

Due Date:

Website documentation report:

Website:

The website documentation report is worth 40% of each component ofthe marks from the

Specification section. The implementation is worth 60%.

Code implemented in the final submission but not reported on in the actual report can still score full

marks on the other two components, but you will lose out on potential feedback on your report.

Website Documentation Report

The website documentation report should cover the design and structure of implementation you intend

to use to produce the selected functionality. This should include:

• ER diagram for database used in the website.
• Wireframes representing the user interface;
• Description of the tests performed on the website (functions, database …)

Website

Students are expected to start developing the website from the first week ofthe semester, the website

should be uploaded as a .zip file to the student website by (Date to be announced). To prepare

your .ZIP file, do the following steps:

1. Prepare a fresh virtual environment via the commands described in the “restrictions” section.
2. Copy your website files into the virtual environment, activate it, and ensure that your website

works inside it.

3. Use the mysqldump ut

i

l

ity t

o out

p

ut you

r

dat

a

base s

pe

c

i

fication in

t

o a f

i

l

e i

n

t

he v

i

r

t

ua

l

environme

nt

. (

The mysqldump.exe

f

i

l

e is in

t

he bin directory of

t

he MySQL Server

install path.)4. Delete the directories Include, Lib, Scripts, and tcl.

5. ZIP the virtual environment directory.

The 60% ofthe section mark for the website is divided as follows:

• The basic functionalities: 30%.
• Quality of user interface design: 10%.
• Quality of back-end architecture: 20%.

Remember to break down processes in detail to allow these to be described. “The user can click to

login” is not sufficient detail - the process of logging in is a multi-stage one that will likely involve

several communications between the client and server, and use ofthe database.

It is not necessary to include source code in the report. The report will be your main opportunity to

gather feedback before the submission (although you may also ask for help in practical sessions) so

make sure to provide detail on any decisions you are not sure about, so that the assessor can provide

useful feedback.

The website documentation report should be submitted on the student website by (Date to be

announced). You may have already started developing your implementation before this submission.Overall Mark Scheme

Basic functionality

Website Documentation Report 40%

General Implementation

30%

User Interface

10%

Back-End Implementation

20%

Component total

100%Tips

Using the lecture material

The lecture material and practical’s do not directly walk you through the coursework, but it can be

completed by applying the skills they teach.

• Session 7 will help you think about designing your database. The specification includes

administrators, users... Think about what needs to be stored about each one and how they

relate to each other, and what data needs to be stored about the relationships.

• Think about database transactions - what is the list of actions that the user can take that alter

the database? How can you write each one as a query? Think back to CHC4007 and

consideration of use cases.

• What input does each transaction need, and how can you get that from the user over the web?

Sessions 1-4 will help here.

• How will you send the input to the server? First, in what form? How can you make it easy for

your program to work with but also secure? Again, see sessions 1-4. Second, how will you

actually send it over the web? See sessions 5 and 8 for your options.

• Can you now write the Python program for the transaction and assign it to be a Flask route?

See sessions 5 and 6 as well as general Python programming from CHC4007.

• How will you return the response to the user? Will you use a web template (session 6) or

maybe a JavaScript program that reads from the server using AJAX (session 9)?

• Is the transaction “stateful” - meaning that it changes the treatment of other transactions after

it, such as logging in? If so, what do you need to store in the Flask session variable (session 6)

to allow this?

Previous Common Errors

Here are some previous mistakes frequently made by students on Web Development coursework.

Please be careful not to repeat them!

Website documentation report

• Repeating what is stated in the specification as if it was your decision rather than what you

have been told to do.

• Describing what is stored on the client or server, but not what functionality they have.
• Writing many-to-one relationships with the foreign key on the wrong side.
• Trying to store foreign keys to two different tables in the same field without distinguishing

them.

• Not showing data table descriptions, only sample data that does not formally indicate

structure.

• Omitting field types from specifications.
• Stating that the “user will be logged in” without indicating what method is used to signal this.
• Large amount of dead space on UI designs.
• Showing UI prototypes instead of wireframes.
• Where search is implemented, not providing a wireframe for the search results page.Web site
• Using unauthorized libraries such as flask extentions (Flask_login,

Flask_MYSQLAlchemy, ….), blueprint, pymysql.. or JavaScript libraries other than JQuery

(Layui.js, Flatpckr.js… JavaScript frameworks)

• Failing to implement all basic functionality.
• Functions on the server that require the user to be logged in don’t actually check that the user

is logged in.

• Storing passwords in cleartext in the database.
• Making the database or on-screen fields for a comment text too short for messages to be

entered.

• Duplicated data in the database, violating normal form.
• Missing or redundant foreign keys in tables.
• Search loads entire table and searches it in Python rather than using SQL database search.
• Can only search exact, not partial, matches.