School of Innovation, Design and Engineeringmdh.diva-portal.org/smash/get/diva2:643591/FULLTEXT01.pdf · Examiner: Dag Nyström, Mälardalen University ... School of Innovation, Design

Web-based address book

- Your contacts, on Your website

Course: CDT307 - Computer Science, Basic Level (15 hp)

Innovation, Design and Engineering, Mälardalen University

Student: Alexander Kassai

Supervisor: Josip Maras, Mälardalen University

Examiner: Dag Nyström, Mälardalen University

Date: 2013-07-01

School of Innovation, Design and Engineering

Alexander Kassai Web-based address book Page i

Mälardalen University Course CDT307 2013-07-01

Abstract

Many webmail service companies provide contact management applications as part of their offering.

Thanks to that the contact management software is run inside a web browser and is hosted by the

webmail provider, users can easily access it from anywhere and without needing to install dedicated

software. The disadvantage is that the users are dependent on and tied to the service’s availability,

integrity and subscription costs.

There are several contact management applications that can be locally installed on the users’ com-

puters. By using them, the users gain control of the data and the application’s availability. However,

these applications lack fundamental features that web services offer; such as easy access from any

internet connected computer, non-existing installations and seamless rollout of software updates.

No obvious customizable address book solution exists for those users that neither trust a third

party’s integrity nor accept desktop applications’ shortcomings.

Therefore, by combining the positive aspects of contact management services offered by web

companies with the advantages of locally installed address book applications, an open source web-

based contact management application has been developed.

Without compromising in user experience, this web-based address book targets users that need to

have full control over their data and application and that also may be interested in tailoring and

modifying the software to suit their own needs.

Många företag som säljer webbmaillösningar, tillhandahåller adressböcker som en del av tjänsten.

Tack vare att dessa adressböcker körs i användarnas webbläsare, och finns på webmailleverantör-

ernas servrar, kan de enkelt nås från internetuppkopplade datorer som ej behöver ha särskild

mjukvara installerad. Nackdelen med lösningen är att användarna blir beroende av tjänstens

tillgänglighet, tillförlitlighet och de avgifter som leverantören debiterar.

Det finns flera adressboksprogram som lokalt kan installeras på användarnas datorer. Genom att

använda dem fås kontroll över adressbokens tillgänglighet och dess data. Dock saknar sådana

adressböcker viktig funktionalitet som webbmaillösningarna erbjuder. Exempel på funktionalitet som

saknas, är att enkelt kunna nå adressboken genom en valfri internetuppkopplad dator, att inte

behöva installera mjukvara lokalt på datorn och att kunna rulla ut mjukvaruupdateringar utan att

involvera användarna.

Det finns ingen självklar konfigurerbar adressbokslösning för företag och personer som varken litar

på tredjepartsleverantörers integritet eller accepterar nackdelarna med lokalt installerade program.

För att kombinera de positiva faktorerna från webbföretagens lösningar med fördelarna hos lokalt

installerade adressböcker, har en öppen källkodslicenserad webb-baserad adressbok utvecklats.

Utan att kompromissa med användarupplevelsen, riktar sig den webb-baserade adressboken till

användare som behöver ha full kontroll över sin data och applikation och som även kan vara i behov

av att modifiera och skräddarsy programmet.

Alexander Kassai Web-based address book Page ii


Table of Content

1 INTRODUCTION ....................................................................................................................................... 1

1.1 BACKGROUND ............................................................................................................................................ 1

1.2 GOAL ....................................................................................................................................................... 1

1.3 METHOD .................................................................................................................................................. 2

2 ANALYSIS ................................................................................................................................................. 3

2.1 REQUIREMENTS AND DELIMITATIONS .............................................................................................................. 3

2.2 WEB-BASED APPROACH ............................................................................................................................... 4

3 BACKGROUND ......................................................................................................................................... 6

3.1 WEB APPLICATION GENERAL OVERVIEW .......................................................................................................... 6

3.2 HOW FRONT AND BACK END ARE CONNECTED ................................................................................................... 6

3.3 FRONT END (CLIENT) SIDE ............................................................................................................................. 7

3.3.1 Available and used components ........................................................................................................ 8

3.3.2 Component details and roles ............................................................................................................. 8

3.4 BACK END (SERVER) SIDE ............................................................................................................................ 10

3.4.1 Web server alternatives and choice ................................................................................................ 11

3.4.2 Programming language alternatives and choice ............................................................................ 11

3.4.3 Database alternatives and choice ................................................................................................... 12

3.5 FRONT AND BACK END COMMUNICATION TECHNIQUES ..................................................................................... 12

3.6 SUMMARY OF TECHNOLOGIES USED IN THE APPLICATION .................................................................................. 13

3.6.1 Notes for the application’s back end ............................................................................................... 13

3.6.2 Notes for the application’s front end .............................................................................................. 13

4 APPLICATION DESIGN ............................................................................................................................ 15

4.1 APPLICATION CONTENT AND FUNCTIONALITY – SITE MAP AND USE CASES ............................................................. 15

4.2 LOGIN PAGE DESCRIPTION AND FUNCTIONALITY .............................................................................................. 17

4.3 SIGN UP FORM DESCRIPTION AND FUNCTIONALITY ........................................................................................... 19

4.4 CONTACT LIST PAGE DESCRIPTION AND FUNCTIONALITY .................................................................................... 20

4.4.1 General design and functionality .................................................................................................... 21

4.4.2 Pagination support .......................................................................................................................... 22

4.4.3 Search functionality ......................................................................................................................... 22

4.4.4 Sorting ............................................................................................................................................. 22

4.4.5 Viewing and modifying a contact .................................................................................................... 23

4.4.6 Deleting a contact ........................................................................................................................... 23

4.4.7 Adding a contact ............................................................................................................................. 23

4.5 CONTACT DETAILS PAGE DESCRIPTION AND FUNCTIONALITY ............................................................................... 24

4.5.1 Viewing contact details and general functionality description ....................................................... 24

4.5.2 Adding contact details ..................................................................................................................... 27

4.5.3 Deleting contact details ................................................................................................................... 28

4.5.4 Modifying contact details ................................................................................................................ 28

4.6 DETAILED SEARCH PAGE DESCRIPTION AND FUNCTIONALITY ............................................................................... 29

4.7 ENTRY TYPES PAGE DESCRIPTION AND FUNCTIONALITY ...................................................................................... 31

4.7.1 Adding an entry type ....................................................................................................................... 33

4.7.2 Deleting an entry type ..................................................................................................................... 33

Alexander Kassai Web-based address book Page iii


4.7.3 Modifying an entry type .................................................................................................................. 33

4.8 LOGOUT FUNCTIONALITY ............................................................................................................................ 34

5 APPLICATION ARCHITECTURE ................................................................................................................ 35

5.1 HOW THE APPLICATION CODE WORKS ........................................................................................................... 35

5.1.1 Back end (server side) activities ...................................................................................................... 37

5.1.2 Front end (client side) activities ....................................................................................................... 38

5.2 BACK AND FRONT END COMMUNICATION ...................................................................................................... 39

5.2.1 Introduction ..................................................................................................................................... 39

5.2.2 Communication between the contact list and contact details page ............................................... 40

5.2.3 Dynamic page modifications using AJAX ......................................................................................... 41

5.3 DATABASE STRUCTURE ............................................................................................................................... 44

6 RESULTS ................................................................................................................................................. 46

6.1 SETTING UP AND RUNNING THE APPLICATION ................................................................................................. 46

6.2 REQUIREMENTS FULFILLMENT, RESULT ANALYSIS AND CHALLENGES ..................................................................... 46

6.3 SUGGESTED FUTURE IMPROVEMENTS............................................................................................................ 47

7 SUMMARY AND CONCLUSIONS ............................................................................................................. 48

8 REFERENCES ........................................................................................................................................... 49

APPENDIX A – PHP FILES ................................................................................................................................... I

APPENDIX B – CSS FILES .................................................................................................................................. IV

APPENDIX C – JAVASCRIPT FILES ...................................................................................................................... V

APPENDIX D – PHP CLASSES ........................................................................................................................... VII

APPENDIX E – DATABASE SCHEMA .................................................................................................................. XI

APPENDIX F – DATABASE SETUP SCRIPTS ....................................................................................................... XII

APPENDIX G –INSTALLATION INSTRUCTIONS ............................................................................................... XVII

Alexander Kassai Web-based address book Page 1 (50)


1 Introduction This chapter describes the project’s background and purpose as well as the method used to realize it.

1.1 Background

Many webmail services, such as Gmail and Hotmail, host contact books as a part of their services.

These contact books are however often limited in functionality and tied to the rest of the webmail

service. Users also have to rely on a third party (the webmail service and its provider) to care for the

stored information’s integrity and availability.

Users looking for a more advanced and customizable contact management software can instead use

one of the popular offline, Personal Information Management suits available, such as Outlook,

Evolution and Kontact.1 These applications are not dedicated to contact management, but instead

offer it as a part of their extensive range of features. As Personal Information Management suits

typically need client side installations, the users are dependent on their own computers’ availability

and locally installed software in order to access their contacts.

The background to this project is the lack of obvious applications that combine these three criteria:

• to offer contact management as primary application feature,

• to give users the possibility of not having to share data with a third party (but instead allow

them to host the application themselves) and

• to be easily accessible from any internet connected computer.

1.2 Goal

The goal is to create an open source contact management application that anyone can setup on their

own server and then let users access and manipulate their own contacts without involving third party

services. It would be the same approach as the Gallery32 project offers for photos. Following

Gallery3’s motto, a suitable description for this project is “Your contacts on Your website”.

Main advantages with this setup are that:

• no applications need to be installed locally on users’ computers,

• changes in the software can be deployed without user involvement,

• users can easily access data from anywhere (not limited to local computer),

• the application is operational system and device independent and

• the open source setup lets the users customize and optimize it according to their own needs.

With this application, users get to host the data on their own storage media, on their own servers

and on their own network. In this way they can choose who should access the data, how safely the

data is stored, what uptime they will have and whether the application should be publicly available

on the internet or on an intranet only.

1 Websiteshttp://userbase.kde.org/KAddressBook_4.4: office.microsoft.com/outlook/,

projects.gnome.org/evolution/, userbase.kde.org/Kontact 2 Project website: galleryproject.org/gallery_3_begins



Some security and integrity minded corporations don’t consider it to be an alternative to rely on

third party cloud based applications for storing and being responsible for sensitive information. It is

impossible for such companies to know exactly how the third party’s service is protected against

attacks, how the data is backed up, whether the addresses are being sold or shared with other third

parties and what risks they thereby are exposed to.

It has been revealed that many large enterprises that offer web-based applications share their

customers’ information with others without notifying the concerned customers when it happens.

When the scope of this was revealed to the public in June 2013 it highlighted what risks companies

take when trusting third parties to be in charge of their sensitive data. [1]

Security and integrity minded corporations’ IT functions therefore need to weigh their security and

data availability needs against their users’ requirement to have a service that is web-based and has

the attributes described earlier in this chapter.

For such corporations, a web-based contact management application is a good option, as it provides

the same type of functionality as the third party web applications but is run on the organizations

own, trusted, servers and without ever needing to reveal the sensitive company data to anyone

outside of the organization.

Without compromising the needs and requirements from a security and data protection perspective,

the company can offer its users a contact management alternative that matches third party offerings.

As the contact management application is open source code, a security aware company can easily

ensure that it does what it is advertised. The open source approach also makes it possible to adjust

and customize it to own needs.

With a contact management application locally installed on the company’s web server, the users can

be offered the convenience and features of a modern web-based interface without needing to

sacrifice the control of the information, its integrity or availability.

1.3 Method

The approach when building the application is to use common programming languages and take

advantage of prewritten libraries for the user interface.

The project is being realized by using PHP, MySQL, JavaScript and JavaScript related plugins and

libraries. Plugins and libraries are mainly jQuery, Jeditable, Datatables and Datatables Editable.

MySQL and PHP are used to store data on a central database server and to implement business side

logic. The PHP code also generates the client-side of the application, which hosts interactive and

dynamic web pages.



2 Analysis This chapter covers the requirements that the application has to realize in order to fulfill the goals

described in the introduction chapter.

The 2.1 Requirements and delimitations section outlines the analysis done regarding needed

requirements from a user perspective.

In the 2.2 Web-based approach section, arguments and analysis for using a web-based solution are

presented.

2.1 Requirements and delimitations

