UNITED STATES INTERNATIONAL

UNIVERSITY-AFRICA
COURSE TITLE : WEB APPLICATIONS
DEVELOPMENT

COURSE CODE : APP4050

SEMESTER/YEAR : FALL/2013

TASK : GROUP PROJECT

TOPIC : HOSTEL MANAGEMENT SYSTEM

PRESENTED TO : DR. G. CHEGE (PhD)

SUBMITED ON : 2ND DECEMBER, 2013

BY : GROUP

NAME : ID NO

SHADRACK BENARD KWEINGOTI 631448

RUSH KIRUBI 629964
DAVID SARI OTIATO 631088
ABSTRACT

Manual management of hostels is challenging since it involves a lot of work load and time consumption.
The system we have developed can easily manage the hostel details which include: Student records, room
details, and an easy way of allocating the rooms. Main feature of this application is to enable users to
login and update their profile, while choosing the rooms of their choice online. The main tools used to
develop the application are MySQL database and Php scripting language.

2|Page
Table of Contents
1. INTRODUCTION ................................................................................................................................ 6
1.1. Scope Definition ........................................................................................................................... 6
1.2. Existing System ............................................................................................................................ 6
1.3. Proposed System ........................................................................................................................... 6
1.4. Project Management strategy ........................................................................................................ 6
2. SYSTEM ANALYSIS AND DESIGN ................................................................................................. 7
2.1. CONTEXT DIAGRAM ................................................................................................................ 7
2.2. ENTITY RELATIONSHIP DIAGRAM ...................................................................................... 7
2.3. Data Flow Diagram ....................................................................................................................... 8
2.3.1. Room Application and Allocation Process ........................................................................... 8
3. System Implementation......................................................................................................................... 9
3.1. DATABASE IMPLEMENTATION............................................................................................. 9
3.1.1. TABLE: APPLICATIONS ................................................................................................... 9
3.1.2. TABLE: ROOMS ................................................................................................................. 9
3.1.3. TABLE: STUDENTS ........................................................................................................... 9
3.1.4. TABLE: USERS ................................................................................................................. 10
3.2. Web Interface .............................................................................................................................. 10
3.3. Scripting ...................................................................................................................................... 10
3.3.1. Php is used for server-side scripting. .................................................................................. 10
3.4. Database Connection .................................................................................................................. 10
3.5 Site Map ............................................................................................................................................ 11
4. SOFTWARE REQUIREMENTS SPECIFICATIONS....................................................................... 12
4.1. Introduction ................................................................................................................................. 12
4.2. Purpose........................................................................................................................................ 12
4.3. Scope ........................................................................................................................................... 12
4.4. ABBREVIATIONS, DEFINITIONS AND ACRONYMS ........................................................ 12
4.5. References ................................................................................................................................... 13
4.6. Overview ..................................................................................................................................... 13
5. General Description ............................................................................................................................ 13
5.1. Product Perspective ..................................................................................................................... 13
5.1.1. System Interface.................................................................................................................. 13

3|Page
 5.1.2. User Interface ...................................................................................................................... 13
5.1.3. Hardware Interface .............................................................................................................. 14
5.1.4. Software Interface ............................................................................................................... 14
5.1.5. Communication Interface .................................................................................................... 14
5.1.6. Memory Constraints ............................................................................................................ 15
5.1.7. Operations ........................................................................................................................... 15
5.1.8. Site Adaptation requirements .............................................................................................. 15
5.2. Product Functions ........................................................................................................................... 15
5.2.1. User Functions ........................................................................................................................ 15
5.2.2. Student Functions.................................................................................................................... 15
5.2.3. User Characteristics ................................................................................................................ 15
5.3. General Constraints ..................................................................................................................... 16
5.4. Assumptions and Dependencies.................................................................................................. 16
6. Specific Requirements ........................................................................................................................ 16
6.1. External Interface Requirements ................................................................................................. 16
6.2. Functional Requirements ............................................................................................................ 16
6.2.1. Administrator Functions ......................................................................................................... 16
6.2.1.1. Add User ......................................................................................................................... 16
6.2.1.2. View Applicants.............................................................................................................. 16
6.2.1.3. View Students ................................................................................................................. 17
6.2.1.4. Change Password ............................................................................................................ 17
6.2.2. Student Functions.................................................................................................................... 17
6.2.2.1. Profile.................................................................................................................................. 17
6.2.2.2. Apply Room .................................................................................................................... 17
6.2.2.3. Status of Application....................................................................................................... 18
6.2.2.4. View History ................................................................................................................... 18
6.2.2.5. Change Password ............................................................................................................ 18
6.3. Use Cases ........................................................................................................................................ 19
6.3.1. Hostel Management System Use Case Diagram ..................................................................... 19
6.3.1.1. Login ............................................................................................................................... 19
6.3.1.2. Manage User Accounts ................................................................................................... 20
6.3.1.3. Manage Student Activities .............................................................................................. 21

