Important

Functional Requirements

There will be two interfaces:

•   A public/driver interface to allow drivers to view information and results.

•   A club Administrator interface for admin staff to use to update, edit and add data.  This

interface requires administrators to access the system via an Admin button or link from the  home page (do not add password functionality – security would be added to a full system to

restrict access, but it is not required for this assessment).  The Admin link will provide a gateway to the Admin features.  The Admin features must not be visible in any public navigation (apart

from the Admin link or button on the home page).

Driver Interface on the default / route

• List of courses: Make the courselist page display the course’s image, rather than the name of the imagefile.  Modify or tidy the template as appropriate.

• Driver’srun details: A driver’s name is selected from a drop-down list of drivers to display a    page showing the driver’s run details and run totals, including the course names (but not the    course ID letter).  Include the driver ID and names, and car model and drive class, as headings.

• List of drivers: Modify the /listdrivers route so that each driver’scar details are also displayed. Do not display the car_num.  Show them in surname then first name order, and use Bootstrap   to display the junior drivers in yellow.  Make the driver name a clickable link that also displays   the driver’s run details page (see above).

• Overall results: Show the overall results in a table, from best to worst overall result, and with   any NQ results at the bottom (at the bottom of the list or as a note below the table).  The table will include the driver ID and names (including ‘(J)’ for juniors), and car model.  Display all 6

course times for each driver, as well as their overall result.  The winner should display “cup” next to their result, and the next 4 display “prize” (just the text is fine, or optionally suitable  alternative symbols).

• Bar graph: Display a horizontal bar graph of the top 5 drivers overall.  Modify the supplied

script in top5graph.html, but using driver names and overall results as passed variables instead of hard-coded constants.  The horizontal bars should use one of the 140 standard HTML colour  names (not pink or lime or anything too pale!), and make the max width sensible but considerably wider than 320 pixels.

Administrator Interface

• Junior driver list: Display the junior drivers including any caregiver names, ordered by age from oldest to youngest, then by surname.

• Driver search: Search for drivers by first name or surname, allowing for partial text matches.

• Edit runs: Enter or edit times, cones and WD for a run.  The admin will be able to select a driver and then edit any runs for that driver, or select a course to edit any runs for that course.

o The admin should not have tore-enter any existing values that are not being entered/ edited.

• Add driver: Add a new driver and assign them to an existing car.  (Do not add any new cars.)

o This must also add 12 blank runs (two for each course) with null times and cones.  WD will default to zero.  (Times, cones and WD will be entered using the Edit Runs feature above.)

o Must be able to specify whether new driver is a junior.  If so, must also enter a date of

birth, and calculate and record the age, and ensure that the driver has a caregiver, if

needed (provide a list of eligible caregivers to select from).  If not ajunior, none of these options (dateofbirth, caregiverselection) should be visible.

Report

Your report must be created using GitHub Markdown format and saved in the README.md file of

your GitHub repository.  It does not need to be a formal report – a tidy document using the following headings will be sufficient.  Write a brief project report that includes:

• Web application structure:

o Outline the structure of your solution (routes & functions, and templates).  This should be brief and can be text-based or a diagram (as animage).

o It must indicate how your routes and templates relate to each other, as well as and what data is being passed between them.

o Do not just give a list of your routes.  Do not include all of your code.  Do not describe the interface and user experience or html layout.

• Assumptions and design decisions:

o Detail any assumptions that you made (what isn't clear or stated in this brief that you had to assume or ask about).

o Discuss the design decisions you made when designing and developing your app (what design options you weighed up, why you designed your app the way that you did, your decisions about the routes, templates, navigation, broad layout, etc, that you made).

o Note your assumptions and your decisions as you work, so you do not forget them!  For

example, did you use multiple similar pages, or share some page templates perhaps with    hidden items?  Did you use GET or POST to request and send data, and how and why?  You will have considered many design possibilities.  These are only two examples.

• Database questions:  Refer to the supplied motorkhana_local.sql file to answer the following questions:

o What SQL statement creates the car table and defines its three fields/columns? (Copy and paste the relevant lines of SQL.)

o Which line of SQL code sets up the relationship between the car and driver tables?

o Which 3 lines of SQL code insert the Mini and GR Yaris details into the car table?

o Suppose the club wanted to set a default value of ‘RWD’ for the driver_class field.  What specific change would you need to make to the SQL to do this?  (Do not implement this    change in your app.)

o Suppose logins were implemented.  Why is it important for drivers and the club admin to access different routes?  As part of your answer, give two specific examples of problems  that could occur if all of the web app facilities were available to everyone.

• Image sources: It is not necessary to use any external images in your web app, apart from the 6 course diagrams provided, but if you do, ensure you reference the image source in your report.

Data Model

Model Notes:

* the ‘Foreign Key’

Cars are classed (drive_class) as one of ‘4WD’, ‘RWD’ or ‘FWD’ (4-wheel drive, rear-wheel drive, front-wheel drive).  Your app does not need to modify the data in this table in anyway.

Drivers with a date_of_birth must also have an age calculated and recorded.  Drivers aged 16 or younger must have a caregiver.  All drivers must have a car.

The driver’s driver_id is an ‘auto-incremented’ field.  That means that when adding a new driver, do not supply a driver_id; the database will assign one for you.

Each run record is for a particular driver (dr_id) on a particular course (crs_id) and is for the driver’s    first attempt or second attempt at that course (run_num, value of 1 or 2). cones is usually less than a handful and nevermore than 25. wd is a Boolean type field, shown in the model above as type

TINYINT(1), and defaults to the value 0 (false).

The number of courses at a BRMM competition Motorkhana is six (course_id is always A-F).

Project Requirements

You must:

•   Use only the COMP636 technologies (Python & Flask, Bootstrap CSS, MySQL).  Do not use SQLAlchemy or ReactJS (or other similar technologies) in your solution.

Do not use any scripts, including JavaScript, except for the