m00299151 - cmt3313 - lunch order system - phase 2

Lunch Order System Phase 2

CMT 3313 Client Server Web System Development

David Vella M00299151

20th May 2010

Client Server Web System Development P a g e | 1

Table of Contents

1 Introduction .............................................................................................................................. 3

2 Functional Requirements ........................................................................................................... 3

2.1 Back-Office Application ...................................................................................................... 3

2.1.1 1.1 User Manager ....................................................................................................... 3

2.1.2 Lunch Provider Manager............................................................................................. 5

2.1.3 Menu Manager ........................................................................................................... 6

2.2 Lunch Order System Frontend ............................................................................................ 7

2.2.1 Register Page .............................................................................................................. 7

2.2.2 Forgot Password Page ................................................................................................ 8

2.2.3 Login Page .................................................................................................................. 8

2.2.4 My Account ................................................................................................................ 9

2.2.5 Lunch Provider ......................................................................................................... 11

2.2.6 Lunch Provider Menu ............................................................................................... 12

2.2.7 Reports Section ........................................................................................................ 14

2.3 Order Handling Process .................................................................................................... 15

2.3.1 Order and Roster Semantics ..................................................................................... 16

2.4 Order Lifecycle ................................................................................................................. 16

3 Technical Requirements ........................................................................................................... 17

3.1 System Architecture ......................................................................................................... 17

3.2 Other Design Considerations ............................................................................................ 19

3.2.1 Permission Based System ......................................................................................... 19

3.2.2 Server-side Data Validation ...................................................................................... 19

3.2.3 Application Configuration ......................................................................................... 20

3.2.4 Security Considerations ............................................................................................ 20

3.2.5 System Emails........................................................................................................... 20

3.2.6 AJAX Technologies Used ........................................................................................... 21

3.3 Database Schema ............................................................................................................. 22

3.3.1 LunchOrder .............................................................................................................. 23

3.3.2 LunchOrderStatus ..................................................................................................... 24

3.3.3 LunchProvider .......................................................................................................... 24

3.3.4 MenuItem ................................................................................................................ 25


3.3.5 MenuItemCategory .................................................................................................. 26

3.3.6 Module..................................................................................................................... 27

3.3.7 Permission ................................................................................................................ 27

3.3.8 Role .......................................................................................................................... 28

3.3.9 RolePermission ......................................................................................................... 29

3.3.10 User ......................................................................................................................... 30

3.3.11 UserOrder ................................................................................................................ 31

3.3.12 UserOrderStatus ....................................................................................................... 32

3.3.13 UserRole ................................................................................................................... 32

4 Future Enhancements .............................................................................................................. 34

5 Tools Used ............................................................................................................................... 35

6 Deployment ............................................................................................................................. 36

6.1 Prerequisites .................................................................................................................... 36

6.2 SQL Scripts ....................................................................................................................... 36

6.3 Source Code ..................................................................................................................... 36

7 References ............................................................................................................................... 38

7.1 Sites Used ........................................................................................................................ 38

7.2 Books Used ...................................................................................................................... 38


1 Introduction

In this document I will go through all the functionality done for the second phase of the Lunch Order

System. The second phase of the project consisted in creating an engine that the Lunch Order

System will run as to process and execute order data from end users. The main technologies used for

the project are a mix of client side and server side technologies using JavaScript, AJAX and PHP,

driven by a MySQL database. The application will be running on an Apache Web Server.

The document will go through the following core functionality:

Back Office Application

User Accounts

Ordering Process

Roster Management

Basic reporting functionality

2 Functional Requirements

Due to time restrictions, only the core functionality for the Lunch Order System will be developed.

The back-office application, the section of the application that will be accessed only by

Administrators; will consist only of the following modules: User Manager, Lunch Provider Manager,

and a Menu Manager. These will be used to manage the data that will be accessed by the users in

order to submit their orders. The second part of this section will describe the frontend functionality

that will be accessed by normal users to view Lunch Providers Menus and make their orders.

2.1 Back-Office Application

The back-office application, or rather, the administrative view of the application, will feature a

number of modules as to support the Lunch Order System. This view will be accessible to the user, if

the logged in user has administrative rights. If the user has administrative rights, in the top menu a

link named “Administration” will be viewed. The Administration Modules to be developed will

consist of the following modules.

2.1.1 1.1 User Manager

From the User Manager Administrators will be able to list all the users registered in the system.

Administrators will be able to create new accounts (e.g. accounts with administrative rights), edit

existing accounts and delete accounts.


A slightly different view will be made available (from the usual Registration Form) to the

Administrator when inputting details. The Administrator will be prompted to input or assign the

default role for the user to be created (or edited). The current data structure supports multiple roles;

however, the actual implementation will not be done due to time constraints. The system will be

deployed with two default roles: Administrator Role – having access to all the system functionality,

Normal User Role – having access to the order functionality only.

2-1 User Manager

2-2 Add/Edit User


2.1.2 Lunch Provider Manager

This manager will be used to list the current providers in the system for the users to submit their

orders to. This manager will be accessible to users having an Administrator Role or equivalent role (a

role which has the necessary rights to access this module) to list the current lunch providers, create

new lunch providers, edit existing lunch providers, and deleting lunch providers.

This manager will also be used to define some constraints for the lunch providers, that is, the

Minimum Order Price to be delivered, Delivery Charges, and the Order Take Time to close the order

and submit the order to the lunch provider.

Administrators will also be able to select a number of featured lunch providers to be presented to

the users in the main page for marketing purposes requirements by the management.