This section describes the needs to be fulfilled within the project scope. It covers the conditions and

specifications from a use perspective. The defined requirements thereby delimit the project’s scope.

The following conditions are, from a user perspective, to be fulfilled and considered for the

application:

• Allow easy installation and update.

• The application must be open source.

• The application and the user’s contact database should be accessible from any device with a

standard web browser, as long as the web server is reachable from the device.

• The application should support most of the world’s writing systems.

• To use the application, users should not need to install any additional software (apart from a

standard web browser) on their computers, meaning that the contact database should be

accessible from any computer or web browser equipped device (only depending on the

browser support).

• Users should be able to view, create, update and delete contacts in the application.

• There should be five categories of contact details. Within each category, the user should be

able to create as many entries and entry types as wished. The five categories:

o Birthday (limited to one entry and no possibility to specify different entry types),

o Names ,

o Addresses,

o Phone numbers,

o Email and instant messaging addresses.

Users should be able to customize a wide range of contact attributes. As an example for the

names category, the users should be able to define name types (surname, nickname, middle

name, maiden name etc) according to their own wishes and add as many names connected

to these name types as desired.



• The application should have a user authentication functionality with login/logout features.

Basic password handling should be included.

• Multiple user accounts must be supported, each with their own individual contact database.

• New users should be able to sign up and create an account without needing to contact the

administrator.

• Contact listing should support pagination. Additionally the user should be able to decide how

many contacts to show per page. The user should be able to disable the pagination and list

all entries on one page.

• The listed contacts should easily be sortable by different columns (such as last name or

telephone number). The sorting should also be able to be done with multiple columns and in

both ascending and descending order.

• A search function should be implemented, in order to be able to do real-time filtering of

presented data. The filtering should support a search criterion consisting of one word.

Support for multiple words is a bonus, but not a requirement.

• A detailed search functionality, which searches all existing contact details data in the

database (for the particular user) should be implemented.

• When clicking on a contact’s valid email address in the contact’s profile, the user should be

redirected to the default email client and have the email address prefilled (using the

“mailto:” [2] scheme).

• The application is to support handling a contact list with maximum 1000 contacts.

2.2 Web-based approach

As can be seen from the user requirements in the previous section the application has to, among all,

enable easy installation and update, allow access from multiple locations and store data in a central

location. Two viable options to achieve this are either by using standard desktop programs and web

based applications.

The advantages of desktop applications are that they provide good user experience in terms of

functionality and integration with the operating system. Disadvantages are that user intervention is

needed to upgrade and install the application on the client device, that it is dependent of which

operating system is being used and that it isn’t natively and easily accessible from a remote location.

A web-based approach makes it possible to upgrade and deploy new versions of the application

without needing to make changes on the user’s computer system and without the user’s

intervention. It allows the user to access the application from any computer without prior installation

of local software. The user’s data will also always be at hand and the user never has to keep track of



where it is stored or how to access it. These are major advantages over a desktop application, which

often requires the user to first install the application and the data file (which in this scenario holds

the contact data) onto the computer and then point the application to the data file.

Furthermore a web-based solution is aligned with the requirement that the application should be

operating system and device type independent. For a desktop application, it would be necessary to

create several versions of the application in order to support different operating systems.

With a web application the user interface can be made highly interactive and, despite being run

through a web browser, behave as a locally installed desktop program.

The only relevant limitation with the web-based approach is that the user’s computer needs to have

a network connection with the server where the application is located.

In summary, web applications provide the following advantages over desktop software:

• provide the user convenience of using a web browser as a client,

• offer the system administrators the ability to update and maintain web applications without

distributing and installing software on potentially thousands of client computers,

• are independent of which operating system the clients are using as long as the clients have a

modern web browser,

• natively supports remote access and

• support multiple user account.

Given the above arguments and that all requirements in section 2.1 are met, the contact

management software is built using a web-based approach.

This means that a web server will host the application which, just like any other web page, is

accessed and loaded into the user’s web browser. The database used by the application (to store the

contacts) is also located centrally on a server.



3 Background This chapter describes what a web application is and how its different parts and components work.

The components and programming languages used in the project are described, as well as the basic

concepts of web development.

3.1 Web application general overview

This section provides a brief overview of how web applications work. More detailed descriptions of

the different components and languages are outlined in the following sections.

On the user’s computer, the application is run inside a web browser and accessible just as any web

page on internet. A typical scenario is that the user enters information into the web browser, which

in turn, from a web server, requests the related web page. The web server receives the request from

the browser, analyses it and then generates a web page that is sent off and displayed to the client.

Figure 1: Communication flow between client and server

The programs that are hosted, interpreted and run by the user’s browser are called client side code

or the application’s front end.

Programs residing on the web server and ensuring that the user’s browser is provided with the

correct data is categorized as server side code or the application back end. Within the responsibility

of the back end function is also to handle the communication with other server side systems, such as

the database, which in this project stores the contact data.

Figure 1 illustrates how the front end relates to the backend as well as how the information

communication is setup between them.

3.2 How front and back end are connected

In order to create a good user experience and be able to run the application in a web browser,

several scripting/programming languages are used, together with a web server and a database.



Figure 2 shows an overview of the different components and technologies on both the front (client

side) and back ends (server side).

Figure 2: Components in front and back end

The following happens when a user is using a web application and needs to make something that

triggers interaction requiring loading or manipulating data in the application (figure 2):

1. The user navigates to a page. A request with the information about this is sent from the

web browser to the web server.

2. The web server fetches the requested web page.

3. The server side code on the web page is run and replaced by its output.

4. The final version of the generated web page is sent to the user’s browser.

5. The user’s browser includes the client side files that are referenced on the web page.

6. Client side code is executed in the browser.

3.3 Front end (client) side

This section focuses on the code that is run in the application’s client side or front end; the client’s

web browser. Descriptions of available technologies and languages are listed as well as which of

these that are used in the application. Following this, a section describes each of the used languages.



3.3.1 Available and used components

There are several alternatives to pick from when deciding on which language and framework to use

for the code run on the client side. This section outlines the most common alternatives and also

states which ones are used. The used languages are described more in detail in the coming sections.

When choosing which client side scripting language to use, the three major options are Adobe Flash,

Microsoft Silverlight or JavaScript.

Flash and Silverlight are run on top of the browser; the browser needs to have a Flash player or

Silverlight plugin installed to execute the code. The advantage of Flash and Silverlight is that they will,

thanks to being run through plugins installed on the web browser and developed by Adobe and

Microsoft, always behave the same – no matter which browser is being used.

Downside of Flash and Silverlight is the dependency on the browser plugin, which may require

application installation by the user. Additionally both Flash and Silverlight have limitations on which

operating systems they support. They also use proprietary formats that are owned and developed by

Adobe and Microsoft.

The HTML, CSS and JavaScript are a combination of technologies that natively, without additional

plugins, is supported by common and modern web browsers. Due to this, they are independent of

both which operating system is being used as well as which device it is being run on.

Usage of the HTML + CSS + JavaScript combination is well-documented, open source, widely

supported by web browsers and also well-documented. This is in contrast to Adobe Flash and

Microsoft Silverlight, that aren’t open source, use proprietary and file formats, require additional

plugin installations in the browsers and don’t support all operating systems.

With the above arguments, the HTML + CSS + JavaScript combination is used for the front end logic.

3.3.2 Component details and roles

This section describes the front end technologies, scripting languages and plugins used to create a

good user experience.

3.3.2.1 HTML and CSS

HTML is a markup language that makes it possible to define the structure and formatting of web

pages and their content. Web browsers use the HTML markup tags to build web pages’ user inter-

face. For example they let the browser know where to create tables, insert links to other web pages

and position images and paragraphs.

HTML has been released in several versions. The most recent one being adapted is HTML5, providing

new features and interactivity such as making it possible for browsers to implement multimedia

content interpretation [3], interactive graphics [3] and local storage [4]. Some of the functionality

used in the application, such as the placeholder feature, isn’t available in older HTML versions.

Cascading Style Sheet (CSS) is a language used to specify how a structured document’s (such as

HTML) elements should be presented. This includes a variety of formatting and styling settings. CSS

code is made up of CSS rules, where each rule has a CSS selector and a set of property-value pairs.

The selector determines which HTML elements that the property-value pair should be applied to.



Working with CSS files makes it possible to reuse formatting options on several HTML pages without

needing to implement and specify them each time. By placing the formatting options in a CSS, the

developer simply needs to link the particular CSS in order to apply the format to all concerned HTML

code. Using CSS also provides the convenience of that all associated HTML code gets updated when

the CSS is modified. From a developer’s perspective, using CSS also makes it easier to get an overview

of the code.

3.3.2.2 JavaScript

Apart from getting the interactivity and features provided by HTML5, the user of a web application

may need more advanced types of interactivity – for example to sort a displayed table by different

columns. Additionally the formatting on the web page might need to be more dynamic than what

HTML5 can provide; for example when hovering with the mouse over a cell in a table, maybe the

concerned row should change font size and color.

As the web server isn’t involved in such actions on the web page, this scenario is difficult to achieve

by simply using static HTML5 tags.

For this reason many web browsers, such as Google Chrome and Mozilla Firefox, are able to run

program code that dynamically changes the web page. JavaScript is an example of such a client side

scripting language, and is commonly used to create an interactive experience for the user.

With the help from JavaScript code, it’s possible to make the web browser behave like an interactive

application, where the user can change and modify content, trigger events and more seamlessly

communicate with the web server. An example of the seamless behavior is the possibility for the user

to alter information on a web page, save those changes on the server side and do this without

needing to reload the page. In order to provide a good user experience, the contact management

software heavily relies on dynamic content manipulation.

Using JavaScript and JavaScript based code in the platform has many advantages. As already

outlined, JavaScript is natively supported by many web browsers and makes it possible to easily add

plugins and libraries without needing to install additional browser extensions. This, together with the

other mentioned arguments, makes JavaScript the only obvious client side scripting language for the

contact management software.

3.3.2.3 jQuery

In order to make it easier for developers to implement JavaScript code needed for commonly used

features, different JavaScript libraries have been developed. A commonly used JavaScript library is

jQuery (used by approximately 57% of all measured websites, 2013 March 28) [5].

Compared to JavaScript, the prewritten code and functions in the jQuery library greatly facilitates

common tasks such as event handling, content selection and UI animations [6].

Not all browsers behave in exactly the same way when executing JavaScript code. jQuery abstracts

away many of the found differences and hence eliminates the need of having to write customized

JavaScript code for each web browser that is to be supported. [6]



3.3.2.4 jQuery plugins

The jQuery library enables developers to write or use already prewritten plugins to support their

coding.3 DataTables [7] and jQuery DataTables Editable [8] are examples of two such plugins that are

used. These two jQuery plugins offer support for presenting information in interactive and feature

rich tables.

The interactive part is based on the fact that the user directly can manipulate contact data inside

tables. In the background, without rendering a new page, the plugins ensure that user data is being

submitted to, and received from, the PHP server.

By implementing plugins such as DataTables and DataTables Editable, a lot of the required user

experience foundation is automatically taken care of. The DataTables plugin provides the user with

flexible and customizable opportunities to arrange, sort and filter lists and tables. No other plugin,

free of charge, was found that with so little customization could deliver a behavior matching the

application requirements.

A challenge with using these plugins is to configure them in a way that suits the other parts of the

application code and to make customizations without necessarily changing the plugins’ own code (as

it would make it difficult to upgrade and security patch the plugins).

When choosing a plugin to build the client side formatting and functionality for the contact list

tables, DataTables is the plugin that appears to be most widely spread and mature enough. It is used

by among all Amazon.com and Los Angeles Times. In addition, it is very well-documented and has an

active forum where both the plugin developer and the other users help each other out. The

configurability provided by the plugin is also a big part of the decision to use it.

The author of the DataTables plugin offers an editor making it possible to modify the shown tables.

However, as this editor isn’t free of charge the DataTables Editable project’s implementation, based

on the JEditable plugin, is used.

3.4 Back end (server) side

This section focuses on the technologies used in the application’s server side. Descriptions of

available technologies and languages are listed as well as which of these that are used for the

application.

The following components are located in the back end:

• A web server. Every time a user requests a web page, it is delivered from a web server. The

web server has three major work tasks in this aspect;

o to handle the web browser’s request,

o to fetch the requested web page and perform necessary manipulations and

interpretations of the requested web page,