4|Page
 6.4. Non-functional Requirements ..................................................................................................... 21
6.4.1. Performance Requirements ................................................................................................. 21
6.4.2. Design Constraints .............................................................................................................. 22
6.4.3. Standards Compliance......................................................................................................... 22
6.4.4. Reliability ............................................................................................................................ 22
6.4.5. Availability ......................................................................................................................... 22
6.4.6. Security ............................................................................................................................... 22
6.4.7. Maintainability .................................................................................................................... 22
6.4.8. Portability ............................................................................................................................ 22
APPENDIXES ............................................................................................................................................ 23
Appendix A: (i) Project Task Schedule .................................................................................................. 23
Appendix A: (ii) Project Gantt Chart ...................................................................................................... 23
Appendix B: Database Relations ............................................................................................................ 23
Screen Shot of the users table ............................................................................................................. 23
Screen Shot of the students table ........................................................................................................ 23
Screen Shot of the rooms table ........................................................................................................... 24
Screen shot of the applicants table ...................................................................................................... 24
Appendix C: Web Interface .................................................................................................................... 24
Appendix D: Php Scripts ........................................................................................................................ 26
session.php .......................................................................................................................................... 26
functions.php....................................................................................................................................... 27
applyRoom.php ................................................................................................................................... 28
processProfile.php ............................................................................................................................... 31
profile.php ........................................................................................................................................... 32
Appendix E: Database Connection ......................................................................................................... 35

5|Page
 1. INTRODUCTION

1.1. Scope Definition

The Hostel Management System is an online application which will capture all the management activities
involved with the hostels. The administrator module is concerned with all administration details, while
the student module is concerned with management of student details in regards to the hostel. Students are
allocated rooms based on their availability. The student’s module enables them to apply for a room, and
manage their details. They then check their application status to check whether a room has been allocated
to them. The systems database will capture both the administrator details, and the student’s details.

1.2. Existing System

The current system offers a manual method of application; in which students fill in a form and submit to
the hostel administrator, who then keys in the student’s details into the system. Rooms are manually
allocated by the hostel administrator. It has been noted that the allocation system is biased in the sense
that the hostel administrator allocates rooms to those he personally know. This manual system has shown
to be slow, time consuming, and inconveniencing to the students.

1.3. Proposed System

The proposed system tries to solve the problems highlighted in the problems of the manual system. The
student’s module will enable a student to login into the system, and apply for a preferred room, after
which they wait for online room allotment. The admin module enables the administrator to allocate rooms
to students. The system will ensure that any hostel property will be accounted for by the occupants of the
room, this way, when an item is damaged or lost, the occupants of the room will be held responsible. The
system is online based, hence accessible from anywhere, and enables bias to be eliminated. Hence
students get the opportunity to get accommodation in the hostel on time. Labor costs are minimized, since
the system is automated

1.4. Project Management strategy

Refer to appendix A (i) and (ii): Project task schedule, and Project Gantt chart respectively.

6|Page
 2. SYSTEM ANALYSIS AND DESIGN

2.1. CONTEXT DIAGRAM

Application Application

STUDENT Allocated/Rejected HOSTEL MANAGEMENT Allocate/Rejected HOSTEL

SYSTEM

Fig 1: Context Diagram of Hostel Management System

In the context diagram above, the student applies for a room. The student either gets allocated to a room
or the application is rejected.

2.2. ENTITY RELATIONSHIP DIAGRAM

USERS
PK USER_ID

USERNAME STUDENTS
HASHED_PASSWORD
ADMIN PK STUD_ID
PK,FK1 USER_ID

FNAME
LNAME
ROOMS GENDER
PLACEOFRESIDENCE
PK ASSIGNED_ROOM_ID PHONENUMBER
ADDRESS
LOCATION PERSONALIMAGE
CONDITION

