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 :

SHADRACK BENARD KWEINGOTI

RUSH KIRUBI

DAVID SARI OTIATO

ID NO

631448

629964

631088

2 | P a g e

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.

3 | P a g e

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

4 | P a g e

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

5 | P a g e

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

6 | P a g e

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 students 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 students 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 students 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

students 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.

7 | P a g e

2. SYSTEM ANALYSIS AND DESIGN

2.1. CONTEXT DIAGRAM

HOSTEL MANAGEMENT SYSTEM

STUDENT HOSTEL

Application Application

Allocate/RejectedAllocated/Rejected

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

ROOMS

PK ASSIGNED_ROOM_ID

LOCATION CONDITION

STUDENTS

PK STUD_IDPK,FK1 USER_ID

FNAME LNAME GENDER PLACEOFRESIDENCE PHONENUMBER ADDRESS PERSONALIMAGE

USERS

PK USER_ID

USERNAME HASHED_PASSWORD ADMIN

APPLICATIONS

PK APP_IDPK,FK1 STUD_IDPK,FK2 ASSIGNED_ROOM_ID

PREFERREDROOM SEMESTER YEAR STATUS

Fig 2: ERD of Hostel Management System

8 | P a g e

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

Valid User

Non Valid User

User

Applied Room

Finance

Verify User

Check Application

Status

Apply Room

Allocate Room

Bill Room

Room Application

Applied Room

Receipt Payment

User Details

Applied User

Payment

User Details

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 dont 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 students application status. The system then retrieves the students application

details.

9 | P a g e

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

NAME

PRIMARY

KEY

DATA

TYPE

COMMENT

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

NAME

PRIMARY

KEY

DATA

TYPE

COMMENT

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

NAME

PRIMA

RY KEY

DATA

TYPE

COMMENT

stud_id Yes int(10) Primary Key which is AUTO_INCREMENT

fName No varchar2(3

0)

The students First Name.

lName No varchar2(3 The students Last Name.

10 | P a g e

0)

gender No varchar2(6) The students gender; whether Male or Female.

placeOfResi

dence

No varchar2(4

5)

The students place of Residence.

phoneNumb

er

No varchar2(2

0)

The students phone number.

user_id No int(10) Foreign Key references the users table

address No varchar2(2

5)

The students address.

personalIma

ge

No varchar(50) The students Image.

3.1.4. TABLE: USERS

COLUMN

NAME

PRIMARY

KEY

DATA TYPE COMMENT

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

11 | P a g e

3.5 Site Map

INDEX

ADMIN HOME STUDENT HOME

ADD USER

VIEW APPLICANTS

VIEW STUDENTS

CHANGE

PASSWORD

PROFILE

APPLY ROOM

STATUS OF

APPLICATION

VIEW

HISTORY

12 | 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

13 | 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.

14 | 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 students 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.

15 | 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 students 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.

16 | 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 requirements 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

17 | 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.

18 | 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.

19 | P a g e

6.3. Use Cases

6.3.1. Hostel Management System Use Case Diagram

6.3.1.1. Login

Use Case

Name

Login

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

Actors Administrator and Student.

Pre-

Conditions

None

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 &

20 | 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

21 | 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;

22 | 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.

23 | 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

24 | P a g e

Screen Shot of the rooms table

Screen shot of the applicants table

Appendix C: Web Interface

Index.php

25 | P a g e

26 | P a g e

Appendix D: Php Scripts

session.php

27 | 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

28 | 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

29 | P a g e

echo "{$pRoom}{$sem}{$year}NOT

ASSIGNED";

}

?>

Preferred Room

------

Single

Double

Semester

------

Spring

Fall

Summer

Year

------

2013

2014

processRooms.php

30 | 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);

31 | P a g e

confirm_query($result);

$counter++;

}

}

redirect_to("viewApplicants.php");

}

processProfile.php

32 | P a g e

// $imgstr.="src=\"$target\" alt=\"uploaded image\" />";

}

else{

redirect_to("profile.php");

echo $_FILES['fUpload']['error']."";

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

33 | 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);

}

?>

34 | P a g e

else if($found_student['gender']=='Female'){

$html.="Female";

$html.="Male";

}

else {

$html.="Male";

$html.="Female";

}

$html.="";

$html.="Place of Residence";

$html.="Phone Number";

$html.="";

$html.="";

$html.="";

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

echo $html;

}

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

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

$html="";

}

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

$html="";

}

$html.="";

$html.="First

Name{$found_student['fName']}";

35 | P a g e

$html.="Last Name

{$found_student['lName']}";

$html.="Address

{$found_student['address']}";

$html.="Gender

{$found_student['gender']}";

$html.="Place of

Residence{$found_student['placeOfResidence']}";

$html.="Phone

Number{$found_student['phoneNumber']}";

$html.="";

$html.="";

$html.="";

$html.="";

echo $html;

}

?>

Appendix E: Database Connection

36 | P a g e