o to output the manipulated web page and send it over to the web browser that it was

requested by.

3 http://plugins.jquery.com/ hosts prewritten plugins ranging from animations to advanced input forms.



• A programming language providing dynamical content to the web server delivered web

pages. The server side code is executed before the user requested web page is sent off to the

web browser. The code received by the user’s web browser therefore doesn’t contain any

server side code, only the resulted content of its execution. A browsing user will never be

aware of what the code looked like, or that it existed. The user will simply end up with a web

page that has been received from the web server.

This programming language also takes care of all requests coming from the web browser. As

the application is run through a web browser, the program initializes every time the web

page is requested and terminates as soon as the web page has been generated. This means

that all variables and run-time data is lost every time a webpage has been generated. This is

a difference from conventional (for example) C++ and C# applications, which run until the

user finishes using them.

The current state of the data and information that would reside in a conventional

application’s memory during program execution, are therefore either kept track of by

frequent read and write operations to the server side database or stored in the user’s

browser (in the web pages).

• A database that stores the information that is received from and communicated, through the

coding language and web server, to the browser. In web applications, the database is

frequently accessed, as the application terminates after each web page is loaded and no

other ways exist to keep track of variable values and data required for future use.

3.4.1 Web server alternatives and choice

There are two major, well-established, web servers to choose between; Apache and is Microsoft’s

Internet Information Server, IIS. [9]

Apache is a commonly used web server and has all necessary plugins to handle PHP and other

components used for web applications. It has a big community and by that ensures that problems

that may occur already have been thought of and solved by others. In addition it is open source, free

of charge and is available on several operating systems. Apache is run on many large corporations’

web servers around the world and is therefore a stable and mature product.

IIS is also a widely used web server that has support for PHP. The major drawbacks with IIS is that it

isn’t free of charge as the user is locked to a non-free Microsoft operating system, in contrast to

Apache that can be run on different operating systems.

With IIS being non-free, non-open source and not available for other operating systems than

Microsoft’s, Apache is chosen as web server.

3.4.2 Programming language alternatives and choice

There are currently four well-known server side languages that have been taken into consideration;

PHP, Python, Ruby and Microsoft’s ASP.NET (according to [10]).They are all scripting languages that

run on the web server and make it possible to dynamically generate web pages [11].



PHP, PHP: Hypertext Preprocessor, is an open source language that integrates very well with both

Apache and MySQL. PHP is widely used and has an extensive documentation, community support

and is easy to learn. PHP supports object-oriented programming as well as built-in functions to easily

connect to and manage MySQL databases.

Python and Ruby are, just like PHP, open source and free to use. However, they are not as widely

used as PHP.

Microsoft’s ASP.Net is also, just as PHP, widely used. It is only run on Microsoft’s own Internet

Information Services (IIS) web server, which in turn requires a non-free Microsoft operating system.

As such setups aren’t open source and also imply a cost and operating system restrictions; ASP.NET is

not relevant to take into consideration.

With the above arguments, PHP is the language of choice for the contact management application. It

supports object-oriented programming as well as built-in functions to easily connect to and manage

MySQL databases. PHP works well with Apache and has extensive online documentation.

3.4.3 Database alternatives and choice

Popular databases, such as Oracle Database, Microsoft SQL and MySQL are considered. [12]

They all offer similar support for web applications like the contact management platform. However,

only MySQL is free and open source [13]. This disqualifies the Oracle Database and Microsoft SQL as

candidates.

Among open source and multi operating system supporting databases, MySQL is by far the most

popular (in terms of usage). This combined with that PHP has comprehensive support for interaction

with MySQL database [14], makes MySQL the database of choice for the contact management

platform.

3.5 Front and back end communication techniques

There are two common traditional ways to pass information along from the client to the web server’s

script interpreter (in this case, PHP). These are the HTTP POST and HTTP GET methods [15].

The POST method makes it possible to submit variables and their corresponding values to be

processed by a web page. The variables and their values are normally passed on from a form and are

then available to the receiving web page’s script interpreter (such as PHP). The POST method is not

directly utilized in the contact list page’s code, but is used by the AJAX type of requests facilitated by

the DataTables Editable jQuery library plugin. [16]

Simplified, when a URL ends with a question mark followed by one or more variables and set values,

it indicates that the GET method has been used. The web page stated in the URL then receives the

variables and their corresponding values, and can use them in the code. Basically, the web page is

requested with the inputted variables (which the web server’s script interpreter can use in the code

preprocessing).

There are obvious advantages and disadvantages between using the POST and GET way to provide

input data to a web server’s script interpreter [17]. A GET request can, as it is a part of the URL be



bookmarked and cached; however it cannot be indefinite in length nor contain any character (limited

to ASCII). For POST, the opposite applies in these cases.

3.6 Summary of technologies used in the application

With the technology and language choices that have been made for the front- and back end, the

application will look as described in figure 3.

Figure 3: Application components

3.6.1 Notes for the application’s back end

The backend PHP code hosts most of the logic for the application, such as:

• Facilitating read and write operations towards the database.

• Outputting contact lists, contact details and other content requested by the web browser.

• Reading, interpreting, validating and taking action on user input received from the client side

(web browser).

• Applying logic, such as filtering data, that is needed to output desired information.

• Hosting the login functionality.

No prewritten libraries, except of those natively delivered by the PHP framework (such as the MySQL

connection) are used. All code and structure is therefore been written and setup from scratch.

3.6.2 Notes for the application’s front end

For the front end, CSS and JavaScript code are used. The JavaScript code:

• changes the HTML layout and content and enables data manipulation,



• adds interactivity to the web page. The page responds to user generated events such as

mouse hovers, clicks etc,

• handles AJAX-type communication with the web server, [18], [19]

• mainly consists of code using the jQuery library.

The DataTables and DataTables Editable plugins are used to setup the contact list and to make it (and

other application tables):

• sortable by clicking on the different header columns,

• have pagination support,

• filterable in “real-time” (no need to submit a search criteria; the hits show up as the search

string is being entered).

The DataTables and DataTables Editable plugins depend on, and load, additional prewritten jQuery

libraries, such as jEditable (to make it possible to dynamically edit content) and jQuery UI (to easily

apply formatting themes) [20]. JavaScript code makes it possible, for example, to replace the content

of HTML id tagged text string.

jQuery is used to customize the DataTables and DataTables Editable plugins to suit the application.

Examples are to host the add/delete buttons on the top left of the tables and to add table titles to

the table headers.

jQuery is also used to write client side interactivity features that are not related to the other

prewritten JavaScript libraries. Such code is to build the “mailto:” functionality, as well as to make it

possible to trigger certain actions when clicking on certain elements and table components.



4 Application design This chapter covers how the application, from a user perspective, is designed and perceived. The first

section below presents an application site map and outlines how the software’s different pages and

functionality. In the subsequent sections, each web page is described in detail.

4.1 Application content and functionality – site map and use cases

This section presents an application overview with a sitemap and brief explanations of the different

parts of the software.

To improve the simplicity and to decrease the risk for confusion, an aim is to display as few web

pages as possible to the user. Figure 4 below outlines the site map.

Figure 4: Site map

Before gaining access to the application and its features, the user is presented with a login page.

If the user tries to access the application and isn’t already logged in, an authentication page is

displayed. The login page has two options; either to login with existing user credentials or to create a

new account (figure 5).

Figure 5: Use case showing the initial authentication flow



A successful login attempt directs the user to the main page (figure 6). By picking the “Sign up”

option instead, the user is prompted to create an account with corresponding password. After that,

the newly signed up user is automatically logged in.

Figure 6: Use case describing the flows once the user is logged in

The illustrated options at the “Main page” are described as following:

• List contacts. This is the default page after a successful login. The page hosts a table of the

registered contacts’ most common names, address, phone number and email address. The

list actively sorts out the main entries for the fields – if a user for example has several

addresses registered, the main one is displayed. By clicking on a contact, the user is directed

to the contact details management page, please see the description below.

• The detailed search page allows the user to search among all details belonging to all

contacts. By clicking on a search hit, the user is directed to the contact details management

page, please see the description below.

• Management of a contact’s details is triggered by clicking on the particular contact in the

one of the above mentioned tables (the list contacts and detailed search pages). Through the

click, the user is directed to a new page where all contact details are revealed.

On this page the user can add, remove or edit entries (different type of names, addresses,

phone numbers and email addresses). The modification is done through dynamic requests

and avoiding unnecessary pop-ups.

Entries recognized as email addresses are clickable to trigger a “mailto:” functionality. When

the user hovers over the address, an option to follow the mailto link is provided.



• Entry type management. In order to provide necessary customization, the entry type

management page hosts the possibility to add, delete and edit types of names, addresses,

phone numbers and email and instant messaging addresses. Predefined values, needed to

exist in order to support basic information for the above described contact table, are

displayed but not editable or removable.

• The logout option logs the user out and directs him/her back to initial Login page. There is no

logout page, but the user is directly logged out and directed to the login page.

Tables and lists mentioned in the above bullets are, when applicable, equipped with support for

filters/searches and the possibility to change the number of entries displayed on every page. They

also offer sorting functionality on any single or multiple columns selected (when applicable).

For a logged in user, the application consists, in total, of four web pages and a logout option. These

pages, together with the authentication and sign form, are described in the following sections.

4.2 Login page description and functionality

The login page’s position is highlighted in red on the below site map, figure 7:

Figure 7: Login page’s position on site map

If the session cookie is unset and user isn’t logged in, a redirection is always made to the login page -

no matter which page within the application the user tries to reach (except for the signup page). The

login page prompts for a username and a password, according to figure 8 below.



Figure 8: Login page

There are three alternatives for the user:

1. Submit correct credentials and get logged in (with a session cookie created) and directed to

the contact list page.

2. Submit incorrect credentials and be asked to try again (there is no limitations on how many

times this can be done).

3. Click on the “Create a user account” link, and be directed to the signup page.

Notes about the login process and security:

• A successful login is remembered through session cookies, which are set. This means that a

user needs to logout or close the browser to unset it.

• Neither the login process nor the rest of the application is equipped with encryption or other

security measures.

• All validation of usernames and passwords are done on the server side, in a PHP file.

• The usernames and passwords are stored in a MySQL database table.

• The passwords are stored after being hashed with the sha256 algorithm. Therefore the

entered passwords need to be hashed with the same algorithm before compared with the

entries in the database.

• No salt is applied to the passwords.

• As seen in the screenshot, the HTML5 placeholder feature is used (before the form’s boxes

are filled out, the boxes themselves state what type of data is expected to be entered).



4.3 Sign up form description and functionality

The sign up form’s position is highlighted in red on the below site map, figure 9:

Figure 9: Sign up form's position on site map

When the (potential) user isn’t logged in and clicks the “Create a user account” link on the login page,

the following account registration form appears (figure 10):

Figure 10: Registration form

The user has the following alternatives:

1. Realize that he/she already has a valid user account and get back to the login page. This is

achieved by clicking the “Login with existing user” link.

2. The user signs up with a username that hasn’t been taken and has entered two identical

passwords. This will create the account and sign the user in.

3. The user has entered two non-identical passwords, provided empty password fields or left

out the username. He or she is then asked to try again.

4. The user enters an already taken username and has provided two identical passwords. An

error message appears, stating that the username already is taken. The user is asked to make

a new attempt to sign up.



Notes regarding the sign up form:

• Validation to match the passwords as well as password hashing is done on the server side.

• The usernames and passwords are stored in a MySQL database table.

• Neither usernames nor passwords are validated by their syntax and appearance.

• The passwords are stored after being hashed with the sha256 algorithm.

• No salt is applied to the passwords.

• There is no “forgotten password” feature implemented, as this has not been a set

requirement. As the application currently isn’t connected to an email server, a lost password

feature can’t easily be setup.

• There is no change password functionality.

• Every time a new account is registered, a set of standard entry types are created for the user

(among all the following name types: “last name”, “first name” and the following address

types: “residential”, “office”). This is done in order to give the new user a set foundation of

entry types to use when creating contacts. Some of the types that are setup are compulsory

as well; please see section 4.7 Entry types page description and functionality about this.

• Session cookies from logged in users are unset before creating a new user (in case a currently

logged in user has accessed the sign up page through its direct URL).

Security poses a very important role in web-based applications. However this project focuses on the

application’s main functionality; the contact management and not the authentication mechanism.

The goal is to build a multi-user platform with password authentication, which has been achieved. No

