COMP284 Scripting Languages - Assignment 1: PHP
COMP284 Scripting Languages (2022-23) -- Assignment 1: PHP
Your task for this assignment consists of two parts:
- Develop a web-based application using PHP and MySQL that provides the functionality stated in the Requirements section below.
- Make the application that you have created accessible and usable via the URL taking care of the requirements set out in Submission and Setup section below.
Requirements
Our department would like to put a system in place that allows each student to choose their own practical sessions for each module instead of each student being allocated to a particular practical session for each module by the Timetabling Team.
Obviously, there will still be a fixed number of practical sessions with each practical session taking place at a particular time during the week in a particular lab, both determined by the Timetabling Team. Each practical session will also only be able to accommodate a certain number of students, in the following we will call this the capacity of the practical session. Initially, the number of (free) places on a practical session at a specific time is equal to its capacity and is then reduced by one for each student who books that practical session. Once the number of free places reaches zero, the practical session is full at that time and no further student can book it. We keep the range and capacity of practical sessions small. To further simplify things, we assume that students do not have to authenticate themselves to the system but instead enter a few personal details when they book a practical session.
In more detail, the system deals with the following practical sessions at the indicated times and all with the indicated capacity independent of the time at which the practical session is offered:
| Timetable of Practical Sessions Module | Times and Location Capacity | |
|---|---|---|
| COMP281 | Tuesdays, 11:00, Lab 2; Tuesdays, 15:00, Lab 2; Thursdays, 9:00, Lab 2; Thursdays, 15:00, Lab 2 | 3 |
| COMP284 | Mondays, 15:00, Lab 2; Tuesdays, 15:00, Lab 2 | 2 |
| COMP285 | Mondays, 9:00, Lab 3; Wednesdays, 13:00, Lab 3; Fridays, 15:00, Lab 3 | 2 |
That is, in total there are 9 practical sessions associated with three different modules, each with a capacity for only two to four students. For instance, two students can take the COMP284 practical session on Mondays, 15:00, in Lab 2, and another two can take the COMP284 practical session on Tuesdays, 15:00, in Lab 2. Note that lab sessions for two different modules takes place on Tuesdays, 15:00 in Lab 2 and this does not impact the capacity of these sessions.
The web-based system should allow a user
- select a module via a drop-down/pop-up list or selection menu;
- select a time at which a practical session for that module takes place via a separate drop-down/pop-up list or selection menu;
- enter their name via a text field;
- enter their e-mail address via a second text field (to uniquely identify students and to be able to contact them in case a practical session is cancelled);
- submit a booking request by pressing a `Submit' button, after selecting/entering the data above.
Ideally, students are able to enter all this data via a single web page (not a sequence of two or more pages). However, a sequence of web pages can be used if this is the only way that you are able to realise this system.
The menus should be populated with data from a database.
On submission of a booking request, a student should be shown a confirmation whether the booking request has been successful or unsuccessful. This confirmation should include all the details of the booking that was attempted. This is subject to the following conditions:
- The system should ensure that the string entered as a name satisfies the following constraints: A name only consist of letters (a-z and A-Z), hyphens, apostrophes and spaces; contains no sequence of two or more of the characters hyphen and apostrophe; and starts with a letter or apostrophe. If these constraints are satisfied, then we call the name valid. If these constraints are not satisfied, then the system should display an error message and the booking request must be unsuccessful. This must be realised using PHP (not HTML5 nor JavaScript).
- The system should ensure that the string entered by the user as an e-mail address has exactly one occurrence of @ that is preceded and followed by a non-empty sequence of the characters a-z, A-Z, dot, hyphen, and underscore where neither sequence ends in a dot or a hyphen. An e-mail address that satisfies these constraints is called valid and the check that the user has entered a valid e-mail address must be performed using PHP only. If the input of the user is not a valid e-mail address, then an error message should be shown and the booking request is unsuccessful.
- If name and e-mail address are valid, then a booking request must be successful if the selected practical session still has at least one place left. On success, the number of places on the selected practical session is reduced by one and a record of the booking will be kept in the database, including the module, time, name, and e-mail address.
- A booking request must be unsuccessful if there are no places left on the selected practical session.
Underlying the system must be a MySQL database. Initially, the database must contain information on the modules, times at which practical sessions for each module are offered and the capacity of each practical sessions. The database should then keep track of the number of free places after each successful booking requests and also keep records of each successful booking, including all the data that the user has provided. The PHP Data Objects (PDO) extension of PHP must be used to implement the interactions between your system and the database.
Additional requirements and comments:
- The description of the system above suggests that a user goes through a
sequence of five steps in order to submit a booking request. However, if
you use a single page design for your system, then there is little that
prevents a user from skipping a step or skipping all steps before clicking on
the
Submit' button. Your system should make sure that a request is only processed once theSubmit' button has been activated and should produce appropriate error messages if the request does not contain all the necessary data. But no error messages should be shown before activation of the `Submit' button. - The system would ideally help the user by only listing in the first menu the modules that have practical sessions with free places, and once a student has selected a particular module in that menu, would in the second menu only list the times at which a practical session with free places takes place.
- It would also be helpful to the user if entries in the two menus are listed in a `sensible' order, that is, modules should be ordered alphabetically and the times chronologically. Also, each module should only occur at most once in the first menu and each time at most once in the second menu.
- If a booking request is unsuccessful, then it should then be possible for a student to make another attempt with as little effort as possible. For example, if name and e-mail address were valid, but there were no places left on the selected practical session, then the system would ideally be programmed in such a way that there is no need to enter name and e-mail address again (but invalid data should not be carried forward).
- One should expect that all `inputs' to the system, even those that are intended to come from a menu, will be used by malicious users to inject code that causes your system to malfunction or reveal the contents of the database. You should program the system in a way that safeguards against such attacks.
- It is possible that two student nearly simultaneously try to book the last remaining place on a practical session. Depending on how you implement the interaction with the database, this could lead to a situation in which your system determines for both students that there is still a free place left and then records for both users that he/she has successfully booked that place. This is obviously an incorrect behaviour by the system and needs to be avoided. The booking request of exactly one of the two students must be successful and the booking request of the other has to be unsuccessful.
- There could be more students than the combined capacity of all the practicals. If someone tries to use the system once all places on the practicals have already been booked, then the system should produce a message indicating that all practicals are full instead of showing the various menus and text fields. The same should also happen if this situation occurs when a user re-enters the system after an unsuccessful booking request.
- As this is an assignment on PHP, the use of other scripting languages should be kept to a minimum. In particular, the use of JavaScript must be restricted to the JavaScript submit() function. User-defined JavaScript functions are not allowed.
- Use of the PHP superglobal $_GLOBALS is poor programming practice and its use will results in a lower mark.
- Your code should follow theCOMP284 Coding StandardActions . This includes pointing out which parts of your code have been developed with the help of on-line sources or textbooks and references for these sources.
Each of these requirements is linked to one of more of the assessment criteria for this assignment. Therefore, the more requirements a system satisfies, the higher the mark.
Submission and Setup
Create a single zip-file called COMP284-1.zip containing your HTML/PHP file and your MySQL database dump (but no directories) and submit the zip-file via the departmental submission system at to an external site. (COMP284-1: PHP).
Do not forget to also set up the database on the departmental MySQL server, to make practicals.php accessible via the departmental web server, and to correctly connect the two.
The files submitted must be identical to those set up on the departmental web server. Furthermore, no alterations are allowed to the latter after files have been submitted. If a submitted file and the corresponding file on the departmental web server have different timestamps, then the later timestamp will be used to determine lateness. This applies even if the earlier file is used for marking. Permissions of the files in your filestore must be such that no other user can view their contents in the filestore. The permissions on your public_html directory must be such that any user can obtain a listing of its content.
Earlier submission is possible, but any submission after the deadline attracts the standard lateness penalties. Please remember that a strict interpretation of `lateness' is applied by the Department, that is, a submission a minute after the deadline is considered to be a day late (analogously for submissions that are delayed further). Also remember that late resubmissions are not allowed.