Administrators will be provided the means to select these providers by just ticking the required

providers.

2-3 Provider Manager

2-4 Add/Edit Provider


2.1.3 Menu Manager

The Menu Manager will list all the menus items in the current system, organized by Lunch Provider.

Administrator will be able to organize and manage the various menu items by Lunch Provider.

Administrators will be able to classify menu items by their category, e.g. drinks, pasta, pizza,

sandwiches, etc and create, edit and delete menu items for a particular provider. From the Menu

Manager, Administrators will be able to set a price for the particular menu item and a Default

Availability field to define the maximum order items that the lunch provider can satisfy for that

particular menu item for a single day. If this is set to zero, unlimited orders can be submitted for that

particular menu item. As in the Provider Manager, the Menu Manager will have the necessary

functionality to select a number of featured menu items to be displayed in the main page for

marketing purposes.

2-5Menu Manager


2.2 Lunch Order System Frontend

The features present in the frontend system were influenced from some research done on other

sites. Sites similar to this application were taken in consideration are:

• http://www.amiyarestaurant.com

• http://www.2goclub.com

• http://www.foodyoyo.com

• http://www.urbanbite.com

In this section I will go briefly through the functional requirements of the application, as these where

already discussed in the previous document for the first phase of the project.

2.2.1 Register Page

When a user having no user account with the lunch order system, the user is provided with a

registration form to get instance access to the system and submits his or her orders. The user will be

required to input a Username and a Password, and some other personal details and contact

information. Some important aspects for this page are: validation used and a password strength

meter as to provide a strong password.

Apart from the client side validation, when the actual implementation is done, server side validation

will also be done for the existence of the Username and Email fields in database as to check if these

already exist.

2-6 Registration Form


2.2.2 Forgot Password Page

The Forgot Password page consists of an input element for the user to enter his or her email. The

same validation rule applies a in the Registration Form for the validation of the email address. The

user will input the email address used to register. The email will be validate against the email stored

in the database; if the email is valid then a new password will be generated and sent to the user via

email.

2.2.3 Login Page

The Login Page consists of a username and password text fields for the user to provide with valid

credentials as to login into the system. Apart from checking these fields for validation, the actual

implementation will involve a check in the database for the existence of the supplied user account. If

the credentials are valid, the User ID will be stored in session and the user will be granted access to

the system. The Login Page will determine also the role that the user will be using for accessing the

system.

2-7 Login Page

Note that the Forgot Password functionality can be accessed from the top menu. Along the with the

Register, Login and Help links.


2.2.4 My Account

When the user logs into the system he or she will be give access to the following sub-sections:

2.2.4.1 Change Password

The change password form consists of the following fields:

Username: displayed as read-only Old Password: the current password the user is using to access the system New Password: the new password required by the user Confirm New Password: used to compare the password inputted in the New Password field

When the user submits the form a check will be made with the database against the old password. If

the old password matches that of the database then the new password will be encrypted (using

MD5) and persisted to database.

2-8 Change Password

2.2.4.2 Edit Account Details

This form will be used to update the details for the logged in user. The same validation rules as in the

registration form apply here as well. It is important to note once the username is chosen it cannot be

change by the user, unless he or she has admin access.

2.2.4.3 My Orders

The My Orders form will be used to list the orders done in the past, and any current existing order.

Each order will feature a heading providing information such as: Lunch Provider, the Order User

Reference, the date when the order was done, the amount and delivery status. Each order items will

be displayed using the jQuery Accordion plugin. This will create a menu like list and is used to view a

detailed breakdown of the order showing: all the menu items for the order, their quantity and the

price for each. This section will feature only the last ten orders for the user.


2-9 My Orders

2.2.4.4 Order Report

To list or search every order done for the user an Order Report page will be created. This screen will

allow the user to search for a particular order, date range, and lunch provider. When the user

submits the form a query (when the actual implementation will be done) will be executed against

the database and search for his or her orders.

2-10 Search Order Report


2.2.4.5 Roster

The Roster page will be available only if the current logged in user is on roster for a particular order.

The person on the roster is decided as the person who submitted less orders to the lunch providers

within a particular order. This screen will feature the order information such as the Order Reference,

the total amount to be paid, the lunch provider selected and eligibility for free delivery. Apart from

these fields the user will be able to delegate (manual over ride) the responsibility to call the lunch

provider to another user selected from a list provided. Another field will be provided as to change

the status for the order and notify the users of the current status: Open (users can submit orders to

this lunch provider), Order Submitted (order was closed and submitted to the lunch provider),

Undelivered (order was not delivered by lunch provider) and Delivered (Order delivered by lunch

provider). This screen will also feature the necessary functionality to mark which orders has been

paid by ticking a checkbox near each user order.

2-11 User Roster

2.2.5 Lunch Provider

The Lunch Provider section will feature the complete list of lunch providers available in the system.

The list will feature the title for the lunch provider, some information about the lunch provider,

address and contact details, logo, and a link to view the menu for the lunch provider. The pagination

functionality was provided using the jQuery plugin Pagination. The Lunch Provider section will also

feature a search section as to provide the user with basic search facilities to search for a particular

lunch provider.


2-12 Lunch Providers

2.2.6 Lunch Provider Menu

The lunch provider Menu page will consist of the list of available menu items for a particular lunch

provider selected by the user from the dropdown list provided or from a previous step from the

lunch provider section. The list will feature some information about the menu item, the featured

category, lunch provider information and the base price for the menu items. It has to be noted, that

in the actual implementation a check will be made against the database table for the menu items as