extensive efforts, apart from the above described, have been invested in adding additional levels of

protection (such as captcha, password policy enforcement and activation emails). The user

requirement states support for basic password functionality, which has been fulfilled.

4.4 Contact list page description and functionality

When a successful login has been performed, the user is directed to the contact list page, please see

figure 11 for how it maps into the site map.

Figure 11: Contact list's position on site map



The contact list page loads and displays a table with all contacts in the user’s database, please see

figure 12. That all contacts are fetched from the web server when the page is accessed has not result-

ed in an unacceptable user experience from a load time perspective. The page has successfully been

loaded with 1000 contacts (which is the user requirement) with load times less than four seconds.

4.4.1 General design and functionality

When the contact list page is loaded, the client’s web browser receives a summarized list of all

contacts stored in the database. The received and displayed list includes the contact’s last name, first

name, birth date, phone number, email address and (geographical) address.

As it is possible to add as many entries as desired of these entry types (for example, one person could

have several first names and several email addresses), the application needs to know which entry to

display.

Therefore, for every entry, there is a “preferred” setting that can be either set to “yes” or “no” in the

contact details page. If this setting is switched to “yes” and the entry type matches one of the

columns in the contact list table, it will be displayed there. These entries are shown in italics, as the

tooltip also indicates in the screenshot (figure 12).

If the contact doesn’t have a “preferred” entry for a certain contact list column, but still has an entry

that matches the column, that entry is used instead. Those entries are shown with normal for-

matting, and not italics. For more details about how the “preferred” flag works and how it

determines which data that shows up in the contact list for a certain contact, please see the “Contact

details page description and functionality” section below.

Figure 12: Contact list page



The table itself is a modified version of the DataTables’ standard view. Through jQuery and JavaScript

code, additional functionality has been added in order to fit the contact management purpose. As

examples, the user can access a particular contact’s details by clicking the contact and the “Add

contact” button has been integrated into the table.

4.4.2 Pagination support

As seen in figure 12, the displayed table also supports pagination. The user can display a certain page

by clicking on the desired page number in the bottom right corner of the table, or use the “First” or

“Last” buttons to go to the first or last page of the table.

In the top left of the table the user can, in a drop-down list, choose how many entries per page that

should be displayed. As standard, ten contacts are displayed per page. This can be changed to five

contacts per page as a minimum and “All” as a maximum (which is the same as turning off the

pagination).

In the very bottom to the left, there is a status bar guiding the user to understand what part of the

contact list that currently is displayed as well as how many contacts the user has stored in the

application.

4.4.3 Search functionality

In the top right corner of the table, there is a “Search” field. Contacts containing information that

match the search criterion are being filtered out in real-time while the criterion is entered.

The matching parts of the criterion are highlighted (with green markup color) in the displayed search

results. Highlighting is applied if the search criterion is limited to one word (as the user requirement

states). The search criterion can additionally consist of several words with the separating spaces

interpreted as a logical AND operator (however without any highlighting in the displayed output).

Figure 13 below shows an example of a filtered contact list, with the search criterion highlighted.

Figure 13: Filtered contact list

4.4.4 Sorting

The displayed table can be sorted on any of the displayed columns. By clicking on a column header,

the table is sorted in ascending order on that particular column’s content. Another click on the same

column header reverses the sort order. The arrows in the header, next to the column name, indicate

in what direction the particular column is sorted. A double arrow reveals that the column doesn’t

have an applied sorting.



It is possible to sort multiple columns at the same time. This is achieved by first clicking on the

column to sort on in first hand, and then apply additional column sorting by holding down the shift

key and clicking on the column that should be sorted in second hand. Additional columns can be

added to the sorting in the same way.

To ensure proper sorting, the order for all months has been mapped (in order not to sort them

alphabetically). Columns containing letters and numbers are correctly recognized and sorted.

4.4.5 Viewing and modifying a contact

By clicking on a contact, anywhere in the row except the “Delete” link, the user is redirected to the

particular contact’s detail page. On this page, the user can view and change the contact’s details. The

detail page content and functionality are described below in the “Contact details page description

and functionality” section.

In order to aid the visibility of which row is about to be selected, the table rows are highlighted in

yellow when the mouse pointer hovers over them (please see figure 12).

4.4.6 Deleting a contact

By clicking on the “Delete” link in the very right column, a prompt is displayed to confirm that the

deletion of the contact is intentional. If confirming the deletion, the contact and all its contact details

are removed. The contact is deleted from the list without needing to reload the web page.

4.4.7 Adding a contact

A click on the table’s “Add contact” button brings up a dialog box, please see figure 14). The fields

marked with an asterisk (“*”), are mandatory to fill out (currently the first and last name). When

possible, drop-down boxes with predefined values are used.

Figure 14: Add new contact dialog box

The available choices behind the email address type, phone number type, and street address type

dialog boxes vary depending on which entry types the user has created.

A newly created contact appears in blue color in the contact list, as seen in figure 12 (please see the

“Kungligsson” contact). Additional data to be added to the contact is done through the contact

details page (as described in the Contact details page description and functionality section below).

The new contact is seamlessly added to the list without triggering a web page reload.



4.5 Contact details page description and functionality

The contact details page makes it possible to view and edit a contact’s details. It fits into the sitemap

as displayed below in figure 15 and is accessed by selecting a contact from the lists on either the

contact list page or the detailed search ditto.

Figure 15: Contact details page's position on site map

4.5.1 Viewing contact details and general functionality description

The contact details page contains four tables where the contact’s names, (geographical) addresses,

phone numbers and email/instant messaging addresses are stored. Additionally it is possible to enter

information about the contact’s birthday. The layout is as shown in figure 16.



Figure 16: Contact details page

The tables in the contact details view have the same or more limited functionality as the contact list

page. Their functionality is therefore described in the section Contact list page description and

functionality. The limitations and differences compared to the Contact list page’s tables are:

• the pagination settings and side numbering have been removed and replaced with two

arrows in the table header (there is no need for extensive pagination)

• the status bar in the bottom is removed (to save space)

• no color highlighting for the search box

• no color highlighting for hovering over entries

In each of the four tables on the contact details page, the user can view, add and delete information.

Each table also has the following four standard fields:

• “Old”. If this field is marked as “Yes”, the related entry is no longer active. It could for ex-

ample be a last name that has been changed or an address that no longer belongs to the con-

tact. Instead of deleting the entry, the user might want to keep it for reference or a log. If the

value is set to “Yes”, the entry will never be the one show up on the Contact list web page.



• “Pref” – preferred. If this field is marked as “Yes”, it indicates that the related entry is

preferred. It could for example be an email address that the contact prefers to receive emails

to, a (geographical) address that the contact would like to get postal deliveries sent to or the

first name that the contact wants others to use.

In those cases that the entry type matches one of the columns found on the contact list

page, the preferred flag controls whether the corresponding entry is displayed on the

Contact list page or not. The priority to decide whether an entry is listed on the contact List

page is as follows:

o Only entry types that have corresponding columns on the contact list page can be

listed on the contact list page. For example an entry type of “maiden name” can

never be listed on the contact list page, as the name type isn’t listed (only “first” and

“last name” are listed). The preferred field setting will therefore not have any effect

on the contact list page if the entry type isn’t to be found there.

o For entry types that are listed on the contact list page, if there is an entry with a

“Yes” in the “preferred” field, it will be picked. For example if someone has two first

names and only one is marked as “Yes” as preferred first name, the “preferred” one

will be promoted to the contact List page.

o For entry types that are listed on the contact list page, if there are several entries

with “Yes” set in the “preferred” field, the last (most recent) of the entries that was

added to the contact’s profile will be used. If a user has two first names marked as

“preferred”, the most recently added one will be promoted to the contact list page.

o If none of the entries of an entry type that is listed on the contact list page is checked

as “preferred”, the entry that first was added to the contact will be displayed. For

example, if there are several first names for a contact, but none is marked as

“preferred”, the first one that was added will be promoted to the contact list page.

o If there are no corresponding entries for a certain entry type that is listed on the

contact list page, a dash (“-“) will instead be displayed.

The above priority relates to all entry types on the contact list page, except for the phone

number column. For the phone number column, all types of numbers from the phone

number table, except for the “Telefax” type, are accepted and prioritized as described above.

Numbers of “Telefax” type will never be promoted to the contact list page.

The mechanism that uses the “old” and “pref” settings in order to decide what is promoted

to the contact list page, shouldn’t need to be explained or understood by the user. As long as

the user, from the tooltip information for the two fields, understands what “old” and “pref”

means, he/she should get expected information promoted to the contact list page.



• “Comment”. This field is meant to be used to add additional contacts or remarks to the

current entry. It is a free text field that can be 100 characters long.

• “Type”. The type determines the entry type for the inserted name, address, phone number

or email/instant messaging address. Types that are available, and can be assigned to contact

entries, are mainly determined by the user.

The user can define and add entry types through the entry types web page. However, some

entry types are preconfigured and not removable nor changeable. These entry types are

used to be able to populate the contact list web page’s standardized columns. Such entry

types are last and first names.

In order to aid the user to easily send emails to contacts through the contact details page, as well as

to be compliant with the set requirements, there is a “mailto:” functionality implemented for the

Email & Instant Messaging table. If an entry is of type “email” and the address field content contains

an “@” sign, hovering the mouse pointer (“mouse over”) over the address field will make it go italics

and change color. In addition a double click on the address will trigger a “mailto:” action for the

particular email address, which should open up the user’s preferred email client and start a new

email prefilled with the address.

As the requirement states that the “mailto:” feature only should be triggered for “email” entry types,

the functionality will not be present when the user double clicks on, for example, a Skype username

containing an “@” sign.

4.5.2 Adding contact details

New contact detail entries are added by clicking on the add button in the concerned table’s header.

This works for all tables but the birthday (as there can only be one birthday for a contact).

New contact details are added through forms that are displayed after clicking the add button. For

example, the “Add name” button brings up the form displayed in figure 17.



Figure 17: Add new name dialog box

Settings that have predefined sets of possible values, such as the “name type” are displayed through

dropdown lists that are (when needed) dynamically are loaded from the backend system when

bringing up the form.

There are no rules limiting the user for entering duplicate information for a certain contact detail. For

example, several first names called “Foo” with identical details can coexist.

The contact detail is added to the table without needing to reload the web page.4

4.5.3 Deleting contact details

By clicking on a contact with the left mouse button, the user selects it. The selection is indicated by

highlighting the contact with a dark blue background. The selections are done on table level and only

one entry can be selected simultaneously per table. A selected entry is deselected by another left

click on it.

When an entry is selected, the concerned table’s normally grayed out delete button becomes

clickable. By clicking on the delete button and confirming the deletion in the confirmation form, the

entry is removed. As with most parts of the application, the entry removal won’t reload the web

page and hence improves the user experience.

4.5.4 Modifying contact details

All contact detail fields displayed on the contact details page are modified by right clicking on them.

Depending on which field is being right-clicked on, the user is presented with the possibility to edit

the currently existing field value or to select a new value from a dropdown menu. Upon the right click

the dropdown menu’s values are loaded and displayed.

In order to confirm the newly entered field value, the user either hits the keyboard’s “enter” key or

clicks the presented “ok” button. Cancellation is done by either hitting the “escape” key or clicking

the “cancel” button.

4 An exception is when adding a new entry to the ”Email & IM” table, as the “mailto:” handler isn’t loaded



The tables’ field values are modified without needing to reload the web page.

Please see figure 18 for an example screenshot on the contact details editing feature.

Figure 18: Edit contact detail

4.6 Detailed search page description and functionality

The detailed search page makes it possible to, on a single page, search all contract details and

attributes. It fits into the sitemap as displayed below in figure 19 and is accessed through the

“Detailed search” link located in the top menu (which, for a logged in user, is available from any page

within the application).

Figure 19: Detailed search page's position on site map

The detailed search page content is, in the same way as the contact details page, structured into the

five main categories: birthdays, names, addresses, phone numbers and email & instant messaging.

These five categories are presented in five tables. Each table contains all contact detail entries, for

the concerned category, for all available contacts (for the logged in user). “Contact ID” is the first

column of each table. This column displays a unique contact id that has been assigned to the contact.

By using the filter function and the contact ids as common denominators, it is possible to narrow

down contact details within each table and also between tables. The filtering, sorting, pagination and

all other functionality works in the same way as for the contact list page’s table.



Please see figure 20 as an example, where different search criteria have been entered in each table.