APPLICATIONS

PK APP_ID
PK,FK1 STUD_ID
PK,FK2 ASSIGNED_ROOM_ID

PREFERREDROOM
SEMESTER
YEAR
STATUS

Fig 2: ERD of Hostel Management System

7|Page
Student can apply only up to one room, and rooms can have many applicants. Applications can have
many rooms and students.

2.3. Data Flow Diagram

2.3.1. Room Application and Allocation Process

User Details Verify User User Details User

Valid User

Check
Application Applied User Applied Room
Status

Non Valid User

Apply Room Room Application

Allocate Room Applied Room

Receipt Payment

Bill Room Payment Finance

Fig 3: DFD of Hostel Management System

In fig 3 above, the system checks for an existing user, who may be a student or administrator, by
authenticating the username and password. If they don’t match the details in the database, the system will
return an invalid username and password message. If the credentials match the details in the database, the
system will check the student’s application status. The system then retrieves the student’s application
details.

8|Page
 3. System Implementation
The system is implemented using Apache web server, MySQL, and PHP. The administrator can access
the backend through PhpMyAdmin console provided by the Apache server.

3.1. DATABASE IMPLEMENTATION

The database is designed using MySQL database running on apache server. Each of the tables on the
database is identified by a unique primary key. Entities have been entered into their respective relations.

See appendix B: Database relations.

3.1.1. TABLE: APPLICATIONS

COLUMN PRIMARY DATA COMMENT
NAME KEY TYPE
app_id Yes int(10) Primary Key which is AUTO_INCREMENT
stud_id No int(10) Foreign Key references the students table.
preferredRoom No varchar2(20) Applicant chooses between a single or double room.
semester No varchar2(20) Applicant chooses the respective semester.
year No year(4) Applicant chooses the respective year.
assigned_room_id No Int(10) Foreign Key references the rooms table.
status No varchar2(20) Whether the applicant is assigned a room or not.

3.1.2. TABLE: ROOMS

COLUMN PRIMARY DATA COMMENT
NAME KEY TYPE
room_id Yes int(11) Primary Key which is AUTO_INCREMENT
location No varchar2(20) The location of the room
condition No varchar2(20) The rooms condition; whether its good or bad
type No varchar2(20) The type of the room; whether single or double.

3.1.3. TABLE: STUDENTS

COLUMN PRIMA DATA COMMENT
NAME RY KEY TYPE
stud_id Yes int(10) Primary Key which is AUTO_INCREMENT
fName No varchar2(3 The students First Name.
0)
lName No varchar2(3 The students Last Name.

9|Page
 0)
gender No varchar2(6) The students gender; whether Male or Female.
placeOfResi No varchar2(4 The students place of Residence.
dence 5)
phoneNumb No varchar2(2 The students phone number.
er 0)
user_id No int(10) Foreign Key references the users table
address No varchar2(2 The students address.
5)
personalIma No varchar(50) The students Image.
ge

3.1.4. TABLE: USERS

COLUMN PRIMARY DATA TYPE COMMENT
NAME KEY
user_id Yes int(10) Primary Key which is AUTO_INCREMENT
username No varchar2(20) The username.
hashed_password No varchar2(50) The HMS user respective passwords which are
encrypted.
admin No tinyint(1) HMS checks to confirm whether user is
administrator.

3.2. Web Interface

The web pages are created using html5 and php scripts. Here, php will also be used to create the session
cookies which will enable login and logout processes.

See appendix C: Web interfaces.

3.3. Scripting

3.3.1. Php is used for server-side scripting.

See appendix 4: Php scripts.

3.4. Database Connection

A single database connection file is created and called within each php script.

See appendix E: Database connection

10 | P a g e
3.5 Site Map

INDEX

ADMIN HOME STUDENT HOME

PROFILE
ADD USER

APPLY ROOM

VIEW APPLICANTS

STATUS OF
APPLICATION

VIEW STUDENTS
VIEW
HISTORY

CHANGE
PASSWORD

11 | P a g e
 4. SOFTWARE REQUIREMENTS SPECIFICATIONS
Preface

This section contains the Software Requirements Specification (SRS) Document for the Hostel
Managements System (HMS). The main aim is to enable online room application and allocation to the
students.

4.1. Introduction
The following subsections are an overview of the entire Software Requirements Specification (SRS)
document.

