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.
2.
INTRODUCTION ................................................................................................................................ 6
1.1.
Scope Definition ........................................................................................................................... 6
1.2.
Existing System ............................................................................................................................ 6
1.3.
Proposed System ........................................................................................................................... 6
1.4.
Project Management strategy ........................................................................................................ 6
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.
3.
Room Application and Allocation Process ........................................................................... 8
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.
3.4.
Php is used for server-side scripting. .................................................................................. 10
Database Connection .................................................................................................................. 10
3.5 Site Map ............................................................................................................................................ 11
4.
5.
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
General Description ............................................................................................................................ 13
5.1.
Product Perspective ..................................................................................................................... 13
5.1.1.
3|Page
System Interface.................................................................................................................. 13
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
Product Functions ........................................................................................................................... 15
5.2.
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
Specific Requirements ........................................................................................................................ 16
6.
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
Profile.................................................................................................................................. 17
6.2.2.1.
6.3.
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
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
STUDENT
Application
Allocated/Rejected
HOSTEL MANAGEMENT
SYSTEM
Allocate/Rejected
HOSTEL
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
STUDENTS
USERNAME
HASHED_PASSWORD
ADMIN
PK
PK,FK1
FNAME
LNAME
GENDER
PLACEOFRESIDENCE
PHONENUMBER
ADDRESS
PERSONALIMAGE
ROOMS
PK
ASSIGNED_ROOM_ID
LOCATION
CONDITION
APPLICATIONS
PK
PK,FK1
PK,FK2
APP_ID
STUD_ID
ASSIGNED_ROOM_ID
PREFERREDROOM
SEMESTER
YEAR
STATUS
Fig 2: ERD of Hostel Management System
7|Page
STUD_ID
USER_ID
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
Check
Application
Status
Applied User
Applied Room
Valid User
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
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
varchar2(20) Whether the applicant is assigned a room or not.
3.1.2.
No
COMMENT
TABLE: ROOMS
COLUMN
PRIMARY
DATA
NAME
KEY
TYPE
room_id
Yes
int(11)
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.
COMMENT
Primary Key which is AUTO_INCREMENT
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
9|Page
No
varchar2(3
The students Last Name.
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
er
The students phone number.
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
STUDENT HOME
ADMIN 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 can check their application status.
Student Module: View history
Students can view history of past applications
Student Module: Change Password
Student can change his/her password.
Student Module: Logout
After the student is done using the system, he/she
logs out.
Administrator Module: Add user
Admin can add a new user by assigning new user
name and passwords respectively.
Administrator Module: View Applicants
Admin can view the applicants by selecting the year
and semester.
Administrator Module: View Students
Admin can view the student’s details.
Administrator Module: Change Password
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.
Starts when student wishes to view Profile, Apply Room, view Status of Application,
Basic Flow
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 btnsuccess\"/></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