By writing “@test” in the “Email & IM” table, all contacts’ all entries containing the search criterion

are presented.

Figure 20: Detailed search page

By clicking on a contact, anywhere in the row, the user is redirected to the particular contact’s details

page. On this page, the user can view and change the contact’s details. The details page content and

functionality are described above in the Contact details page description and functionality section.

A future enhancement would be to make the contact id numbers more unique, to avoid mixing the

contact ids that street numbers, zip codes and other digits when doing searches. It could also be

advisable to be able to enter more complex search criteria with “AND” and “OR” statements as well

as limiting search content to specific columns and parts.



4.7 Entry types page description and functionality

The entry types page gives the user the possibility to view, update, add and delete entry types that

are used for the contact details. It fits into the sitemap as displayed below in figure 21 and is

accessed through the “Entry types” link located in the top menu (which, for a logged in user, is

available from any page within the application).

Figure 21: Entry types page's position on site map

Apart from being able to assign one birthday per contact, all contact information is categorized into

the following tables (as described in previous chapters):

• Names

• Addresses (geographical)

• Phone numbers

• Email & Instant messaging addresses

For each of these categories it is possible to define as many entry types as wished as long as there

are no duplicates. For example, for the names table, the user can choose to have an entry type called

“nickname”, “maiden name”, “middle name”, “first name”, “last name” etc. For addresses, it could

be “residential”, “office”, “summer place” etc. For each of these entry types, the user can add as

many entries as wished on the contact details page.

The entry types web page hosts tables for the above listed four categories. The tables consist of two

columns:

• an entry type column with the name of the entry type (such as “Nickname”) and

• a description of the entry (for example “the nickname is an informal name that isn’t used in

formal communication nor registered with the authorities”).

The entry types are not global, but are individually set for and by each user of the application.

Figure 22 describes the entry types web page with its four tables.



Figure 22: Entry types administration page

The contact list web page has fixed columns containing preset entry types (such as “last name” and

“first name” and “email”). These entry types are mandatory to have and cannot be modified or

removed from the tables on the entry types web page. Such entries are grayed out and have the text

“(fixed/mandatory)” appended in the entry type column.



Note that the “Telefax” entry type in the phone number table is mandatory. This is due to that the

telefax entry type’s data always is excluded from showing up on the contact list web page’s table (so

that the user doesn’t accidently dial a number that is thought to lead to some kind of phone but

reaches a fax machine).

4.7.1 Adding an entry type

An entry type is added by clicking the “Add type” button in the header of the concerned table. By

clicking the button, a form is presented – please see figure 23.

Figure 23: Add new nametype dialog box

The procedure of adding an entry type is performed similarly to the process of adding new contact

details.

As mentioned, duplicate entries are not accepted. If the user attempts to create a duplicate entry

(for the entry type field), it will be disregarded and not added to the database.

4.7.2 Deleting an entry type

By clicking (with the left mouse button) on an entry type, the row is selected and highlighted in a

darker color. When selecting a row, the “Delete type” button also becomes clickable (please see the

corresponding section outlining the deletion of a contact detail entry).

Clicking the “Delete type” button brings up an alert box informing about that by clicking the “ok”

button and deleting the entry type, all contact details associated with it will be removed as well.

Grayed out entry types cannot be deleted, and an error message is presented to the user if a deletion

is attempted.

An entry type is deleted without triggering a web page reload.

4.7.3 Modifying an entry type

All table fields, except for the ones being grayed out can be modified by clicking on them with the

right mouse button. The grayed out field will not react to a right click.

By doing a right click on a field, the user is presented with the possibility to edit the currently existing

field value.

The tables’ field values are modified without needing to trigger webpage reloads.



4.8 Logout functionality

The logout link is found in the top right corner of the web page. It fits into the sitemap as displayed

below in figure 24.

Figure 24: Logout page's position on site map

Next to the logout link, the logged in user’s username is displayed – please see figure 25 below (the

username pointed at). By clicking on the logout link, the user is logged out from the application and

set back to the login screen.

Figure 25: Logout link



5 Application architecture This chapter describes the application’s architecture – how it has been built and how it works.

The 5.1 How the application code works section illustrates the server and client side application

architectures and how its components are connected.

The 5.2 Back and front end communication section focuses on how data is transferred between the

front and the back end using the JavaScript libraries, without the need of reloading the web page.

In the 5.3 Database structure section, the database architecture and setup is described.

5.1 How the application code works

This section provides, through an example, an overview of how the application is run; how the back-

and front end files are linked and where (web server or client browser) they are run.

All application files are initially stored on the web server side (backend) and loaded when requested

by a web browser.

The PHP files (suffix “.php”) are used for the server side execution, and the JavaScript files (suffix

“.js”) are run on the client side. The processed PHP files generate HTML code sent to the client’s web

browser. This HTML code includes links triggering actions that make the client browser load and

(locally) execute the JavaScript files.

In the style sheet files (“.css”), web page content formatting, such as font sizes, colors and

alignments, are found. Just as with the JavaScript files, the content of these files are loaded by the

client’s web browser after having been directed to the “.css” file from within the HTML code.

Appendix A, Appendix B and Appendix C host tables with descriptions of each individual PHP, CSS and

JavaScript file. Appendix D lists the application’s PHP classes, their members and functions.

To exemplify the overall architecture of the application and what happens when the different pages

are accessed; the loading process of the contact list page is used. It covers what is done on the server

and client side when the contact list is loaded.

Figure 26 outlines which files are accessed (and objects used) when the contact list (index.php) page

is loaded. It shows how the PHP files and objects are connected as well as which client side JavaScript

and CSS that are executed in the web browser.



Figure 26: Files and classes accessed upon contact list page load



To summarize what already has been described, the following occurs on the server and client side

when a PHP file is loaded:

1. A user’s web browser requests the web page file, e.g. index.php, from the web server.

2. The PHP script parts of the index.php file are run. The resulting output replaces the PHP

content with HTML formatted/tagged code.

3. The response (after running the PHP code in index.php) now only contains browser

interpretable data – such as HTML and JavaScript. The content is transferred, together with

the CSS and JavaScript files, to the requesting web browser.

4. The user’s web browser receives the data together with links to CSS and JavaScript files.

5. When building the web page, the browser fetches the CSS and JavaScript files in order to

apply their formatting and run their code.

5.1.1 Back end (server side) activities

In the particular case of accessing index.php as a logged in user (as displayed in figure 26), the

following happens on the server side:

1. PHP code in index.php instantiates an AddressBook object and runs its populateBook

function.

2. To be able facilitate the contact with the application’s MySQL database, the AddressBook

object instantiates a DBAccess object.

3. Using the DbAccess object, the AddressBook object’s populateBook method reads all the

user’s stored contact ids from the database and saves the id number in an array of

instantiated Contact objects’ id member variable.

4. The populateBook method now uses each Contact object’s populateContact method.

5. The Contact object’s populateContact function populates arrays of name-, address-, phone

number- and email address objects. These objects are, using the contact’s id, populated with

data fetched from the MySQL database.

Now the AddressBook object contains contacts, which in turn are populated with arrays of

(objects with) names, addresses, phone numbers and email addresses.

6. In index.php, the populated AddressBook object’s outputContactListBody method is called.

7. The outputContactListBody method’s task is to generate rows with data to the contact list

table. In order to do this, it fetches one first name, one last name, one street address etc for

each contact and outputs this information together with HTML tags. In order to fetch only

the desired entry for each field (for each contact), it uses the Contact object’s

displayOneName, displayOneAddress etc methods.



5.1.2 Front end (client side) activities

Now that all PHP parts (server side code) of the index.php files have been run and replaced by HTML-

formatted output data (in this case a contact list table), the resulting HTML file is sent off to the

client’s web browser. The HTML data is formatted with the use of the CSS files that are loaded

through the HTML header. However the content of the file is static (no filtering, sorting or pagination

is possible). This is remedied by the client browser executing the JavaScript files that are loaded

through the HTML header.

The following happens, on the client side, from that the index.php file has been received by the web

browser until the page is displayed to the user:

1. The CSS and JavaScript files in the header are loaded. For the JavaScript files, the load order

is important if the files depend on each other.

2. CSS formatting is applied to the web page content, according to the settings in the CSS files

mentioned in figure 26. For example, adding row highlighting when the user hovers over a

row in the table and to add different colors to odd and even rows in the table (to increase

readability), are features that are applied.

Some of the CSS files are prebuilt by the jQuery UI framework and are applied by the

DataTables or other jQuery based plugins.

3. All JavaScript files (loaded in index.html) but common.js and contactlist.js are:

a. prewritten and have not been altered (with one insignificant exception).

b. dependent on a file initiating the DataTables and DataTables Editable plugins.

4. contactlist.js initiates the DataTables and DataTables Editable plugins/libraries. This is done

by a jQuery selector [16], which in this case point at the #contactList id (which identifies the

contact list table). By doing this, the DataTables plugin files apply all formatting and intro-

duce necessary interactivity (such as listeners and event handlers) to setup the desired

DataTables.

5. contactlist.js and common.js also host non-DataTables related code, such as functionality to

make it possible to click on a contact’s table row and get directed to the concerned contact’s

contact details page.

Thanks to the client side JavaScripts and by HTML tagging data with classes and ids, it is possible to

easily change and modify content on the web page without needing to get new code from the web

server. Such client side scripting has as mentioned, mainly been done using the jQuery library.



5.2 Back and front end communication

5.2.1 Introduction

The previous section has outlined what happens on the server and client side when an application

web page is loaded.

This application uses dynamical content, making it possible for users to interact with the displayed

web pages in the same way as they would do with any application that runs directly on the operating

system. As an example it is possible to right click on a contact’s name day month and there, through

a dropdown list that appears, pick a different month.

In the background, when the name day’s month is changed, the client application needs to ensure

that it has received correctly formatted information, send it over to the web server (that possibly

also validates the data) which in turn stores the new month in the database for the contact.

Web applications, from a web server side perspective, are terminated as soon as the requested

page/data has been sent off to the client’s web browser. In the above scenario, when a user (thanks

to the JavaScript functionality in the web browser), modifies the name day’s month on the web page,

the change also needs to be sent off, by the client to the web server (which in turn updates the

database).

In the information sent off to the web server, the client also needs to include all necessary

information about what has been changed on which contact (and for which user) in order for the

web server to know what to modify (as the web server does not store the information that it

previously has sent off to the client’s web browser).

In addition to the complexity of the information exchange in the mentioned birth day month

example, the user interface is also an important component. It would be possible to use traditional

HTML forms with submit buttons, but this would provide a cumbersome and not intuitive user

experience. However in order to mimic the behavior of non-web-based application, the interactivity

needs to be seamless – as soon as the user has changed the month, it should be directly updated on

the web page (and changed in the database on the web server side) – without the user needing to

reload the web page or noticing what is happening in the background.

The interactivity in the front end is ensured by the JavaScript based jQuery library, which in turn is

used by plugins such as jEditable, DataTables and DataTables Editable.

How to communicate client-side initiated changes with the web server (such as changing the name

day’s month), without needing to unnecessarily reload the whole page and to eliminate the need for

pushing extra “submit form” buttons, is the topic of this section. It also outlines the communication

setup between the pages; what data is being transferred and how the communication is conducted.

Below subsections cover the overall communication scenarios. The first section exemplifies what

happens in the communication between two web pages in the application – the contact list and

contact details pages. The second section explains how content dynamically, in AJAX style, is updated

on the contact details page.



5.2.2 Communication between the contact list and contact details page

5.2.2.1 Sessions

When the contact list web page is loaded, the first thing that happens on the server side is to check

which user has submitted the request. The user ID is stored as a session cookie which is passed on,

by the web browser to the web server. This applies to all server side PHP pages in the application.

Thanks to the userid, the application is able to determine which user’s contact to display as well as to

ensure that the user has logged in with correct credentials. If the session cookie hasn’t been set, the

web browser is directed to the login page.

If a logged-in user clicks on the logout button in the top right corner of the application, the user is

logged out by that the session key is removed (what actually happens is a redirection to the login

page, which always starts its execution by removing any existing user ids).

5.2.2.2 GET method

For the contact list (index.php) page, the GET method is used to bring up the corresponding contact’s

contact detail page when a user clicks on a certain contact in the contact list. That the GET method

has been used, is revealed in the contact detail page’s address field, please see figure 27.

All table rows, in all tables residing in the application, are identified with HTML “TR id” tags [21]. The

