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
Top Related