to check if the current menu item is available for order, by checking the Default Available field (as

this will specify the maximum availability for a particular item). If the item is available the user will

be able to click on the “Add To My Order” button provided to add the item to his or her order. Using

the jQuery DOMWindow plugin a modal popup will be show to the user prompting to input the

quantity required and some comments (optional) for the lunch order provider. The user will confirm

the order item to be added to the user order by clicking on the “Add to My Order”. The order item

will appear in the list of orders in the Right Section of the page, by listing the ordered item, its

quantity and price. Also in the Right Section underneath the My Order section, the user order will be

exposed as to allow other users what current orders are submitted and buy from an already chosen

provider (as to provide the total necessary to be eligible for free delivery defined by the

MinOrderPrice in the LunchProvider table). From the My Order section the logged in user will be

able to modify the quantity or remove the order from his or her order list.


2-13Menu List

2-14 Add/Edit Menu Order Item


2-15 My Orders/Current Orders

In the Right Section of the page the Current Orders will be displayed to every lunch provider chosen. Orders will be organised by lunch provider and every order will provide the following information:

The total number of ordered items The total price for order Free delivery eligibility (Can Be Delivered field) User On Roster (who will be calling the lunch

provider) The Order Take Time (when the order will be closed

and submitted to the lunch provider) Order Status

2.2.7 Reports Section

Reports Section (Facts): The report section currently features two reports:

• Lunch Provider Monthly Report

• User Orders Monthly Report

The reports generated will consist of a summary of the actual amount of money spent as global

figure across all users in the system for the Lunch Provider Monthly Report. In the case of the User

Orders Monthly Report the figures given in this report are for the user logged in the system. Note

that this section will be restricted to users having access to the system.


2.3 Order Handling Process

The below flowchart shows the flow of handling an order item when the user selects the item from

the menu and submits the selected item to the lunch provider order.

Start

Choose Provider

List

Providers

List Menu

Items

Choose Menu

Item

User Already

Submitted

Order Item?

Same Lunch

Provider?

Error: User Can

Submit Orders to

the same provider

Check Item

Availability

Is Available?

Error: Item

not available

Add Item To

Order

End

Check Roster

Schedule

Assign User to Roster

for lunch order

Yes

Yes

Yes

No

No

No

2-16 Order Handling Process


2.3.1 Order and Roster Semantics

Users buying from the system will be able to choose their favorite lunch provider for the day and can

only buy from one single provider on that particular day. Other users of the system will also be able

to submit orders to the same lunch provider. If the total price for the amount of lunch orders

submitted exceeds the minimum amount define for the lunch provider (in system), the users who

have ordered from that lunch provider will get free delivery. If the total price for the orders is lower

than the value defined for the lunch providers the user can opt for delivery all the same, however

will be charged for the delivery. Another option would be that the person in charge of the orders (on

the roster for that day) will go at the lunch provider’s place and get the lunch order himself.

The roster for the person responsible of the lunch order for a group of orders submitted to a

particular lunch provider will be determined according to the distribution of the amount of orders a

particular person has done. That is, if four people (User A, User B, User C and User D) has submitted

their lunch order and User B is the person who has done the least orders for that group, User B will

be responsible for the lunch order, to call the lunch provider, collect the money and get the order.

This will be updated as the orders will be submitted by different users of the system for the same

lunch provider until the Order Take Time, that is, when the order is closed and the lunch provider

will be called. It is assumed that if initially the group of persons submitting their orders for a lunch

provider never submitted an order, that last person submitting the order will be responsible for the

order. The Take Time for the order will be different for all lunch providers as defined in the system.

All users submitting the orders will be required to pay the person in charge for the order take in. The

user responsible for the order will go into the system and check the payment status for each order

item. If the user order is not paid before the take in that user order will be dropped by the system.

The money will be collected manually by the person in charge for all the orders. It is important to

note that only the person responsible for the order will be able to set the status for each order item.

2.4 Order Lifecycle

An order for a particular lunch provider will follow the below lifecycle:

• Open – A lunch order having this status will be open for users to submit their orders, edit

order details and remove ordered items.

• Closed – When a lunch order is closed (e.g. take time exceeded), user will not be able to

add other menu items to order or amend existing items.

• Awaiting Payment – Order was closed but some ordered items were not paid. This is an

optional step, where the user responsible for the roster, blocks the order from being

submitted until all items are paid beforehand.

• Confirmed – All items were paid and can be submitted to lunch provider.

• Submitted – Ordered items were submitted to lunch provider.

• Delivered – Ordered items were successfully delivered.


3 Technical Requirements

In this section I will describe the design considerations taken for the development of the Lunch

Order System.

3.1 System Architecture

The system is based on a two layer system, the Presentation Layer and the Data Access Layer. Since

the domain logic isn’t too complex, limited to only creates, reads, updates, and deletes, an Active

Record pattern [Martin Fowler (2002) Patterns of Enterprise Application Architecture] was

employed.

An Active Record object carries both data and behaviour. The data contained in this object is usually

persisted to database. All reads and writes to database are achieved through an instance of an

Active Record object. All classes implementing the Active Record pattern match very closely the

record structure of the underlying database. Each Active Record is responsible for saving and loading

to the database and also for any domain logic that acts on the data. The data structure of each

Active Record exactly matches that of the database, that is, one field in the class represents a

column in the database table. These are implemented through getters and setters. These provide

also some basic validation and converts SQL oriented types to better in-memory types.

+escapeString()

+getError()

+isValid()

+ErrorList

+DatabaseConnection

DomainObject