id tags hold values that are unique to the rows and therefore make each row identifiable by the

server side. For example, in the contact list web page’s table, each row is equipped with the TR id tag

populated with the id number of the contact residing to the row. In figure 27 above, therefore the

row’s id tag would look like “tr id=”23”.

Regarding the communication, when a user clicks on the row, a jQuery function in the web pages’s

JavaScript file (contactlist.js) extracts the table row’s id value and adds it as a GET request into the

contact detail web page’s URL. Figure 27 shows the outcome of this, and what the resulting URL

looks like on the contact details page (displaycontact.php).

In the displaycontact.php file’s code, the variable in the GET part of the URL is interpreted and

assigned to a variable called id with the following code: “$id = $_GET['contactId'];”.

? reveals GET, contactID

is assigned 23 as value

Figure 27: HTTP GET method shown in URL



5.2.3 Dynamic page modifications using AJAX

In the previous section as well as in the Background chapter’s 3.5 “Front and back end

communication techniques” section, it was outlined how information is passed on from the client to

the server through the HTTP POST and GET methods. The POST method isn’t, as mentioned, directly

used in the HTML code. Instead it is dynamically utilized by the DataTables Editable plugin.

The DataTables Editable plugin relies on and integrates several other plugins such as jEditable and

JQuery Validation.

The jEditable plugin makes it possible to “click and edit content of different html elements” [22]. By

implementing jEditable, the web page becomes interactive and makes it possible to do “inline”

editing of page content. jEditable makes it possible to select, by simple jQuery queries, HTML

elements (such as id and class tagged objects). In addition to updating the element content in the

web browser page, jEditable also supports sending the new values to a web server.

This communication is achieved by using the HTTP POST method. DataTables Editable’s

implementation of jEditable makes it possible to adjust DataTables table cell values and send them

off to a web server script file, as long as each table row is assigned and identifiable through a web-

page unique HTML id element. In order for the DataTables Editable plugin to work, the following is

required:

• each DataTables row needs to have an id. On the contact management application’s contact

details page’s tables, the row ids are composite strings consisting of the following elements:

o the contact id (for example, contact id 23, which also is noted in the URLs GET part),

o type of entry (ContactName for name entries, ContactAddress for addresses etc) and

o the entry id (each entry, such as a name entry, has an entry number in the database.

This entry number is connected to the contact as well as the user).

The row id composite values are separated by underscore (“_”) characters. Figure 28 below

illustrates an example of what this could look like. The Mozilla Firefox web browser’s

Firebug5 extension clearly shows the “tr id” with the above described elements.

5 http://getfirebug.com/



Figure 28: Firebug showing row ids on contact details page

• that a destination file is provided to send the changed data entries to. In the figure 28

example above, a contact’s name is looked at. This table is controlled by the code in the

displaynametypes.js file. In this file, the web server destination file is defined as

sUpdateURL: "UpdateContent.php", which means that the UpdateContent.php files is

addressed a HTTP POST submit with the changed information.

• that the server side file processes the input. In the above example, it would be

UpdateContent.php. This file needs to process the change request (sent in the HTTP POST)

and then correctly answer back to the JavaScript query that everything has gone well or

information about that the change hasn’t been implemented by the server side (and in the

database).

What differs from a normal HTTP POST submit in the above described communication, is that a

JavaScript XMLHttpRequest object is used to facilitate the client end’s communication with the web

server. Through the XMLHttpRequest object, the web server file, in this case UpdateContent.php is

requested (providing the information in the HTTP POST submittal). The PHP file’s HTML response

won’t load as a new web page in the user’s browser but instead be caught by the XMLHttpRequest

object and processed by the JavaScript code. This whole communication is hence done without

reloading the web page. This procedure and type of JavaScript coding is called Asynchronous

JavaScript and XML (AJAX) [23].

The whole DataTables Editable plugin is based on AJAX type of communication. To visualize what the

above communication scenario would look like, an example is provided describing what happens

when a name table entry is changed on the contact details page:



1. The user right-clicks on the Name column, in order to change cell content, which currently

hosts the “Ceasar” name. The cell turns editable, please see figure 29.

Figure 29: Table cell turns editable

2. The user now changes the name into “Gaius” and hits the ENTER key. The XMLHttpRequest

(abbreviated XHR) is sent to the server including HTTP POST data. The information

submitted, such as the new cell value and table row ide is illustrated in the Firebug window,

figure 30 below.

Figure 30: New data posted to the server

3. In the UpdateContent.php file, the data is processed and the new name is successfully

updated to the MySQL database. To tell the DataTables Editable JavaScript that the update

was successful on the server side, the same information that was received by the server is

echoed back as a response (from the php file) to the web browser. This is illustrated in figure

31 below, describing the answer to the web page (UpdateContent.php) request.



Figure 31: Confirmation response from the server

4. As seen in figure 31, the response to the query is “Gaius”. The DataTables plugin interprets

that the same information was received back as sent off earlier, as a success statement. The

“Ceasar” name is therefore replaced by “Gaius” in the edited DataTables cell. No reload of

the contact details page has been done during the name change process.

Adding new and deleting current entries is done in the same way regarding the backend

communication.

5.3 Database structure

By using foreign keys and striving to apply Boyce-Codd normal form when designing the MySQL data-

base, the risk of unintentional inconsistency and unexpected behavior is reduced [24].

The database schema is modeled in Appendix E.

Regarding the database architecture, the following is noted:

• Structure-wise there is a contact table hosting a unique identifier (contact id) for each

contact. The contact table also ties the contact to a certain user found in the users table. The

userid is therefore a foreign key in the contact table. One user can have many contacts, but

one contact can only belong to one user.

• Content-wise, the contact table hosts the contact’s birth date information.

• There are four tables called contact_has_name, contact_has_address,

contact_has_phonenumber and contact_has_email. These tables host information about the

concerned types of entries – for example the contact_has_name table host name days

columns for the particular name. The contact_has_address table provides fields to input

street name, district, country and other address related data.



• Each contact_has_* table is connected to only one contact. However one contact could

none, one or several entries in each respective contact_has_* table. Therefore the contacted

is a foreign key in the contact_has_* tables.

• Each contact_has_* table also hosts an entry type column. For names, these entry types are

for example first name, last name etc. The column is therefore, in the contact_has_name

table, called nametype. The nametype is a foreign key linked to the nametypes table, which

hosts the different available nametypes (with descriptions). Each contact_has_* table has

this kind of *types table connected.

• Each contact_has_* table has a counting id integer (nameid, addressed) as primary key. Each

*types table also has an integer identifier as primary key.

• The *types tables have userids as foreign keys as every user have their own sets of *types

table entries.

• The users table hosts a userid, the users’ email (which is the same as username) and a

hashed password string.

• Although foreign keys enforce consistency on a database level, checks to avoid possible

inconsistency are to some extent implemented in the PHP code as well.



6 Results This chapter presents and discusses the results, whether the goal was achieved and to what extent

the requirements were met. The major challenges are highlighted and the results are analyzed.

Finally a section describes possible improvements and future work with the application.

6.1 Setting up and running the application

The contact management software is built to be working with a PHP enabled Apache server and a

locally hosted MySQL database. Appendix G describes how to install the application.

To use the software, a user simply needs to access the URL that leads to the application’s index.php

file.

6.2 Requirements fulfillment, result analysis and challenges

The user and technical requirements in the analysis chapter have been met. Some of the

requirements, such as the one about mimicking the behavior of a locally installed program, can be

fulfilled to different degrees. The same goes for how a detailed search page should behave and look.

An overall goal has been to use prewritten front end libraries and plugins when possible, in order to

focus on building logic in the backend and to get a good user experience which otherwise wouldn’t fit

into the project’s time frame. Thanks to DataTables, a good foundation for the software’s user

interface has been set.

The challenge has been to tweak and configure the DataTables and DataTables Editable plugins to fit

the application requirements. In order to keep the updatability of the software, core changes of the

plugins have been almost completely avoided. Instead plugin configuration files, as well as own

jQuery code, has been used to fill the gap between the “off the shelf” plugin and the contact

management application’s need. An example of this has been how to identify contacts and their

details in the DataTables (in order to tell the server side code what is being changed/added/deleted).

From a knowledge perspective, it has been challenging to analyze and understand insufficiently

documented and sometimes not properly functioning, prewritten, jQuery plugins.



6.3 Suggested future improvements

Although the requirements have been fulfilled, the software can of course be improved in many ways

– both from security and feature perspectives. The following list, which isn’t sorted by any kind of

priority, shows a sample of possible improvements to be done:

• Improve user authentication and registration by introducing activation and “forgot

password” emails. Allow login through Open ID, Facebook and Google Accounts.

• Add security such as encryption and certificates to the login as well as to the sessions.

• Update the MySQL related functions, as not the latest version of PHP MySQL functions is

used (such as replacing mysql with mysqli).

• Adding support for mobile devices’ web browsers and make the application look good no

matter what screen or browser size the user has. It currently works well with web browser

windows that are larger than 1366x768 pixels (meaning that the user, on an average laptop,

should maximize the browser window in order to experience the application as intended).

• Add support for more web browsers. The application hasn’t been tested on anything but

certain Mozilla Firefox versions.

• Improve the handling of duplicate entries for the entry type page (the back end handles it

correctly; however the front end makes it look like it's possible to create duplicates).

• Front end error messages and error handling missing when the application fails to add, for

example, new addresses.

• Support user contact lists with more than 1000 contacts. This by introducing more frequent

back end reading, which in turn is supported and featured in DataTables. Currently all the

user’s contacts are loaded into the web browser when the user accesses the contact list

page, which creates hefty load times and poor user experience (if the contact list page

contains, say, 10000 entries).

• Investigate whether the “ok” and “cancel” buttons should be displayed when editing cells.

Most users will probably use the ENTER key on their keyboards so this is a best-practice and

user experience topic.

• Better handle automatic logouts (due to timeouts / idle time) in order to avoid error

messages when trying to manipulate entries and in the meantime have been logged out (due

to inactivity).

• Improve the detailed search web page to support logical operators (such as AND and OR).

Make it possible to only search certain fields and also implement the contact id field better

into the search experience (the user shouldn’t necessary have to be aware of that a contact

id exists).



7 Summary and conclusions Many webmail service companies provide contact management applications as part of their offering.

Thanks to that the contact management software is run inside a web browser and is hosted by the

webmail provider, users can easily access it from anywhere and without needing to install dedicated

software. The disadvantage is that the users are dependent on and tied to the service’s availability,

integrity and subscription costs.

There are several contact management applications that can be locally installed on the users’ com-

puters. By using them, the users gain control of the data and the application’s availability. However,

these applications lack fundamental features that web services offer; such as easy access from any

internet connected computer, non-existing installations and seamless rollout of software updates.

No obvious, customizable, address book solution exists for those users that neither trust a third

party’s integrity nor accept desktop applications’ shortcomings.

The goal has been to develop an application that combines the positive aspects of contact

management services offered by web companies with the advantages of locally installed address

book programs.

This goal has been realized through the creation of a contact management application that anyone

can setup on their own server and then let users access and manipulate their contacts without

involving third party services. By owning the application code, the users and administrators are not

dependent on other services’ features and reliability. Thanks to that the application code is open

source, advanced users and corporations can tailor and modify the software to suit their own needs.

In order to minimize the burden for the users, the software is realized as a web application. This

eliminates the need for local installations on user computers, makes the application operating

system independent, provides the user the opportunity to access his/her contacts from any location

with internet access and requires nothing but a modern web browser.

The password protected and multi-user application behaves just like any other locally installed

software, with dynamic content editing and updating. It lets users assign as many entries as they

wish to a certain contact and also supports a variety of filtering and sorting options.

The application is setup in PHP, MySQL and JavaScript, and by using JavaScript related plugins and

libraries. MySQL and PHP are used to store data on a central database server and to implement

business side logic. The PHP code also generates the client-side of the application, which hosts

interactive and dynamic web pages.



8 References

[1] C. Savage, E. Wyatt and P. Baker, "U.S. Confirms That It Gathers Online Data Overseas," 6 June

2013. [Online]. Available: http://www.nytimes.com/2013/06/07/us/nsa-verizon-calls.html.

[Accessed 13 June 2013].

[2] M. Duerst, L. Masinter and J. Zawinski, "The 'mailto' URI Scheme," Internet Engineering Task

Force, October 2010. [Online]. Available: http://tools.ietf.org/html/rfc6068. [Accessed 29 March

2013].

