Sample TMA
This assesment, for block 2 of the module, is an example of the Tutor Marked Assignments (TMA) which are part of TT284. There are three such TMAs and an End of Module Assessment (EMA) which also has practical and written parts. The EMA is a substantial project drawing on earlier blocks which represents around five study weeks of work.TMA 02
Introduction
The TMA associated with this block, TMA 02, consists of two main parts:
- A Practical component (50% of the marks), which calls for you to produce a set of demonstration web pages to submit results and display event times sorted in a range of ways.
- A Reporting Component (50% of the marks), which asks you to review a small set of aspects relating to the development of a web presence for the Open University Running Club (OURC) and provide short discussions around these elements.
For the first part of the TMA you will find that if you have completed all the practical activities throughout Block 2 then you have already produced a similar set of web pages and need only adapt that work for a new form and database table.
For the second part of the TMA I will provide specific pointers to the case study elements that are particularly relevant although you will find that other sections you met earlier in Block 1 will also contribute to your overall understanding.
Please read the guidance in the TMA questions and guidance section of the TT284 Module Guide before answering the questions here.
If you need further guidance on any assignment questions, please ask your tutor who will be happy to help.
Section 1: Demonstration Web Pages
The practical part requires that you take a small set of web pages which are similar to those you developed in Block 2 of the module and reproduce these as a demonstration for the OURC. There are just three web pages which you need to develop for the prototype to demonstrate:
- Use of a form to submit data to a database table where the data is validated on the client side.
- Use of a PHP web page to receive form data and store this data in a database table.
- Use a PHP web page to retrieve and display data from a database table in a format specified by data from a form.
These three web pages are explained in detail in the following sections.
The form used to submit data to the PHP page in point 3 above is provided for you and does not require data validation.
As JavaScript, for example, can behave slightly differently in different browsers, I recommend that you use FireFox as this is freely available. Firefox 9.01 is the current version, which will be used when your work is assessed. This is available from:
http://www.mozilla.org/ en-US/ firefox/ fx/
If you cannot employ Firefox for some specific reason then you should contact your tutor to agree this and document which browser you have used by adding a note to the report part of your TMA.
When you produce your code remember that it is good practice to use external (JavaScript) files and include these in a reusable fashion when appropriate. Also remember that (PHP) functions are also good for supporting reuse, especially in handling matters such as database connections.
Form to submit data to a database
The operation of the form to submit data to a database table is outlined in Figure 1. The form contains a range of fields for entering data. This data needs to be validated on the client side using JavaScript. When the form is submitted to the server a page containing PHP scripts extracts the data from the posted information and stores this, using SQL ‘insert', into a database table.
Figure 1 Outline of the storage of data
The Data and Database Table
As you have started to become familiar with the TT284 case studies the demonstration can draw on these by employing a simplified data table from the parkrun case study. This study includes some details of the database tables that are used to hold information about events, event organisers, runners, runner categories and event results. These are reproduced below.
The database consists of five tables (Events, Organisers, Runners, Categories and Results) each of which has a number of fields shown in Table 1.
Table 1 Fields in parkrun database tables
| Events | Organisers | Runners | Categories | Results |
|---|---|---|---|---|
| EventID | OrganiserID | RunnerID | CategoryID | RunnerID |
| Name | FName | FName | Name | EventID |
| Postcode | LName | LName | AgeFrom | Date |
| GeoLat | AgeTo | FinishTime | ||
| GeoLong | Phone | DOB | Gender | Position |
| OrganiserID | Gender | CategoryID | ||
| AgeGrade | ||||
| PB |
To enter data into the database a set of forms can be used. Each form can submit data to one or more of the database tables. However for a demonstration we need only employ a single table. So, here I will focus on just the ‘Results' table.
The ‘Results' table has eight fields:
- RunnerID. This is a unique number assigned to a runner when they join parkrun which is used to identify the runner. A runnerID is between 1 and 99999, as numbers with up to five digits are allowed.
- EventID. This is a unique number assigned to an event. This has the same format as ‘RunnerID'.
- Date. This is the date of the event (and result). A date has the format YYYY-MM-DD.
- FinishTime. This is the time taken by the runner to complete the event. A time has the format HH:MM:SS.
- Position. This is the runner's finishing position. The finishing number is within the range 1-10000.
- CategoryID. This is a classification of the runner by age and gender. A category is a number in the range 1-100.
- AgeGrade. This is a calculated number which “Gives an indication of how well the runner has done relative to their age and gender”. The format of this is a percentage with two decimal places, for example 99.36 or 13.45.
- PB (personal best). This indicates if the time for the event ‘FinishTime' represents this runner's best ever time. It has the format ‘1' representing ‘true' or ‘0' (i.e. ‘false').
An example of this data is illustrated by the following samples.
| RunnerID | 309 | 18 | 306 | 892 |
|---|---|---|---|---|
| EventID | 12 | 201 | 210 | 187 |
| Date | 2011-02-28 | 2012-01-20 | 2012-01-15 | 2011-12-23 |
| FinishTime | 00:55:12 | 01:12:34 | 00:45:23 | 00:48:52 |
| Position | 34 | 86 | 27 | 112 |
| CategoryID | 3 | 2 | 2 | 2 |
| AgeGrade | 56.34 | 38.45 | 67.32 | 65.23 |
| PB | 0 | 0 | 1 | 0 |
The table has been created using the following SQL statement:
CREATE TABLE Results (
- RunnerID int,
- EventID int,
- Date date,
- FinishTime time,
- Position int,
- CategoryID int,
- AgeGrade float,
- PB boolean)
Note that the table is called ‘Results' and that this is NOT equivalent to ‘results' or ‘RESULTS'.
The Form and Validation
A form that can be used to submit a new row of table data to the Results table is listed in Appendix A (see Figure 2). This form is also available from the TT284 web site.
Figure 2 Form to submit a new runner time
The form as downloaded from the module web site currently has an action which posts the form to:
http://students.open.ac.uk/ mct/ tt284/ reflect/ reflect.php
which is the URL of a PHP page that writes out the names and values of the fields in a form. You will need to change this URL so that the PHP file receives the posted data instead.
So if your server account has a welcome page with URL:
http://oucu123.tt284.open.ac.uk/
where ‘oucu123' is replaced with your own Open University Computer User (OUCU) name, then if you have previously uploaded a PHP file to process the form data called ‘storedata.php' then the URL of that page (and the URL to post the form to) will be:
http://oucu123.tt284.open.ac.uk/files/storedata.php
The form should use validation so that values are checked before they are submitted to the server. Validation should ensure that the values conform to the description of the eight fields given earlier. This will mean for example that whilst the RunnerID is of type ‘int', which can store any number in the range -2147483648 to 2147483647, the form validation should seek to ensure the value is in the range 1 to 99999.
You should add validation to the form to ensure that appropriate values are filled in and also add a mechanism for providing feedback and guidance to the user when incorrect values are used.
Carefully test your form by clicking the submit button with different sets of data including missing values and incorrect values.
PHP to store values
After completing the form to submit data to the server the next stage is to develop PHP code to take the values from the form when they reach the server and then insert the values into a database table (Figure 1).
You should accomplish these two operations by using:
- The PHP '$_POST' superglobal variable which contains all the values submitted by a (posted) form. So for example the value of a form field named ‘date' is referenced by '$_POST['date'] '
- SQL within the PHP page to which uses an ‘insert' statement.
Within your server account on tt284.open.ac.uk you already have access to a suitable database table which can hold the data. The table called ‘Results' is displayed by the ‘Your database: Results table' web page which can be reached by clicking the ‘Results table page' link on your account's home page.
The table already contains some data, as illustrated below (Figure 3).
Figure 3 Display of Results table in a TT284 server account
You will need to take some care when handling some of these values in PHP and building SQL statements. For example a value such as ‘00:55:12' MUST be quoted inside an SQL statement to be legal. So if you have built the start of an SQL statement in a variable $start and you want to append this value which is help in $_POST[' FinishTime'] then to do this and create an SQL statement you need to introduce quotes:
$myQuery = $start . "'" . $_POST['FinishTime'] . "'";
Your PHP should:
- establish a connection with your database using your username and password given on your welcome page on the tt284.open.ac.uk server
- take the values posted by the form, for example $_POST[' RunnerID'] is the value for the RunnerID item and put these into an appropriate SQL statement to insert the data into the Results table.
- output a message for the user confirming what data has been added to the table. You can do this by simply echoing a message and the data values to the user.
This last item ‘3' is not illustrated in Figure 1 but it simply means that after submitting the form the user will be returned an HTML page confirming the data has been stored. An example of this feedback is shown in Figure 4.
Figure 4 Example of feedback when data is successfully saved
You can ascertain if the execution of the SQL insert statement succeeded by testing the value returned when the query is executed. So if the query is held in ' $myquery' and I have a database connection ' $conn' then I can execute the query:
$answer = mysql_query( $myquery, $conn);
and if successful then ' $answer' will be true (i.e. have a value ‘1') or false (‘0').
Page to display results
The final task of the practical element of this TMA is to produce the PHP needed to display the Results table in a sorted order that is selected by a user in a form. As this is a demonstration the form can be simple and so we will allow only three fields to be specified by the user.
To request display of the Results table a user will post a form which specifies:
- Whether to include the ‘AgeGrade' column in the displayed table. This might be because this data is regarded as somewhat sensitive and we might want to exclude it from some web public pages.
- Which field to sort the data on. This might be based on a particular interest in looking at all the results for one runner or one event for example.
- Whether to sort in ascending or descending order.
The operation of the PHP you are required to write is outline in Figure 5. The user selects the three options outlined above and submits the form to your PHP.
Figure 5 Operation of PHP web page to retrieve and display data
Note that you are given this form which is included as Appendix B (see Fig 6) and which is also available from the TT284 web site. Also note that here is no requirement or marks for adding validation to this form.
Figure 6 Form to request display of the Runner Results table