+getUser(in UserID)

+getUserList()

+create()

+update()

+delete()

+UserID

+Name

+Surname

+Username

+Password

+Email

+Telephone

+DefaultRole

+Active

User

Lunch Order

System

MySQL

3-1 Active Record Pattern

The below diagram shows the Active Record object for the User entity. The User Active Record

object will be delegated with the responsibility of reading from the database and persisting the data


from the presentation layer into the database. Each attribute in this object is implemented through

getters and setters. The object also provides some basic CRUD functionality through the create(),

update(), delete(), getUser(), and getUserList() functions. Note also, that on direct access is given to

the presentation layer to the database. All queries and connectivity to database are known only by

the Active Record Patter object. Another important point to note is that each Active Record pattern

inherits from the DomainObject class. This provides the common functionality to all objects in the

domain, such as, database connectivity, error checking and retrieving, etc.

The DomainObject class also instantiates another class; the Database class. The Database class is a

wrapper class providing database connection information and helper methods to facilitate the

connection to database and execute the required queries. All connections are handled by this class

avoiding a lot of redundant code and waste of time. The Database class implements the following

functions:

setServerName($value) – sets the server name where the MySQL database is hosted

setDatabase($value) – sets the database name to access and execute queries

setUsername($value) – sets the username to access database

setPassword($value) – sets the password to access database

connect() – opens a new connection to a MySQL database

close() – close a connection initiated by the Database connection class

escapeString($value) – returns the same string with all SQL Injection attempts safely escaped

executeQueryDB($sqlQuery) – execute a select query statement against a table in database

and return a list of record or record in an array.

executeNonQueryDB($sqlQuery) – execute an update, insert or delete query statement

against a table in database. This method will return the value of an auto-number column or

the count of modified for an update or delete statement.


3.2 Other Design Considerations

In this section I will discuss some design decisions and considerations for the development of the

Lunch Order System.

3.2.1 Permission Based System

The application is designed to support multiple user roles. That is, each user in the system is bound

to a role or multiple roles (selected during login), each role having a limited number of permissions

to perform certain operations that were assigned to that specific role.

Role

Session

Permission OperationUser

3-2 Permission Bases System Model

The actual implementation of the system, assumes that each role is bound to a default role when it

is created. Though multiple roles are supported, only a single role model was implemented. So when

the user logs into the system the default role is stored into the session. When the user access a

particular resource such as an Administration module, at top of the page a check is made against the

Role table in the database so as to check if the user can perform the required operation. If the user

has the required permissions, execution of the operation will follow, else the user will be redirected

to a page with a message stating that the required operation cannot be performed.

3.2.2 Server-side Data Validation

All server side validation is performed by the Active Pattern objects (discussed in the previous

section). In each setter method, the required validation is performed using, data length and type

checking and making use of Regex patterns and functions provided by the PEAR library package.

PEAR or PHP Extension and Application Repository is a framework and distribution system for

reusable PHP components.

When an error is found during the validation process, a flag in the domain object is set and the error

is pushed on to a stack of errors. When all setter operations are checked, all errors detected are

popped from this stack and rendered on screen, prompting the user to fix the error.


3.2.3 Application Configuration

All configurations to the project are stored in a configuration file, config.ini. The file is divided into

several sections, Database, System, Application, etc. The former is used to store database related

information, having attributes such as SERVER, DATABASE, USERNAME, and PASSWORD. The latter

stores generic information, such as path to libraries, system emails, etc. The config.ini file is being

protected by a .htaccess file blocking users from downloading or viewing the file as follows:

<Files config.ini>

order allow,deny

deny from all

</Files>

3.2.4 Security Considerations

Some important points to consider are that all user input is being escaped using

mysql_real_escape_string(). The mysql_real_escape_string() function escapes special characters in a

string for use in an SQL statement. This function will return the same string with all SQL Injection

attempts safely escaped. Apart from escaping the user input, some data, for example passwords, is

hashed using MD5. Such data is stored in the database hashed using this hash function. The result of

invoking this function is a 32-character hexadecimal number. MD5 is a one way hash algorithm

which makes is suitable for storing passwords so as to mitigate the possibility of reading these

passwords in clear text from a database.

3.2.5 System Emails

PEAR or PHP Extension and Application Repository is a framework and distribution system for

reusable PHP components. The functionality for sending system emails from a particular form was

implemented using one of the packages offered by PEAR, called Mail. The Mail package provides the

necessary features for creating and working with electronic mails. As to provide reusability a

wrapper class was created named SMTPMail, around this package as to implement the necessary

functionality to send email. The SMTPMail object implements one function as to send an email

send($from, $to, $subject, $message, $isHTML). This object is instantiated by specifying the host

address, the port for the email service, username and password to authenticate the user used to

send an email. When the function “send” is invoked the From and To email address are specified,

along with the subject and message body. To create a new instance of the PEAR mailer the

Mail::factory() factory class is used. The factory class accepts two parameters $backend and

$params. $backend is used to specify the name of the backend, in our case “smtp”. The $params

parameter is used to pass the following parameters:

$params["host"] - The server to connect. Default is localhost.

$params["port"] - The port to connect. Default is 25.


$params["auth"] - Whether or not to use SMTP authentication.

$params["username"] - The username to use for SMTP authentication.

$params["password"] - The password to use for SMTP authentication.

$params["debug"] - Whether to enable SMTP debug mode or not. Default is False.

The Mail_Mime packaged was also used as to provide MIME messages and be able to send an email

having HTML content. Two methods were used to switch from normal text to HTML, setTXTBody()