[3] "HTML5," W3C, 17 December 2012. [Online]. Available: http://www.w3.org/TR/html5/.

[Accessed 28 05 2013].

[4] "HTML5 Web Storage," w3schools.com, 2013. [Online]. Available:

http://www.w3schools.com/html/html5_webstorage.asp. [Accessed 25 May 2013].

[5] "Usage Statistics and Market Share of JavaScript Libraries for Websites, March 2013," W3techs,

2013. [Online]. Available: http://w3techs.com/technologies/overview/javascript_library/all.

[Accessed 28 March 2013].

[6] S. Craig and E. Castledine, jQuery: Novice to Ninja, 2 ed., Collingwood, Victoria: SitePoint Pty Ltd,

2012.

[7] ”DataTables (table plug-in for jQuery),” SpryMedia, 2013. [Online]. Available:

http://www.datatables.net. [Använd 28 03 2013].

[8] J. Popovic, "jquery-datatables-editable - JQuery plugin that adds CRUD Data Management

functionalities to the data table - Google Project Hosting," JQuery DataTables Data Manager,

[Online]. Available: https://code.google.com/p/jquery-datatables-editable. [Accessed 28 March

2013].

[9] ”Usage Statistics and Market Share of Web Servers for Websites, March 2013,” W3techs, 2013.

[Online]. [Använd 29 March 2013].

[10] "Usage of server-side programming languages for websites," w3techs, 27 June 2013. [Online].

Available: http://w3techs.com/technologies/overview/programming_language/all. [Accessed 28

June 2013].

[11] "PHP: General Information – Manual," PHP Manual, May 2013. [Online]. Available:

http://us.php.net/manual/en/faq.general.php. [Accessed 24 May 2013].

[12] "DB-Engines Ranking - popularity ranking of database management systems," DB-Engines, March

2013. [Online]. Available: http://db-engines.com/en/ranking. [Accessed 29 March 2013].

[13] "MySQL :: The world's most popular open source database," MySQL, 2013. [Online]. Available:



http://www.mysql.com. [Accessed 29 03 2013].

[14] J. P. C. M. T. Converse, "PHP5 and MySQL Bible," Indianapolis, Wiley Publishing Inc, 2004, pp.

241-243.

[15] e. a. Fielding, "HTTP/1.1: Method Definitions," W3, June 1999. [Online]. Available:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html. [Accessed 2 April 2013].

[16] "Ajax | jQuery API Documentation," jQuery, 2013. [Online]. Available:

http://api.jquery.com/category/selectors. [Accessed 30 March 2013].

[17] "HTTP Methods GET vs POST," w3schools.com, [Online]. Available:

http://www.w3schools.com/tags/ref_httpmethods.asp. [Accessed 2 April 2013].

[18] "Ajax | jQuery API Documentation," jQuery, 2013. [Online]. Available:

http://api.jquery.com/category/ajax. [Accessed 30 March 2013].

[19] "XMLHttpRequest," W3C, 6 December 2012. [Online]. Available:

http://www.w3.org/TR/XMLHttpRequest. [Accessed 20 March 2013].

[20] "jQuery UI," jQuery user interface, 2013. [Online]. Available: http://jqueryui.com. [Accessed 2

April 2013].

[21] "Introduction to tables," W3C, [Online]. Available:

http://www.w3.org/TR/CSS21/tables.html#tables-intro. [Accessed 2 April 2013].

[22] M. Tuupola, "Jeditable - Edit In Place Plugin For jQuery," Jeditable, 2013. [Online]. Available:

http://www.appelsiini.net/projects/jeditable. [Accessed 10 April 2013].

[23] "JavaScript Web APIs," W3C, [Online]. Available:

http://www.w3.org/standards/webdesign/script.html. [Accessed 1 May 2013].

[24] T. Padron-McCarthy and T. Risch, "Databasteknik," 1:5 ed., Lund, Studentlitteratur AB, 2005, pp.

217-234.

Alexander Kassai Web-based address book Page I

Mälardalen University Course CDT307 Appendix A – PHP files

Appendix A – PHP files In order to load a web page, the user accesses (through clicking on links) an URL that ends with one

of the below listed PHP files (if the file contains script code that builds a web page and not just a

class). The following table lists PHP files that are used:

File Description

AddContact.php

This file is accessed when new contacts are created through the add

contact form on the contact list (index.php) page. The file among all uses

contact objects (Contact.php).

The file is never directly accessed by the user but is triggered by the

DataTables editable’s jQuery code when adding a new contact (the

entered contact information form content is submitted to this file).

AddContent.php

The file is run when a new contact detail is created through the contact

details web page (displaycontact.php).

Is never directly accessed through the web browser address field or links,

but is used by the DataTables Editable’s add forms on the contact details

page (the entered contact detail information form content is submitted to

this file).

AddressBook.php

Hosts the AddressBook class, which among all is used to populate the

contact list and detailed search web pages with information.

As it is a class, it’s never directly called upon through the web browser. The

AddressBook class uses DbAccess and Contact objects.

AddType.php A file that is used by the add entry form on the entry types web page. The

file is making sure that the new entries are added.

advancedsearch.php

This is the detailed search web page, which displays all database contact

data for the logged-in user.

advancedsearch.php is directly accessed through the application’s top

menu link. It initiates and uses an AddressBook (AddressBook.php) object

for the listing.

ContactAddress.php,

ContactEmail.php,

ContactName.php,

ContactPhone.php

These class files host Address, Email, Name and Phone number objects.

They contain attributes to their respective object types (such as street

name, zip etc. for the ContactAddress class objects).

These objects are initiated and populated by among all the Contact class.

They contain methods to output their content in various ways.

Contact.php

The Contact class sets up an object that hosts all stored data about a

contact. Therefore it also initiates ContactAddress, ContactEmail etc.

objects (as described above).

The class hosts several methods that:

• read data from the database

• sort and output relevant data according to different needs

• create new user ids in the database

Alexander Kassai Web-based address book Page II


The class is used by the AddContact.php, AddressBook.php and

displaycontact.php files.

DbAccess.php This class sets up objects that facilitate the communication between the

PHP scripts and the Mysql database

DeleteContact.php Same setup as AddContact.php, but is instead used to remove a contact.

DeleteContent.php Same setup as AddContent.php, but used to remove a contact’s content.

DeleteType.php Same setup as AddType.php, but used to remove an entry type.

displaycontact.php

This is the contact details web page, which lists and makes it possible to

modify data for a particular contact.

The file is directly accessed by clicking on the contact that should be

displayed from the contact list (index.php) or detailed search

(advancedsearch.php ) web pages. The file is always accessed with a GET

query stating the id of the contact that is to be displayed.

displaytypes.php

This is the entry types web page, which lists and makes it possible to

modify a user’s available entry types.

displaytypes.php is directly accessed through the application’s top menu

link.

entrytypes.php

This script file is used by the displayaddresses.js, displayemails.js,

displaynames.js and displayphonenumbers.js files in order to fetch

available entry types in JSON 6format for the dropdown lists on the display

contact (displaycontact.php) web page.

index.php

This is the contact list web page, which lists contacts and makes it possible

to add new and remove current ones. This is the main page fetched by the

web browser if not specific file is provided in the URL’s file directory.

index.php is also directly accessed through the application’s top menu

bar’s link. It initiates and uses an AddressBook (AddressBook.php) object

for the contact listing.

login.php

This is the file that all other php files direct the visitor to in case a valid

login session is not found or when a logged in user clicks the “logout” link

in the top menu bar’s link.

login.php uses user (User.php) objects and authenticate the login attempts

as well as to logout logged-in users.

register.php

register.php can be directly accessed or redirected to from the login

(login.php) web page when a user account is to be created.

Register.php uses user (User.php) objects to create and setup new users.

UpdateContent.php

The file is run when a contact detail is updated through the contact details

web page (displaycontact.php).


but is used by the DataTables Editable’s update scripts on the contact

details page.

UpdateType.php

The file is run when a contact type is updated through the entry types web

page (displaytypes.php).

6 http://www.json.org/

Alexander Kassai Web-based address book Page III



but is used by the DataTables Editable’s update scripts on entry types

page.

User.php

This file contains the user class, which hosts the attributes and methods

needed to administrate user information and user authentication.

The class also contains a method to setup standard mandatory entry types

(such as first and last names)

User.php is never directly requested, but instead initiated by other scripts,

such as the login web page (login.php).

Alexander Kassai Web-based address book Page IV

Mälardalen University Course CDT307 Appendix B – CSS files

Appendix B – CSS files The below listed CSS files are loaded through the HTML headers in the PHP files in Appendix A. They

apply formatting and style sheet settings to classes and elements on the web pages.

File Description

css/displaycontact.css Loaded by the php files with the same corresponding file names (but

with .php as extensions). Contains formatting setting for table widths,

table row highlighting when hovering, search result highlighting, top

menu bar alignments etc.

css/register.css

css/advancedsearch.css

css/login.css

css/displaytypes.css

css/contactlist.css This is the css file used by the Contact list page (index.php). It contains

the same type of formatting and styling settings as the above files.

Apart from the above list, the following prewritten stylesheets have been included in the project, as

they are part of the DataTables and its related components:

File Description

http://ajax.aspnetcdn.com/ajax/jquery.ui/1.8.2

2/themes/smoothness/jquery-ui.css Stylesheets connected to the formatting that

the DataTables jQuery library requires. Hosted

on Microsoft’s CDN servers.7 The stylesheets

make it possible to easily apply and change

formatting to DataTables tables.

http://ajax.aspnetcdn.com/ajax/jquery.dataTab

les/1.9.2/css/jquery.dataTables.css

http://ajax.aspnetcdn.com/ajax/jquery.dataTab

les/1.9.2/css/jquery.dataTables_themeroller.css

7 http://www.asp.net/ajaxlibrary/CDNjQueryDataTables192.ashx

Alexander Kassai Web-based address book Page V

Mälardalen University Course CDT307 Appendix C – JavaScript files

Appendix C – JavaScript files The below listed JavaScript files are loaded through the HTML headers in the PHP files in Appendix A.

They run client side code in the user’s browser. This is done in order to provide formatting, a better

user experience and communication towards the backend PHP code.

Apart from files, which are written from scratch, the project also uses JavaScript libraries with

prewritten files. The following files have been written from scratch:

File Description

js/displaybirthdate.js

js/displaynames.js

js/displayaddresses.js

js/displayphonenumbers

.js

js/displayemails.js

These files are run when the user loads the contact details web page

(displaycontact.php). The JavaScripts maps the different tables and

their content to the DataTables and DataTables Editable libraries. They

set up features making it possible to search, paginate and sort the

tables as well as to, through AJAX8 type request, send and retrieve

information to/from the web server without the need to reload the

whole page.

Each file executes code that is applicable for the table with the

corresponding name.

The displayemails.js file includes additional functionality to support

functionality for handling email addresses (“mailto:”).

js/displayemailtypes.js

js/displayaddresstypes.js

js/displayphonenumbert

ypes.js

js/displaynametypes.js

These files are executed when the user loads the entry types web page

(displaytypes.php).

The JavaScripts maps the different tables and their content to the

DataTables and DataTables Editable libraries. They set up features

making it possible to search, paginate and sort the tables as well as to,

through AJAX type request, send and retrieve information to/from the

web server without the need to reload the whole page.

Each file executes code that is applicable for the table with the

corresponding name.

js/common.js

common.js is run when the user loads the detailed search

(advancedsearch.php), contact details (displaycontact.php), entry types

(displaytypes.php) or contact list (index.php) web page.

common.js, among all, contains functions to get correct sorting of

calendar months (January – December), to support highlighting of

search results and to apply formatting to non-supported DataTables

objects (that are not included in DataTables formatting).

This file is loaded before other JavaScript files as its DataTables settings

need to be initiated before the DataTables tables are instantiated.

8 Asynchronous JavaScript and XML – please see http://jquery.com/ for more information

Alexander Kassai Web-based address book Page VI

Mälardalen University Course CDT307 Appendix C – JavaScript files

js/contactlist.js

The contactlist.js file is run when the contact list (index.php) web page

is loaded. The JavaScripts in this file maps the contact list table’s

content to the DataTables and DataTables Editable’s libararies and

ensures that the table becomes sortable, searchable, nicely formatted

etc.

In addition, just like with advancedsearch.js file, the file also includes