4.2. Purpose
This SRS section describes the design decisions and the detailed design needed to implement the system.
It defines the product functions, user characteristics, constraints under which it must operate, how the
system will react to external stimuli, and specific requirements of the system. The document is intended
for the users and the developers of the system.

4.3. Scope
HMS has the main aim of managing room application and allocation in a Web-based environment. The
overall system will consist of HMS Database System and HMS Web Interface. The HMS database system
will supply the fundamental database structure of the entire system whereas its Web Interface will provide
a secure Web interface between the users and the database. HMS aims towards establishing a “paperless
office” rather than using a manual system.

The objectives of the project are: To enable online room application and allocation in a timely manner, to
enable the students update their details online, to eliminate duplicate data, and to enable a smooth
communication channel between the system administrator and its users,

4.4. ABBREVIATIONS, DEFINITIONS AND ACRONYMS

DFD – Data Flow Diagram

ERD – Entity Relationship Diagram

SRS – Software Requirements Specifications

HMS – Hostel Management System

PHP – Hypertext Processor

12 | P a g e
HTML5 – Hyper Text Markup Language 5

MYSQL – Open source database application

SQL – Structured Query Language

Users – The people who will be actually using the system

4.5. References
 IEEE Standards 1016-1998, Recommended Practice for Software Design Descriptions

4.6. Overview
This document is prepared in accordance with the IEEE Standards 830-1998, IEEE Recommended
Practice for Software Requirements Specifications.

Section 5.0 of this document gives a general description of HMS. It also provides product perspectives,
product functions, user characteristics, general constraints, and assumptions and dependencies of the
system.

Section 6.0 contains additional design details. It will contain functional and performance requirements,
design constraints, attributes and external interface requirements for the HMS.

5. General Description
This section describes the general factors that affect the HMS and its requirements. This part of SRS
provides a background for the requirements for ease of comprehension.

5.1. Product Perspective

5.1.1. System Interface

The HMS is a complete web enabled system which can be accessed through web browser.

5.1.2. User Interface

The user interface is as follows:

Screen Name Description

Login Login into system as student or admin
Student Module: Profile Student can view and update personal details.
Student Module: Apply Room Student applies room by selecting the preferred
room, semester, and year.

13 | P a g e
Student Module: Status of Application
Student Module: View history
Student Module: Change Password
Student Module: Logout
Administrator Module: Add user
Administrator Module: View Applicants
Administrator Module: View Students
Administrator Module: Change Password
Student can check their application status.
Students can view history of past applications
Student can change his/her password.
After the student is done using the system, he/she
logs out.
Admin can add a new user by assigning new user
name and passwords respectively.
Admin can view the applicants by selecting the year
and semester.
Admin can view the student’s details.
Admin can change his/her password.

5.1.3. Hardware Interface

Client Side

Any Personal computer, which can support any X-window or Windows environment with a mouse
support, is acceptable.

Server Side

HMS will be run on a web server, which is installed into the school server.

5.1.4. Software Interface

Server Side

Apache Web server is installed and will enable HMS to interact with its users. PHP is a server-side
scripting language, which will be used to code the HMS.

Client Side

On the client side the required software product is Internet Explorer/Google Chrome/Mozilla Firefox
supporting at least HTML version 3.2, java enabled, and any operating system that can run the browsers.

5.1.5. Communication Interface

The default communication protocol for data transmission between server and the client is Transmission
Control Protocol/ Internet Protocol (TCP/IP). At the upper level Hyper Text Transfer Protocol (HTTP)
will be used for communication between the web server and client.

14 | P a g e
 5.1.6. Memory Constraints
The client computer, which runs the web browser, should have enough physical memory to run this
program.

5.1.7. Operations
The HMS operations needed by the users are described below.

 Administrator of the system creates and defines the status of users by (Add User). The user will be
given a unique username and password. The Admin may change their passwords by (Change
Password). The Admin can view applicants and also view the student’s details.

 The student accesses the system by logging in. They can view their profiles and update it (Profile),
Apply room, View Status of Application, View history and change their passwords.

5.1.8. Site Adaptation requirements

The school servers have requirements to operate PHP scripts (Apache Web server 1.3.2 with PHP 4.0
modules).

5.2. Product Functions

5.2.1. User Functions

 The administrator of HMS shall add new users to the system who is basically the student. After
entering the information about the user, the system gives a unique username and password to the
user.
 The administrator shall view applicants and students, and change password.