which is used to set the email body as normal text and setHTMLBody to set the email body to HTML.

This functionality is mainly used in the Forgot Password form so as to send a new generated

password to the user.

3.2.6 AJAX Technologies Used

Ajax (asynchronous JavaScript and XML) is a web development technique used on the client-side to

create interactive web applications. Using Ajax a Web application can retrieve data from the server

asynchronously in the background without interfering with the display and behaviour of the existing

page.

Ajax was mainly used in the Lunch Order System, mainly in two places, in the updating of the “My

Order” section and in the uploading of files or images. In the former when a user adds a new menu

item an Ajax call will be used to retrieve the updated list of orders from database. To send a request,

the open() and send() methods of the XMLHttpRequest object are used as follows:

objSendXMLHttpRequest.open("GET", '/my-account/user-order-listener.php, true);

objSendXMLHttpRequest.onreadystatechange = getUserOrdersHandler;

objSendXMLHttpRequest.send(null);

The first line specifies the type of request, the URL and if the request should be handled

asynchronously. When the third parameter is set to true, the request will be handled

asynchronously. The onreadystatechange stores the function that will handle the response when the

readyState property changes. The third line sends the request to the server.

When the request is sent to the user-order-listener.php page, the PHP script will build an XML

response of the list of orders. The response of the page is an XML response listing all the orders for

that particular user.

When the readyState property of the XMLHttpRequest object is changed the getUserOrdersHandler

function is called. If the readyState property is equal to 4, that is the request finished and response is

ready, the response is read from the responseXML property of the XMLHttpRequest object. The XML

response is read and the list of ordered items is rendered in the My Orders section.

A better approach using Ajax technologies was used for the uploading of files or images (Lunch

Order Manager and Menu Manager) using jQuery AJAX Upload plugin (http://valums.com/ajax-


upload). The advantages of using this approach are that there is no need to refresh the page and has

the advantage to be able to style any input element used for the file upload. Using jQuery Ajax

Upload, the loaded file is posted to a PHP form, in which the file is read from the Post and save to

hard disk.

3.3 Database Schema

In this section I will explain the information that the database will store.

3-3 Entity Relationship Diagram for the Lunch Order System

Note: for clarity a high resolution image will be supplied along with this document.


3.3.1 LunchOrder

Database: MySql

Detail: Created on 27/01/2010. Last modified on 27/01/2010.

Notes: This table will be used to store the list of user orders for the day.

Columns PK Name Type Not Null Unique Len Notes

True LunchOrderID INTEGER True True Uniquely identified a lunch order

False Reference VARCHA

R

True True 50 A user friendly reference to be used to

identify an order

False UserID INTEGER True False Foreign key to user. This user will be

responsible to call the lunch provider

False LunchProviderID INTEGER True False Each user order is identified by it's lunch

provider

False LunchOrderStatusID SMALLIN

T

False False Provides the current status for the lunch

order

False DeliveryRequest BIT True False This field will indicate if the user has

requested the order to be delivered or

pickup the order from the lunch provider

False OrderDate DATE False False This field represents the date when the

order was submitted

Constraints Name Columns

FK_LunchOrder_LunchOrderStatus LunchOrderStatusID

PK_LunchOrder LunchOrderID

UQ_LunchOrder_LunchOrderID LunchOrderID

UQ_LunchOrder_Reference Reference

FK_LunchOrder_LunchProvider LunchProviderID

Relationships Columns Association Notes

(LunchOrderStatusID =

LunchOrderStatusID)

0..* LunchOrder.FK_LunchOrder_LunchOrderStatus

1 LunchOrderStatus.PK_UserOrderStatus

(LunchProviderID =

LunchProviderID)

0..* LunchOrder.FK_LunchOrder_LunchProvider

1 LunchProvider.PK_LunchProvider

(LunchOrderID =

LunchOrderID)

0..* UserOrder.FK_UserOrder_LunchOrder

1 LunchOrder.PK_LunchOrder


3.3.2 LunchOrderStatus

Database: MySql


Notes: This table will be used to identify the status for a particular user order, e.g. Confirmed,

Cancelled Paid, Delivered, Open, Closed etc


True LunchOrderStatusID SMALLINT True True Uniquely identifies a status

False Name VARCHAR True False 150 Name of status

False Description VARCHAR False False 255 Description for status

False Active BIT True False Activates/Deactivates a status


PK_UserOrderStatus LunchOrderStatusID

UQ_LunchOrderStatus_LunchOrderStatusID LunchOrderStatusID

Relationships Columns Association

(LunchOrderStatusID =

LunchOrderStatusID)

0..* LunchOrder.FK_LunchOrder_LunchOrderStatus

1 LunchOrderStatus.PK_UserOrderStatus

3.3.3 LunchProvider

Database: MySql


Notes: This table represents to lunch providers, that is, the suppliers from where the food will be

purchased


True LunchProviderID INTEGER True True Uniquely identifies a lunch provider

False Name VARCHAR True False 150 Name of lunch provider

False Email VARCHAR False False 150 Lunch provider email

False Address VARCHAR False False 255 Address details of lunch provider

False Locality VARCHAR False False 150 Locality of lunch provider

False PostCode VARCHAR False False 20 Post Code of lunch provider

False PhoneNo1 VARCHAR True False 20 Phone Number

False PhoneNo2 VARCHAR False False 20 Phone Number (Optional)

False FaxNo VARCHAR False False 20 Fax Number (Optional)

False ContactPerson VARCHAR True False 255 Conatct Person for lunch provider

False Description TEXT False False Description for lunch provider

False MinOrderPrice INTEGER True False This field is used to store the minimum


order price for a provider in case of

delivery

False DeliveryCharge DECIMAL True False Delivery charges only apply if the

minimum order price was not

exceeded

False OrderTakeTime CHAR True False 5

False ImagePath VARCHAR False False 255 This is the image to be displyed in the

provider information page

False WebURL VARCHAR False False 150 Address to provider Website

False Featured BIT True False This field is used to identify featured

lunch providers on main page for

advertising purposes

False Active BIT True False Activates/Deactivates Lunch provider


PK_LunchProvider LunchProviderID

UQ_LunchProvider_LunchProviderID LunchProviderID


(LunchProviderID = LunchProviderID) 0..* LunchOrder.FK_LunchOrder_LunchProvider


(LunchProviderID = LunchProviderID) 0..* MenuItem.FK_MenuItem_LunchProvider


3.3.4 MenuItem

Database: MySql


Notes:

Columns PK Name Type Not Null Unique Len Prec Scale Notes

True MenuItemID INTEGER True True Uniquely identifies a

menu item

False LunchProviderID INTEGER False False Foreign key to lunch

provider. This will

identify which menu

items are handled by a

particular supplier.

False CategoryID INTEGER True False Defines to which

category a menu item is

bound

False Name VARCHA

R

True False 150 Name of menu item

False Description TEXT True False Description for menu

item


False Price DECIMAL True False 10 2 Price for menu item

False DefaultAvailability INTEGER True False This is the maximum

available items for the

day that a lunch provider

can supply. Setting this

to 0 will specify that the

menu item has unlimited

availability.

False ImagePath VARCHA

R

False False 255 This is the image to be

displyed in the menu

information page

False Featured BIT True False This field is used to

identify featured menu

items on main page for

advertising purposes

False Active BIT True False Activates/Deactivates a

menu item


PK_MenuItem MenuItemID

UQ_MenuItem_MenuItemID MenuItemID

FK_MenuItem_LunchProvider LunchProviderID

FK_MenuItem_MenuItemCategory CategoryID


(MenuItemID = MenuItemID) 0..* UserOrder.FK_UserOrder_MenuItem

1 MenuItem.PK_MenuItem

(LunchProviderID =

LunchProviderID)

0..* MenuItem.FK_MenuItem_LunchProvider


(CategoryID = CategoryID) 0..* MenuItem.FK_MenuItem_MenuItemCategory

1 MenuItemCategory.PK_MenuItemCategory

3.3.5 MenuItemCategory

Database: MySql


Notes: This table will be used to classify menu items e.g. Salads, Sandwiches, Pizza, Pasta, Healty

Options, Desserts, beverages, etc


True CategoryID INTEGER True True Uniquely identifies a category

False Name VARCHAR True False 150 Name of category

False Description VARCHAR False False 255 Description for category

False Active BIT True False Activates/Deactivates a category



PK_MenuItemCategory CategoryID

UQ_MenuItemCategory_CategoryID CategoryID


(CategoryID = CategoryID) 0..* MenuItem.FK_MenuItem_MenuItemCategory

1 MenuItemCategory.PK_MenuItemCategory

3.3.6 Module

Database: MySql


Notes: The Modules table holds the system modules information to be used to identify the various

functions of the particular module


True ModuleID INTEGER True True Uniquely identifies a Module

False ParentModuleID INTEGER False False Foreign link to the parent module

False Name VARCHA

R

True False 50 Module name

False Description VARCHA

R

False False 150 Module Description

False Active BIT True False Enables/disables a module in the

system


PK_Module ModuleID

UQ_Module_ModuleID ModuleID

FK_Module_Module ParentModuleID


(ParentModuleID = ModuleID) 0..* Module.FK_Module_Module

1 Module.PK_Module

(ModuleID = ModuleID) 0..* Permission.FK_Permission_Module

1 Module.PK_Module

3.3.7 Permission

Database: MySql



Notes: This is the list of permissions bound to a particular module available in the system.


True PermissionID INTEGER True True Uniquely identifies a permission item

False Reference VARCHA

R

True True 40 Represents a unique reference used

by the application

False Name VARCHA

R

True False 50 Name of permission

False ModuleID INTEGER True False Foreign key to module

False Active BIT True False Enables/Disables a permission item


PK_Permission PermissionID

UQ_Permission_PermissionID PermissionID

UQ_Permission_Reference Reference

FK_Permission_Module ModuleID


(PermissionID = PermissionID) 0..* RolePermission.FK_RolePermission_Permission

1 Permission.PK_Permission

(ModuleID = ModuleID) 0..* Permission.FK_Permission_Module

1 Module.PK_Module

3.3.8 Role

Database: MySql


Notes: The role table holds the list of roles for the application. It defines the permissions for user of

the system and comprises a set of permissions a user has in relation to a module.


True RoleID INTEGER True True Uniquely identifies a role in the

system

False Name VARCHAR True False 50 Represents the name for the role

False Description VARCHAR False False 255 Role description

False Active BIT True False Enables/Disables a role (logical

delete)


PK_Role RoleID

UQ_Role_RoleID RoleID



(RoleID = RoleID) 0..* UserRole.FK_UserRole_Role

1 Role.PK_Role

(RoleID = RoleID) 0..* RolePermission.FK_RolePermission_Role

1 Role.PK_Role

3.3.9 RolePermission

Database: MySql


Notes: The Role Permission table holds the relationship that that a role has in relation to

permissions.

Columns PK Name Type Not Null Unique Notes

True RoleID INTEGER True False Foreign Key to role

True PermissionID INTEGER True False Foreign Key to permission item

False Active BIT True False Activates/Deactivates a permission item


PK_RolePermission RoleID

PermissionID

FK_RolePermission_Permission PermissionID

FK_RolePermission_Role RoleID


(PermissionID = PermissionID) 0..* RolePermission.FK_RolePermission_Permission

1 Permission.PK_Permission

(RoleID = RoleID) 0..* RolePermission.FK_RolePermission_Role

1 Role.PK_Role


3.3.10 User

Database: MySql


Notes: This table will be used to store all users accessing the system


True UserID INTEGER True True User ID uniquely identifies a user of

the system

False Name VARCHAR True False 150 First Name of user

False Surname VARCHAR True False 150 Surname of user

False Username VARCHAR True True 100 Username which uniquely identfies a

user logging into the system

False Password VARCHAR True False 20 Password used to access the system

False Email VARCHAR True True 255 Email to be used for forgot password

functionality and notifications

False Telephone NUMERIC False False Telephone number for user

False Mobile NUMERIC False False Mobile number for user

False Avatar BLOB False False A picature uploaded by the user used

for profile

False EnableAvatar BIT True False User can decide to hide avatar.

Setting field to false avatar picture

will not show.

False Active BIT True False

False DefaultRoleID INTEGER False False Specifies what is the default role in

the application e.g. Administrator,

Manager, Normal User, etc


UQ_User_UserID UserID

UQ_User_Username Username

PK_User UserID

UQ_User_Email Email


(UserID = UserID) 0..* UserOrder.FK_UserOrder_User

1 User.PK_User

(UserID = UserID) 0..* UserRole.FK_UserRole_User

1 User.PK_User


3.3.11 UserOrder

Database: MySql


Notes: This table will be used to store user orders.


True UserOrderID INTEGER True True Uniquely identifies a user order id

False Reference VARCHAR True True 50 Order reference known by the user

submitting an order.

False UserID INTEGER True False

False MenuItemID INTEGER True False Foreign key to menu item selected by

the user.

False LunchOrderID INTEGER True False Foreign key to lunch order

False Quantity SMALLINT True False Quantity of menu item requested by

the user

False Comments TEXT False False These are comments submitted by

users when ordering an item/s

False UserOrderStatusID SMALLINT True False Used to identify the status for the

user order

False OrderDate DATETIME True False Date when order was submitted


FK_UserOrder_LunchOrder LunchOrderID

FK_UserOrder_UserOrderStatus UserOrderStatusID

FK_UserOrder_User UserID

PK_UserOrder UserOrderID

UQ_UserOrder_Reference Reference

UQ_UserOrder_UserOrderID UserOrderID

FK_UserOrder_MenuItem MenuItemID


(UserOrderStatusID =

UserOrderStatusID)

0..* UserOrder.FK_UserOrder_UserOrderStatus

1 UserOrderStatus.PK_UserOrderStatus

(LunchOrderID =

LunchOrderID)

0..* UserOrder.FK_UserOrder_LunchOrder

1 LunchOrder.PK_LunchOrder

(UserID = UserID) 0..* UserOrder.FK_UserOrder_User

1 User.PK_User

(MenuItemID = MenuItemID) 0..* UserOrder.FK_UserOrder_MenuItem

1 MenuItem.PK_MenuItem


3.3.12 UserOrderStatus

Database: MySql


Notes: This table will be used to identify the status for a particular user order, e.g. Confirmed,

Cancelled Paid, etc


True UserOrderStatusID SMALLINT True True Uniquely identifies a status

False Name VARCHAR True False 150 Name of status

False Description VARCHAR False False 255 Description for status

False Active BIT True False Activates/Deactivates a status


PK_UserOrderStatus UserOrderStatusID

UQ_UserOrderStatus_UserOrderStatusID UserOrderStatusID


(UserOrderStatusID =

UserOrderStatusID)

0..* UserOrder.FK_UserOrder_UserOrderStatus

1 UserOrderStatus.PK_UserOrderStatus

3.3.13 UserRole

Database: MySql


Notes: The UserRoles table represents the roles that a user has bound to his/her account.

Columns PK Name Type Not Null Unique Notes

True UserID INTEGER True True Foreign key to user

True RoleID INTEGER True True Foreign Key to Role

False Active BIT True False Enables/Disables a user role in system


PK_UserRole UserID

RoleID

UQ_UserRole UserID

RoleID

FK_UserRole_Role RoleID

FK_UserRole_User UserID



(UserID = UserID) 0..* UserRole.FK_UserRole_User

1 User.PK_User

(RoleID = RoleID) 0..* UserRole.FK_UserRole_Role

1 Role.PK_Role


4 Future Enhancements

Due to the limited time, only the core functionality was developed. Features that are to be included

in future releases are some of the main page sections. These include the Top Menu Items, Top

Providers, Suggestions, and Featured Providers. Using the “Featured” flag of both the lunch

providers database field and menu items, administrators will be able to control the listing of these

items in the main page.

Some other features that were not implemented were the use of RSS and Web Slices. Using RSS or

Web Slices users will be able to use any feed reads (or Internet Explorer 8 in case of Web Slices) to

remain updated about order statuses.

Another feature to be implemented is the Review section. This section will provide users to log in

with their account and post comments with regards to purchased menu items and provide feedback

to other users of the system.

Other features that can enhance user experience are, the use of AJAX techniques to perform server-

side validation. Without refreshing the page or disrupting the user from inputting data into the form

validation is done asynchronously through an AJAX call.

The featured Tag Cloud in the main page and some subpages will be driven from a database table or

a user manager from the administration module, from where users having administrative rights will

be able to update or add new tags.

Other features that will be implemented in future releases, the support of multiple roles. User will

be able to select from a list of roles (that are bound to their account), a low privileged account for

daily routines, such as purchasing of items and a high privileged account to perform administration

tasks.

Another important feature that will also be implemented in future releases is to provide a

notification system, that is, emails generated by the system on every action that is performed on the

frontend when ordering menu items. User will be able to receive updated statuses via email. The

same scenario is valid also for the lunch provider, that is, when an order is submitted to the lunch

provider, the system will generate an email to be sent to the selected provider.

Other features that are missing are printing of order lists and receipts. The system will be able to

print a list of orders for a particular Lunch Provider for example, a list of orders to be sent by fax.

Other features that will be nice to have are:

jQuery Autocomplete plugin – this will enable users to quickly find and select from a pre-populated list of values as they type in a text field for searching and filtering.

Further improvements to the Top Menu Items section – When user clicks on the name of the menu item a modal popup will load all the details for the menu item.

Further improvements to the Top Providers section – When user clicks on the name of the provider a modal popup will load all the details for the provider.

Frequently Asked Questions – a list of frequently asked questions as to provide help for users using the system.

Contact Us – the contact us form will be used to contact system administrators.


5 Tools Used

Tools Used

Microsoft Web Expressions – used for HTML, CSS, JavaScript editing. Enterprise Architect – used to create the database schema using UML. Firebug (Mozilla Fierfox plugin) – used to debug JavaScript issues. NuSphere PhpEd 5.9 Apache Web Server 2.2 MySQL Version 5 Toad for MySQL PHP Vesrion 5.2

HTML Pages Tested With

Internet Explorer 8 (Preferably use this browser to view HTML pages) Internet Explorer 7 Mozilla Firefox 3.5.8

Application was tested on Windows 2003 Server platform.


6 Deployment

6.1 Prerequisites

MySQL Version 5

Apache Web Server Version 2.2

PHP Version 5.2

(Tested on Windows 2003 Server)

6.2 SQL Scripts

The SQL scripts for the documentation are contained in the SQL directory.

First execute structure.sql, following data.sql

The structure.sql will create a database named db_davidvella

6.3 Source Code

The application source code is contained in htdocs. These files must be copied into the root directory

of the Apache Web Server or IIS by creating a virtual directory where the application is to be hosted.

IMPORTANT: In case of Apache files must be hosted under the root directory. All paths in the

server side includes are relative to the root directory (usually htdocs).

To change any configuration for the application, open config.ini configuration file located in the root

directory. The following attributes are to be amended as required.

Section Attribute Description

[Database] SERVER Name of server where database is hosted (default: localhost)

DATABASE Name of database (default: db_davidvella) USERNAME Username used to access the database (default: ruth)

PASSWORD Password used to access the database (default: ruth)

[System] pear_path Path to pear library. It is important that this path points to the pear library located in the project – This must not be changed for normal operation

app_code_path This is the path of the domain object PHP classes. By default this is includes/app_code, relative to the root directory. Again this should not be changed

filebank This is the path where the uploaded files are to be stored

virtualfilebank This is the virtual path of the uploaded path

[Application] defaultroleid This is the default role assigned to a user when registering the first time.


[Mail] host SMTP Host address

port SMTP Port address

username User name for SMTP host

password Password for SMTP host

IMPORTANT: Use the PEAR library that comes with the source code. The path in the configuration

path must be left unchanged.

To view a demo of the site, go to http://www.davidvella.info

The source code along with the documentation can be downloaded from

http://www.davidvella.info/lunch_order_system.zip

Test Accounts to be used:

Username: velld001

Password: velld100

Username: velld002

Password: velld100


7 References

7.1 Sites Used

Tag Cloud: http://www.artviper.net/xml-flash-tag-cloud.php

Validation Plugin: http://docs.jquery.com/Plugins/Validation

jQuery Password Strength Meter: http://phiras.wordpress.com/2009/07/29/password-strength-

meter-v-2

Datepicker, Tabs jQuery UI: http://jqueryui.com

Animatedcollapse: http://www.dynamicdrive.com

DOMWindow: http://swip.codylindley.com/DOMWindowDemo.html

Accordion: http://bassistance.de/jquery-plugins/jquery-plugin-accordion

jQuery Format: http://docs.jquery.com

jQuery Maskedinput: http://docs.jquery.com

jQuery Pagination: http://plugins.jquery.com/project/pagination

Tablesorter: http://tablesorter.com/docs

jQuery Tooltip: http://bassistance.de/jquery-plugins/jquery-plugin-tooltip

jQuery Validate: http://bassistance.de/jquery-plugins/jquery-plugin-validation

jQuery: http://jquery.com

Fusioncharts Free: http://www.fusioncharts.com/free

Tinymce: http://tinymce.moxiecode.com

Date functions: http://www.mattkruse.com

PEAR Library: http://pear.php.net

PHP Manual: http://php.net/manual/en/index.php

W3schools: http://www.w3schools.com/PHP/DEfaULT.asP

W3schools: http://www.w3schools.com/ajax/default.asp

AJAX Upload: http://valums.com/ajax-upload

7.2 Books Used

Martin Fowler (2002) Patterns of Enterprise Application Architecture

m00299151 - cmt3313 - lunch order system - phase 2

Documents