code to facilitate the direction to the contact details

(displaycontact.php) web page for a clicked-on contact.

js/advancedsearch.js

advancedsearch.js is run when the detailed search

(advancedsearch.php) web page is loaded. It runs script functions that

provide similar functionality as those in contactlist.js.

Apart from the above list, the following prewritten libraries have been included in the project:

File Description

http://ajax.aspnetcdn.com/ajax/jquery.d

ataTables/1.9.2/jquery.dataTables.min.js The DataTables library and connected components

hosted on Microsoft’s CDN servers.9 These libraries

make it possible to easily create sortable, filterable

and well-formatted tables with pagination support.

http://ajax.aspnetcdn.com/ajax/jquery.ui

/1.8.22/jquery-ui.min.js

http://ajax.aspnetcdn.com/ajax/jQuery/j

query-1.7.2.min.js

editable-js/jquery.jeditable.js

This jEditable10

plugin makes it possible to change web

page content dynamically. It works as an “inplace”

editor, making it possible for the webpage viewer to

change the displayed content.

editable-js/jquery.validate.js A plugin making it possible to set field size limitations,

validate email addresses etc.11

editable-js/jquery.dataTables.editable.js

This plugin provides an easily setup and implemented

framework to make DataTables table cells editable

(using the jEditable and related libraries) as well as

facilitates the backend AJAX-type information

exchange with the server side.

9 http://www.asp.net/ajaxlibrary/CDNjQueryDataTables192.ashx

10 http://www.appelsiini.net/projects/jeditable

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

Alexander Kassai Web-based address book Page VII

Mälardalen University Course CDT307 Appendix D – PHP classes

Appendix D – PHP classes The application contains eight classes, of which seven classes are used for the application usage and

the eight is to facilitate the user authentication. The User class looks like following:

The other seven classes relate to each other as described in figure 25, “3.4.2 How the application

code works” section. Below figures illustrate each of the above listed objects’ members and

methods.

Alexander Kassai Web-based address book Page VIII


Alexander Kassai Web-based address book Page IX


Alexander Kassai Web-based address book Page X


Alexander Kassai Web-based address book Page XI

Mälardalen University Course CDT307 Appendix E – Database schema

Appendix E – Database schema The below schema illustrates the application’s database structure.

Primary keys are marked with yellow key symbols.

Foreign keys are marked with red icons. All foreign key dependencies are set as “on delete cascade

on update cascade”, which means that affected table entries will be deleted/updated upon the

deletion/update of the foreign key.

The relations between the tables are obvious and therefore not commented on in the schema.

Alexander Kassai Web-based address book Page XII

Mälardalen University Course CDT307 Appendix F – Database setup scripts

Appendix F – Database setup scripts This chapter lists the two MySQL scripts that are used to setup the application’s database user and

structure. In a typical Linux-based distribution, such a script is run from the command line interface

with the following syntax:

foo@debian:~$ mysql -u root -p < scriptname.sql

The first script listed below, called “1_create_frame-2012-12-09.sql” is used to setup the tables (and

their relations) described in Appendix E.

The second script, called “2_create_user-2011-07-28.sql” creates the MySQL user that is used by the

PHP code to interact with the database.

Alexander Kassai Web-based address book Page XIII


1_create_frame-2012-12-09.sql – script for setting up the database tables

-- Setup a db if needed and create tables and relations for the ak_contactbook database

-- ------------------------------------------------------------------------------------

CREATE DATABASE if not exists ak_contactbook character set=utf8;

USE ak_contactbook;

CREATE TABLE users

(

userid int UNSIGNED NOT NULL AUTO_INCREMENT,

email varchar(50) NOT NULL,

passkey char(64) NOT NULL, -- the sha256 is always 64 chars long.

PRIMARY KEY (userid)

) ENGINE=InnoDB;

CREATE TABLE contact

(

contactid int UNSIGNED NOT NULL AUTO_INCREMENT,

birthyear varchar(4),

birthmonth varchar(2),

birthday varchar(2),

userid int UNSIGNED NOT NULL,

PRIMARY KEY (contactid)

) ENGINE=InnoDB;

-- -----------------------------------------------

-- Foreign key adding for the contact table

-- -----------------------------------------------

ALTER TABLE contact add FOREIGN KEY (userid) REFERENCES users(userid) on delete cascade on update cascade;

-- -----------------------------------------------

CREATE TABLE contact_has_name

(

nameid int UNSIGNED NOT NULL AUTO_INCREMENT,

contactid int UNSIGNED NOT NULL,

nametypeid int UNSIGNED NOT NULL,

name varchar(25),

namesmonth varchar(2),

namesday varchar(2),

inactivename varchar(3), -- if the person no longer has the name

preferredname varchar(3),

namecomment text, -- for example if the person has taken this name later in life (for example when getting married, in that case when etc)

PRIMARY KEY (nameid)

) ENGINE=InnoDB;

Alexander Kassai Web-based address book Page XIV


CREATE TABLE nametypes

(

nametypeid int UNSIGNED NOT NULL AUTO_INCREMENT,

nametype varchar(25) NOT NULL,

nametypedesc text,

locked varchar(3), -- If the value is set to "Yes", the content is not allowed to be deleted or modified. Such nametypes (as "last

name" and "first name") have been hard coded in order to be able to display relevant entries on the Address Book's main page.


PRIMARY KEY (nametypeid)

) ENGINE=InnoDB;

-- -----------------------------------------------

-- Foreign key adding for the name related tables

-- -----------------------------------------------

ALTER TABLE contact_has_name add FOREIGN KEY (contactid) REFERENCES contact(contactid) on delete cascade on update cascade;

ALTER TABLE contact_has_name add FOREIGN KEY (nametypeid) REFERENCES nametypes(nametypeid) on delete cascade on update cascade;

ALTER TABLE nametypes add FOREIGN KEY (userid) REFERENCES users(userid) on delete cascade on update cascade;

-- -----------------------------------------------

CREATE TABLE contact_has_address

(

addressid int UNSIGNED NOT NULL AUTO_INCREMENT,


addresstypeid int UNSIGNED NOT NULL,

streetname varchar(25),

streetnumber varchar(10),

zip varchar(10),

city varchar(25),

district varchar(25),

country varchar(25),

outdatedaddress varchar(3),

preferredaddress varchar(3),

addresscomment text, -- how long they've lived there or if they only reside there seasonally, or if mail shouldn't be sent there etc, portkod

etc

PRIMARY KEY (addressid)

) ENGINE=InnoDB;

CREATE TABLE addresstypes

(

addresstypeid int UNSIGNED NOT NULL AUTO_INCREMENT,

addresstype varchar(25) NOT NULL,

addresstypedesc text,

locked varchar(3), -- If the value is set to "Yes", the content is not allowed to be deleted or modified. Such addresstypes (as "office" and

"residential") have been hardcoded in order to be able to display relevant entries on the Address Book's main page.


PRIMARY KEY (addresstypeid)

) ENGINE=InnoDB;

Alexander Kassai Web-based address book Page XV


-- --------------------------------------------------

-- Foreign key adding for the address related tables

-- --------------------------------------------------

ALTER TABLE contact_has_address add FOREIGN KEY (contactid) REFERENCES contact(contactid) on delete cascade on update cascade;

ALTER TABLE contact_has_address add FOREIGN KEY (addresstypeid) REFERENCES addresstypes(addresstypeid) on delete cascade on update cascade;

ALTER TABLE addresstypes add FOREIGN KEY (userid) REFERENCES users(userid) on delete cascade on update cascade;

-- --------------------------------------------------

CREATE TABLE contact_has_email

(

emailid int UNSIGNED NOT NULL AUTO_INCREMENT,


emailtypeid int UNSIGNED NOT NULL,

emailaddress varchar(100) NOT NULL,

outdatedemail varchar(3), -- if it no longer is in use

primaryemail varchar(3),

emailcomment text, -- maybe they only read this email(or icq or whatever) in the weekends etc.

PRIMARY KEY (emailid)

) ENGINE=InnoDB;

CREATE TABLE emailtypes

(

emailtypeid int UNSIGNED NOT NULL AUTO_INCREMENT,

emailtype varchar(25) NOT NULL, -- for example email, icq, irc, msn, gtalk, jabber etc

emailtypedesc text, -- to clarify what the certain emailtype means

locked varchar(3), -- If the value is set to "Yes", the content is not allowed to be deleted or modified. Such emailtypes (as "email")

have been hardcoded in order to be able to display relevant entries on the Address Book's main page.


PRIMARY KEY (emailtypeid)

) ENGINE=InnoDB;

-- ------------------------------------------------

-- Foreign key adding for the email related tables

-- ------------------------------------------------

ALTER TABLE contact_has_email add FOREIGN KEY (contactid) REFERENCES contact(contactid) on delete cascade on update cascade;

ALTER TABLE contact_has_email add FOREIGN KEY (emailtypeid) REFERENCES emailtypes(emailtypeid) on delete cascade on update cascade;

ALTER TABLE emailtypes add FOREIGN KEY (userid) REFERENCES users(userid) on delete cascade on update cascade;

-- ------------------------------------------------

CREATE TABLE contact_has_phonenumber

(

phonenumberid int UNSIGNED NOT NULL AUTO_INCREMENT,


phonenumbertypeid int UNSIGNED NOT NULL,

phonenumber varchar(25) NOT NULL,

outdatedphonenumber varchar(3), -- if it no longer is in use

Alexander Kassai Web-based address book Page XVI


primaryphonenumber varchar(3),

phonenumbercomment text, -- maybe they only answer this number in the weekends etc.

PRIMARY KEY (phonenumberid)

) ENGINE=InnoDB;

CREATE TABLE phonenumbertypes

(

phonenumbertypeid int UNSIGNED NOT NULL AUTO_INCREMENT,

phonenumbertype varchar(25) NOT NULL,

phonenumbertypedesc text,

locked varchar(3), -- If the value is set to "Yes", the content is not allowed to be deleted or modified. Such phone

types (as "fax") have been hardcoded in order to be able to display elevant entries on the Address Book's main page (the "fax" numbers are for

example never displayed)


PRIMARY KEY (phonenumbertypeid)

) ENGINE=InnoDB;

-- --------------------------------------------------------

-- Foreign key adding for the phone numbers related tables

-- --------------------------------------------------------

ALTER TABLE contact_has_phonenumber add FOREIGN KEY (contactid) REFERENCES contact(contactid) on delete cascade on update cascade;

ALTER TABLE contact_has_phonenumber add FOREIGN KEY (phonenumbertypeid) REFERENCES phonenumbertypes(phonenumbertypeid) on delete cascade on

update cascade;

ALTER TABLE phonenumbertypes add FOREIGN KEY (userid) REFERENCES users(userid) on delete cascade on update cascade;

-- --------------------------------------------------------

2_create_user-2011-07-28.sql – script for creating the database user

-- Create a user for the ak_contactbook database

-- ---------------------------------------------

-- Server: localhost

-- Username: cbuser

-- Password: contact1Book2user1

CREATE USER 'cbuser'@'localhost' IDENTIFIED BY 'contact1Book2user1';

GRANT INSERT, DELETE, REFERENCES, SELECT, UPDATE ON ak_contactbook.* TO 'cbuser'@'localhost';

Alexander Kassai Web-based address book Page XVII

Mälardalen University Course CDT307 Appendix G –Installation instructions

Appendix G –Installation instructions This appendix describes how the application is installed onto an Apache web server.

Prerequisites for the installation are that the web server is supporting PHP, has a root directory to

host the application and that a MySQL database is locally available on the same server (reachable on

the IP address 127.0.0.1). As the application uses index.php as main page, it is important that no

other web sites are located in the directory structure.

The application is installed according to this procedure:

1. Place the PHP files in the document root of the web server.

2. Put the JavaScript files in a subfolder named “js” (directly under the root of the web server).

3. Put the CSS files in a subfolder called “css” (directly under the root of the web server).

4. Place the “editable-js” directory, with all content, in a folder with the same name (directly

under the root of the web server).

5. Make sure that the folder and file permissions allow the web server to access the files.

6. Run the DB setup scripts as described in Appendix F.

Access the application by entering the URL of the web server’s document root directory (where the

index.php file is located).

Documents

School of Innovation, Design and Engineeringmdh.diva-portal.org/smash/get/diva2:643591/FULLTEXT01.pdf · Examiner: Dag Nyström, Mälardalen University ... School of Innovation, Design