5.2.2. Student Functions

 The student shall view and update their profiles.
 The student shall apply a room.
 The student shall view the status of application.
 The student shall view their history and change their password.

5.2.3. User Characteristics

The Administrator

This user has to have at least Window 7/Linux OS and Internet browsing skills for administrating HMS
user profiles.

15 | P a g e
The Student

This user has to have at least Window 7/Linux OS and Internet browsing skills to use the system.

5.3. General Constraints

Academic rules and IEEE standards have to be observed throughout the entire requirement’s process.

5.4. Assumptions and Dependencies

 The system will not store any payment information; rather all payments will be handled by the
finance department of the university.

 Credit card payment or any other form of payment other than through the finance department is
not allowed on the system.

6. Specific Requirements

6.1. External Interface Requirements

The HMS uses the standard input/output devices for a personal computer. This includes the following:
Keyboard, Mouse, Monitor and Printer.

6.2. Functional Requirements

6.2.1. Administrator Functions

6.2.1.1. Add User

Introduction: HMS shall enable administrator to add new users to the system.

Input: username and password.

Process: The administrator activates the function and enters the username and password of the new user.
The function will also check the database whether the user already exists or not. According to the results,
the system adds the user to the all user list with a confirmation message, or the function displays an error
message.

Output: error message or confirmation message.

6.2.1.2. View Applicants

Introduction: HMS shall display all the applicants archived in the system.

Input: none

16 | P a g e
Process: The administrator selects the semester and year. The function queries the database for the
students who have applied for rooms.

Output: All applicants with their respective details (user id, preferred room, and assigned room id) will
be displayed.

6.2.1.3. View Students

Introduction: HMS shall display all the students in the system.

Input: none

Process: When the administrator logon the system, automatically, all student list is displayed. The
function queries the database for all the students.

Output: List of all students with their respective details (student id, first name, and last name, and
gender, place of residence, phone number, and address) will be displayed.

6.2.1.4. Change Password

Introduction: HMS shall enable administrator to change the password.

Input: old password, new password, confirm password

Process: Administrator activates the function to change the password. The new password and confirm
password fields are entered. If they match, the old password will be updated with the new one.

Output: Error or confirmation message will be displayed.

6.2.2. Student Functions

6.2.2.1. Profile
Introduction: HMS shall enable student to view and update their profile.

Input: none

Process: By this function, the database is queried for all the personal information of the student.

Output: All students’ personal information is displayed.

6.2.2.2. Apply Room

Introduction: HMS shall enable a student to apply a room.

Input: preferred room, semester, and year.

17 | P a g e
Process: By this function, the selected information is stored into the database.

Output: All students’ application information is stored into the database

6.2.2.3. Status of Application

Introduction: HMS shall enable the student to view the status of their room application.

Input: student id

Process: By this function, the database is queried for all the room application information of the student.

Output: All application status is displayed.

6.2.2.4. View History

Introduction: HMS shall enable the student to view their previous application history.

Input: student id

Process: By this function, the database is queried for all the previous room application information of the
student.

Output: All room application history is displayed.

6.2.2.5. Change Password

Introduction: HMS shall enable student to change the password.

Input: old password, new password, confirm password

Process: student activates the function to change the password. The new password and confirm password
fields are entered. If they match, the old password will be updated with the new one.

Output: Error or confirmation message will be displayed.

18 | P a g e
 6.3. Use Cases

6.3.1. Hostel Management System Use Case Diagram

6.3.1.1. Login
Use Case Login
Name

Introduction This use case describes how a user logs into the HMS.

Actors Administrator and Student.

Pre- None
Conditions

Basic Flow This use case starts when the actor wishes to login to the HMS which requests that the
actor enter his/her username and password. The actor enters his/her username &

19 | P a g e
 password. System validates username and password, and if finds correct allow the
actor to log into the system.

Alternate Flow Invalid name and password. If in the basic flow, the actor enters an invalid name and/or
password, the system displays an error message.

The actor can choose to either return to the beginning of the basic flow or cancel the
login, at that point, the use case ends.

Post-Condition If the use case is successful, the actor is logged into the system. If not, the system state
is unchanged.

6.3.1.2. Manage User Accounts

Use Case Name Manage User Accounts

Introduction This use case allows the administrator to maintain user account. This includes
adding, viewing applicants, view students and changing passwords.

Actors Administrator

Pre-Conditions The administrator must be logged on to the system before the use case begins.

Post-Condition If the use case was successful, the user is added, applicant information is viewed,
view student details, and admin can change his/her password. Otherwise, the system
state is unchanged.

Basic Flow This use case starts when the Administrator wishes to add a user, view applicant,
view student, and change his /her password.

The system requests that the Administrator specify the function he/she would like to
perform (Add User, View Applicant, View Student, or Change Password).

Once the Administrator provides the requested information, one of the sub-flows is
executed

If the Administrator selected “Add User”, the Add User sub flow is executed.

If the Administrator selected “View Applicant”, the

20 | P a g e
 View Applicant sub-flow is executed.

If the Administrator selected “Change Password”, the Change Password sub-flow is

executed.

Alternate Flow User Not Found: If a user account with the specified details does not exist, the
system displays an error message. The Administrator can then enter a different User
name or cancel the operation, at which point the use case ends.

Post-Condition The system shall add, view applicant, view student, and change password.

6.3.1.3. Manage Student Activities

Use Case Name Manage Student Activities

Introduction Allows the student to manage their various activities. This includes View Profile,
Apply Room, View Status of Application, View History, and Change Password.

Actors Student.

Pre-Conditions Student must be logged into the system.

Post-Condition If use case is successful, the student can view their profiles, apply room, view status
of application, view history and change password. Otherwise the system state is
unchanged.

Basic Flow Starts when student wishes to view Profile, Apply Room, view Status of Application,
and Change Password. The system requests the Student to specify the function;
he/she would like to perform.

Alternate Flow The system displays an error message if student information is unavailable.

Post-Condition The system shall view Profile, Apply Room, view Status of Application, and Change
Password for the student.

6.4. Non-functional Requirements

6.4.1. Performance Requirements

Performance requirements define acceptable response times for system functionality. Depending on the
user internet connection speed;

21 | P a g e
  The load time for user interface screens should take no longer than two seconds.

 The log in information shall be verified within five seconds.

 Queries shall return results within five seconds.

6.4.2. Design Constraints

The system is an online web application which runs on any operating system platform. It is developed
using PHP, HTML5 and MYSQL database.

6.4.3. Standards Compliance

There is consistency in variable names within the system. The graphical user interfaces have a consistent
look and feel.

6.4.4. Reliability
The system database connectivity has been designed with a persistent connection to ensure system
reliability. The system runs on a dedicated server to ensure that it is reliable at all times.

6.4.5. Availability
The system is available at all times, but a room application is open at the beginning of every semester to
ensure that rooms are available.

6.4.6. Security
The system has an authorization mechanism for users to identify their personal profiles. Therefore,
different users will have different authorization levels to access the data. The system should utilize certain
cryptographic techniques for instance SHA1 algorithm, encrypting passwords.

6.4.7. Maintainability
The system is developed using PHP, and PHP is a cross platform programming language which is easy to
maintain. Most of the PHP variables are global variables.

6.4.8. Portability
The HMS runs on any desktop computer supporting web browsing.

22 | P a g e
APPENDIXES

Appendix A: (i) Project Task Schedule

Appendix A: (ii) Project Gantt Chart

Appendix B: Database Relations

Screen Shot of the users table

Screen Shot of the students table

23 | P a g e
Screen Shot of the rooms table

Screen shot of the applicants table

Appendix C: Web Interface

Index.php

24 | P a g e
25 | P a g e
Appendix D: Php Scripts
session.php

<?php

26 | P a g e
include("includes/functions.php");

session_start();

function confirmLogIn(){

if(!logged_in()){

redirect_to("index.php");

function logged_in(){

return isset($_SESSION['user_id']);

?>

functions.php
<?php

$mainPage=false;

function mysql_prep( $value ) {

$magic_quotes_active = get_magic_quotes_gpc();

$new_enough_php = function_exists( "mysql_real_escape_string" ); // i.e. PHP >= v4.3.0

if( $new_enough_php ) { // PHP v4.3.0 or higher

// undo any magic quote effects so mysql_real_escape_string can do the work

if( $magic_quotes_active ) { $value = stripslashes( $value ); }

$value = mysql_real_escape_string( $value );

} else { // before PHP v4.3.0

// if magic quotes aren't already on then add slashes manually

if( !$magic_quotes_active ) { $value = addslashes( $value ); }

// if magic quotes are active, then the slashes already exist

return $value;

function redirect_to( $location = NULL ) {

27 | P a g e
 if ($location != NULL) {

header("Location: {$location}");

exit;

function confirm_query($result_set) {

if (!$result_set) {

die("Database query failed: " . mysql_error());

}}?>

applyRoom.php
<?php

$title="HMS | Admin - Apply Room";

require_once("includes/session.php");

confirmLogIn();

include("includes/header.php");

include("includes/connectDb.php");

//save details in applications table

if(isset($_POST['submit'])){

extract($_POST);

$query="INSERT INTO applications(stud_id, preferredRoom,semester,year,status)

VALUES('{$_SESSION['stud_id']}',

'{$pRoom}','{$sem}','{$year}','NOT ASSIGNED')";

$result=mysql_query($query,$connection);

confirm_query($result);

mysql_close($connection);

echo "<h3>Application successful!</h3>";

echo "<table class='pull-center'><tr><th>Preferred

Room</th><th>Semester</th><th>Year</th><th>Status</th><tr>";

28 | P a g e
 echo "<tr><td>{$pRoom}</td><td>{$sem}</td><td>{$year}</td><td>NOT
ASSIGNED</td></tr></table>";

?>

<form class="applyRoom" action="applyRoom.php" method="post">

<label>Preferred Room</label><select name="pRoom">

<option>------</option>

<option>Single</option>

<option>Double</option>

</select>

<label>Semester</label><select name="sem">

<option>------</option>

<option>Spring</option>

<option>Fall</option>

<option>Summer</option>

</select>

<label>Year</label><select name="year">

<option>------</option>

<option>2013</option>

<option>2014</option>

<input class="btn btn-success" type="submit" name="submit" value="Apply Room" />

</select>

</form>

<?php include("includes/footer.php");?>

processRooms.php

<?php

include("includes/session.php");

29 | P a g e
include("includes/connectDb.php");

$counter=0;

$names=array('a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z');

if(isset($_POST['confirmRooms'])){

// extract($_POST);

// echo $_POST['app'];

foreach ($_POST as $key => $value) {

if(preg_match("[^APP]",$key) ){

$counter++;

$count=$counter;

$counter=1;

foreach ($_POST as $key => $value) {

if(preg_match("[^rID]",$key) ){

if($value==''){

$query="UPDATE applications SET status='NOT ASSIGNED', assigned_room_id";

$query.="=0";

else{

$query="UPDATE applications SET status='ASSIGNED', assigned_room_id";

$query.="={$value}";

$query.=" WHERE app_id={$counter}";

//POST INDIVIDUAL ROOM ID TO DB:-

$result=mysql_query($query,$connection);

30 | P a g e
 confirm_query($result);

$counter++;

redirect_to("viewApplicants.php");

processProfile.php
<?php

include("includes/session.php");

require_once("includes/connectDb.php");

$target=NULL;

if(isset($_FILES['fUpload'])){

if($_FILES['fUpload']['type']=='image/png'||$_FILES['fUpload']['type']=='image/jpeg'){

$source=$_FILES['fUpload']['tmp_name'];

$target="images/profile/".basename($_FILES['fUpload']['name']);

$targetName=basename($_FILES['fUpload']['name']);

if(move_uploaded_file($source, $target)){

saveOtherDetails($targetName,$connection);

print("File uploaded successfully");

else{

if($_FILES['fUpload']['error']==UPLOAD_ERR_NO_FILE){

saveOtherDetails($targetName);

echo $_FILES['fUpload']['error']."<br />";

//$size=getImageSize($target);

// $imgstr="<p> <img width=\"size[0]\" height=\"size[1]\" ";

31 | P a g e
 // $imgstr.="src=\"$target\" alt=\"uploaded image\" />";

else{

redirect_to("profile.php");

echo $_FILES['fUpload']['error']."<br />";

print "Upload a jpeg/png photo";

function saveOtherDetails($targetName,$connection){

extract($_POST);

$targetName=mysql_prep($targetName);

$fname=mysql_prep($fname);

$lname=mysql_prep($lname);

$gender=mysql_prep($gender);

$pnumber=mysql_prep($pnumber);

$pOfRes=mysql_prep($pOfRes);

$address=mysql_prep($address);

$query="UPDATE students SET fName = '{$fname}', gender='{$gender}',

lName = '{$lname}',

placeOfResidence = '{$pOfRes}', personalImage='{$targetName}',

phoneNumber = '{$pnumber}',

address = '{$address}' WHERE user_id = {$_SESSION['user_id']}";

$result=mysql_query($query,$connection);

confirm_query($result);

redirect_to("profile.php");}?>

profile.php
<?php

$title="HMS | Student - Profile";

require_once("includes/session.php");

32 | P a g e
confirmLogIn();

require_once("includes/connectDb.php");

include_once("includes/functions.php");

include("includes/header.php");

$user_id=$_SESSION['user_id'];

$query="SELECT * FROM students WHERE user_id={$user_id} LIMIT 1";

$result=mysql_query($query);

confirm_query($result);

if(mysql_num_rows($result)==1){

$found_student=mysql_fetch_array($result);

?>

<div class="span3 offset9">

<?php

echo "<legend>Student Profile</legend>";

$html="<form method=\"post\" action=\"processProfile.php\" enctype=\"multipart/form-data\">";

$html.="<label>Upload profile picture</label><input type='hidden' name='MAX_FILE_SIZE'

value='2000000' /> <input type='file' name='fUpload' value='' size='60'/><br />";

$html.="<label>First Name</label><input type=\"text\" name=\"fname\"

value=\"{$found_student['fName']}\" />";

$html.="<label>Last Name</label><input type=\"text\" name=\"lname\"

value=\"{$found_student['lName']}\" />";

$html.="<label>Address</label><input type=\"text\" name=\"address\"

value=\"{$found_student['address']}\" />";

$html.="<label>Gender</label>";

$html.="<select name='gender'>";

if($found_student['gender']=='Male'){

$html.="<option selected='selected'>Male</option>";

$html.="<option>Female</option>";

33 | P a g e
else if($found_student['gender']=='Female'){

$html.="<option selected='selected'>Female</option>";

$html.="<option>Male</option>";

else {

$html.="<option>Male</option>";

$html.="<option>Female</option>";

$html.="</select><br />";

$html.="<label>Place of Residence</label><input type=\"text\" name=\"pOfRes\"

value=\"{$found_student['placeOfResidence']}\" />";

$html.="<label>Phone Number</label><input type=\"text\" name=\"pnumber\"

value=\"{$found_student['phoneNumber']}\"/>";

$html.="<input type=\"submit\" name=\"submit\" value='Save' class=\"btn btn-success\"/>";

$html.="<input type=\"reset\" name=\"reset\" value='Clear' class=\"btn btn-info\"/>";

$html.="</form>";

if(isset($_POST['submit'])){

echo $html;

if(!isset($_POST['submit'])){

if($found_student['personalImage']==NULL){

$html="<img class='pull-left' src='images/doe.png' />";

else if($found_student['personalImage']!=NULL){

$html="<img class='pull-left' height='250' width='250'

src='images/profile/"."{$found_student['personalImage']}' />";

$html.="<table class='profile'>";

$html.="<tr><td><strong>First
Name</strong></td><td><span>{$found_student['fName']}</span></td></tr>";

34 | P a g e
 $html.="<tr><td><strong>Last Name
</strong></td><td><span>{$found_student['lName']}</span></td></tr>";

$html.="<tr><td><strong>Address</strong>
</td><td><span>{$found_student['address']}</span></td></tr>";

$html.="<tr><td><strong>Gender</strong>
</td><td><span>{$found_student['gender']}</span></td></tr>";

$html.="<tr><td><strong>Place of
Residence</strong></td><td><span>{$found_student['placeOfResidence']}</span></td></tr>";

$html.="<tr><td><strong>Phone
Number</strong></td><td><span>{$found_student['phoneNumber']}</span></td></tr>";

$html.="<form method='post' action='profile.php'></tr>";

$html.="<tr><td><input type='submit' value='update' name='submit' class=\"btn btn-

success\"/></td></tr>";

$html.="</form>";

$html.="</table>";

echo $html;

?>

</div>

<?php include("includes/footer.php");

?>

Appendix E: Database Connection

<?php

$connection=mysql_connect("localhost","root","");

if(!$connection){

die("Database connection has failed ".mysql_error());

$db_select=mysql_select_db("hms",$connection);

if(!$db_select){

die("Database selection has failed ".mysql_error());

}?>

35 | P a g e
36 | P a g e