designing framework for web development
TRANSCRIPT
Designing framework for web development Mohammad Hafijur Rahman
Department of Informatics and Media
Degree project 30 credits.
Autumn term 2011
Supervisor: Dr. Jonas Sjöström
Abstract In this software development era it is a key point to make software in such a good way so that it earns
reliability and stability with a satisfactory level of standard that enhances easy modification and
tailoring. By definition in the context of software development a framework is a tool for developing
any software quickly and to gain most architectural advantages. However to use any framework
developers or programmers who are just starting-out will find it difficult to use as it requires a descent
level of understanding of various Object Oriented Programming (OOP) techniques and principles.
Never the less, frameworks improve quality, consistency and even allow junior programmers to have
good contribution in a large scale project with minimal guidance. So it is very important that
frameworks are understood by the developers to promote good practices for maintaining a better
structure of the software. The aim of this thesis is to develop a full functional Model View Controller
(MVC) driven framework (PHPWebPad) based on Object Oriented Programming in PHP5. This
research is categorized as Design Science Research (DSR) and I use a subset of Hevner’s evaluation
method to explore different design artifacts in PHPWebPad. I explain several distinguishing
differences and improvements in PHPWebPad compare to other well-known frameworks. Further this
project is released as open source program under General Public License (GPL).
Keywords:
PHP, PHP5, PHPWebPad, Web development framework, MVC, ORM, Abstract design patterns, Load
by demand, Design science.
Acknowledgement
I am glade to make my research from Uppsala University, Sweden. This is one of the prestigious
universities in the world. I am very thankful to my supervisor Jonas Sjöström who helped me through
various means. It is my honor to learn from him. I would also like to thank specially one of my
favorite teachers Anneli Edman for her great help at the end. This thesis is an effort of collective
knowledge that I have learned from my great teachers, friends, and colleagues. I am grateful to
everyone.
Table of Contents
1. Introduction ........................................................................................ 2
1.1. Problem relevance ....................................................................................... 3
1.2. Research questions ...................................................................................... 4
1.3. Thesis outline .............................................................................................. 4
2. Research method................................................................................. 5
3. Literature Review ................................................................................ 9
3.1. General thoughts about frameworks ............................................................... 9
3.2. Characterization of frameworks ....................................................................11
3.3. MVC architecture ........................................................................................12
3.4. Object relational modeling by OOP ................................................................12
4. Description of PHPWebPad ................................................................ 13
4.1. PHP implementation of MVC .........................................................................13
4.2. Abstract design pattern ...............................................................................14
4.3. How it works ..............................................................................................15
4.4. Load by demand .........................................................................................16
4.5. Error handling ............................................................................................16
4.6. Convention over configuration ......................................................................17
5. Scenario-based Evaluation of PHPWebPad ........................................ 18
5.1. Controller ...................................................................................................19
5.2. Action ........................................................................................................21
5.3. View ..........................................................................................................23
5.4. Layout .......................................................................................................23
5.5. Element .....................................................................................................23
5.6. Model ........................................................................................................24
5.7. AJAX .........................................................................................................26
5.8. Object-relational mapping ............................................................................29
5.8.1. Store a user .........................................................................................29
5.8.2. Load all users .......................................................................................29
5.8.3. Load all users with filter .........................................................................30
5.8.4. Update a user .......................................................................................30
5.8.5. Database transaction, rollback, commit ....................................................30
5.9. Special route ..............................................................................................31
5.10. Render action ...........................................................................................31
6. Concluding discussion ....................................................................... 32
6.1. Summary of results .....................................................................................32
1
6.2. Re-visiting the research questions .................................................................33
6.3. Design science artifacts as contributions ........................................................33
6.4. Implication for research and practice .............................................................34
7. References ........................................................................................ 35
8. Appendix ........................................................................................... 36
List of Figures
Figure 1: Hevner's Information Science Research Framework. .............................................................. 5 Figure 2: Use of abstraction of the Controller class. ............................................................................. 14 Figure 3: Sequence diagram of how request works in PHPWebPad ..................................................... 15 Figure 4: Simple login flowchart ........................................................................................................... 18
List of Tables
Table 1: Examples of frameworks in different languages ....................................................................... 2 Table 2: Hevner's Desing Evaluation Methods. ...................................................................................... 7 Table 3: Hevner's Design-Science Research Guideline. ......................................................................... 8 Table 4: List of abstract methods of Controller class. ........................................................................... 19 Table 5: List of methods of controller class. ......................................................................................... 20 Table 6: One abstract method of model class. ....................................................................................... 24 Table 7: PHPWebPad resources ............................................................................................................ 34
2
1. Introduction
Many software developers today are still following the old traditional way of "write your own code"
strategy. This can work well in some cases depending on programmer’s skill and originality in the
field, especially when the application volume is fairly small. So it may seem feasible from a
developer's perspective in terms of his own skill, expertise and originality. But when it comes to
develop large-scale applications on a tight schedule, this may not be the best approach.
Often in a large scale application several developers work together with the same code. Since the
application volume may increase over time more developers may join at different times and in
different faces of the project. So the developers feel the necessity of structuring the program in such a
way so that the application can still be manageable over time. There are other benefits of such
approach which enables developers to work faster since most of the repetitive tasks can be handled. So
this is how the term framework appears that gives opportunities to minimize the development time,
maximize the software delivery and maintain a good structure of the software. It also gives
organization a skeleton to start from and acquire most architectural advantages which can be
understood by the wide range of developers.
A framework emphasizes on the basic notion of "Write less, do more" by reusing the common patterns
of code and structuring the program. So in the long run we get more manageable and structured code
to maintain the software and to add more functionality easily. As a result we see lots of well-
established frameworks for different purposes and different languages. In this research I focus on the
web application frameworks because of the growing needs of worldwide users in web applications. In
Table 1, I mention some of the frameworks those are broadly used in these days for developing web
applications.
Programming Languages Frameworks
PHP Zend, CodeIgniter, CakePHP
C# MVC / MVC2 in Visual Studio ASP.NET [16]
JAVA Struts / Struts 2 [17], Spring, Play
Ruby Rubyonrails [18]
Table 1: Examples of frameworks in different languages
These frameworks abstract are commonly used in software functionality requirements. The good
examples are database connection, CRUD (Create, Retrieve, Update, and Delete) operations, input
validations, error-handling, configuration etc. In every framework most of the repetitive tasks are
easily handled in a way so that developers or programmers can focus more on the business logic of the
application. Also, these frameworks (From Table 1) are designed by following a solid structure of
Object-Oriented techniques and design patterns which ensure that the code are well structured and
confront with a certain level of software standard.
3
1.1. Problem relevance
In the article Object-Oriented Frameworks, Michael Mattsson discusses several advantages and
disadvantages in adopting frameworks [8]. According to Mattsson, frameworks support the
organization to keep knowledge about the application domain because the organization has a design to
start from. These help to minimize the amount of code needed while implementing similar
applications in the domain. These offer not only reusability of design but also code and make the
organization efficient enough to deploy any software which may not be possible to develop within a
normal project budget and schedule [8]. He also states that frameworks help developers to focus more
on area of expertise, and focus less on area of system compatibility.
One realistic problem when using frameworks is that developers or programmers who are just starting-
out will find it difficult to use frameworks as it requires a descent level of understanding of various
Object Oriented Programming (OOP) techniques and principles. But overall, for most developers who
are aiming to deploy more in less time, frameworks are the best choice.
Besides the choice of frameworks the resistance from any development team can be vital. As we study
the successive maturity levels of Capability Maturity Model (CMM) [22] for any organization we see
that the standardization of software development actually affect the process rather than the developers
[4]. But according to a recent CMM maturity profile, almost half of all companies assessed are at
Level-1 [19]. This indicates that there are many immature software organization in which development
is inconsistent and lacks common software development processes (i.e., methodologies are not used)
[4]. So the lack of standardization of development process often becomes a problem due to shortage
and high turnover of developers into these days.
The lack of documentation of any framework may also become a problem since it is crucial to the
framework users. Also the backward compatibility [23] of any framework can be difficult to maintain.
The debugging process may lead to confusion to distinguish bugs in the framework from bugs in the
application code [8].
4
1.2. Research questions
Frameworks are designed to create various advantages in software development. While the term
framework appears to be used widely, the first aim of this thesis is to answer the research questions:
RQ1: How can we understand the concept of framework in software development?
The second research question is phrased with the intention to develop a full functional framework for
web development by using PHP5 programming language.
RQ2: How can we design a web development framework in terms of current design practices,
and principles that can be easily understood by the developers [implemented in software
development]?
1.3. Thesis outline
Chapter one explains how frameworks may become useful for the developers to work with. It also
tries to find out different consequences that developers feel while choosing any framework. Here I also
determine my research questions to focus on overall goal of this thesis. The next chapter explains the
research method of my thesis. Here I mention Information Science (IS) research framework proposed
by Hevner. This thesis aims to Design Science (DS) research within the IS framework. The
overreaching mission is to develop a Model View Controller (MVC) driven web application
framework by following Object Oriented Programming (OOP). Further there are several evaluation
processes take place to examine the project (PHPWebPad) by following Hevner’s Design Evaluation
methods [15]. Chapter three explains the general thoughts and characterization of frameworks that
helps to construct some core concepts about different terms related to framework development.
Chapter four contains the descriptive analysis of the PHPWebPad project. Chapter five is also a part of
descriptive analysis explaining a complete practical example of using PHPWebPad. Chapter six
presents the summary of results, the research contributions and some distinguishing improvements in
the project compare to other web application frameworks.
5
2. Research method
Every design science research offers an extension of the boundaries of human or organizational
capabilities by creating new and innovative artifacts as mentioned by Alan R.Hevner in his article MIS
Quarterly (Design Science in Information Systems Research) [15]. The two basic paradigms in
Information Systems (IS) research as suggested by Hevner are behavioral science and design science.
Behavioral science seeks to explain the world, often through the use of quantitative methods, where
correlations between various variables are tested. Design science, on the other hand, seeks to develop
knowledge to support design. Design science thus seeks to bring changes to the world, rather than just
describe it. Hevner suggests a research framework for IS in order to achieve a good understanding of
and appreciation for design since as an IS research paradigm.
Figure 1: Hevner's Information Science Research Framework.
Hevner explains the relation (See Figure 1) of IS research with the progressive environmental needs
caused by people in one side and advancements of knowledge on the other side by gaining theories,
models, instruments, methods, etc. The two paradigm (Design science research & Behavioral
science research) of IS research is the medium to help constructing business needs identified from the
environment due to strategic, cultural or technological advancements demanded by people and
organizations. The knowledge base on the other hand is the cumulative knowledge that may inform the
design researchers in attempting to solve the problems defined in the relevance cycle. At the end IS
research contributes to the environment by offering new technology, and strategy. It also helps gain
more knowledge through design and evaluation of design science artifacts.
6
This thesis focuses on the design science research. Since the aim of this thesis is to identify the
business needs and offer utility (or design artifact) as design science research is supposed to differ
from behavioral science research according to Hevner [15].
In the first chapter we discuss the background and the problem relevance which reasonably explains
the business needs (see Figure 1) which the developer communities (People) are facing now a day.
The primary concern of this thesis is the design mechanism (Develop / Build) of a web development
framework. In this thesis an MVC driven framework (PHPWebPad) has been developed by using
PHP5 programming language which I also try to evaluate (Justify/Evaluate) by following Hevner’s
design evaluation methods. There are five approaches or methods for evaluation in Design-Science
proposed by Hevner.
Evaluation type Evaluation method Appropriation
Observational Case study. Not in details but there are some
comparisons and discussions about
PHPWebPad with other types of
frameworks.
Field study.
No field study is appropriated since the aim
is to motivate developers towards using
framework. So in that effort I build MVC
driven object oriented framework in PHP5.
Analytical Static analysis which examine
the structure of artifacts for
static quality [15].
See chapter 3.
Architectural analysis. See chapter 3.
Optimization. There are several examples in this project
which shows some optimize solution (i.e.,
Object Relational Mapping (ORM), MVC,
Auto load of classes and models) compare
to other frameworks. This framework is very
lightweight and covers most of the necessary
needs for web development.
Dynamic analysis.
Not appropriated.
Experimental Controlled experiment. There are some control experiments by
which the framework has been tested and
further developed.
Simulation.
The framework is simulated on different
stage in the development of PHPWebPad.
Testing Functional testing or black box
testing.
Done, but in a non-systematic manner. The
expected behavior of the framework has
been tested through the development and
7
execution of example applications, which is
comparable to black box testing.
Structural testing or white box
testing.
Done, but in a non-systematic manner. The
code has been subject to continuous
inspection and re-factoring in a number of
design iterations.
Descriptive Informed arguments. Use
information from the
knowledge base to build a
convincing argument for the
artifact’s utility
See chapter 4.
Scenario. See chapter 5.
Table 2: Hevner's Desing Evaluation Methods.
This thesis aims to conduct several evaluation methods (See Table 2). In the static analysis the aim is
to explain the general proposition of framework design, and emphasize the core concepts about
different terms related to framework development. The architectural analysis gives the basic building
block of design principals and techniques to develop such framework (PHPWebPad). The descriptive
evaluation has been divided into two sections (Informed arguments and Scenario). In case of
informed arguments, the common knowledge, trends, practices and design patterns have been
discussed rigorously. It shows the use of common design principals implemented in this framework
(PHPWebPad). In case of scenario section, a complete example of using PHPWebPad has been
shown.
8
According to Hevner Design-Science Research he also mentions some guidelines in order to conduct
the research.
Guideline Description Appropriation
Design as an Artifact DS (Design Science) must provide a
viable artifact.
This research has led to an
open-source MVC
framework and a straight-
forward mechanism for
automated ORM mapping.
Problem Relevance The objective of DSR (Design Science
Research) is to develop technology
based solution to some real world
problem.
In the introduction section,
we discuss the need for
frameworks to improve
software processes.
Design Evaluation A design artifact must be rigorously
demonstrated via well executed
evaluation methods.
I evaluate the framework
using several methods
proposed within DSR.
Research Contribution Must provide verifiable contribution in
the area of design artifacts.
See Chapter 6.
Research Rigor See Chapter 6.
Design as a Search process See Chapter 6.
Communication of Research See Chapter 6.
Table 3: Hevner's Design-Science Research Guideline.
According to Table 3, all the chapters of this thesis follow these guidelines. This thesis tries to design
artifacts based on current practices, design patterns which can enhance develop applications in object
oriented manner. PHPWebPad has another agenda of motivating the developer’s communities to drive
development in a professional way compare to typical approach where developers write their own
code but doesn’t follow any common architecture or techniques. The relevant problems for trying to
motivate other programmers are also mutually beneficial in order to find out the best and easy
approaches to application development. It tries to strengthen the evaluation processes of the
framework. According to the guideline of Hevner’s Design Science Research (DSR) the main
objective of DSR is to develop technology based solution.
9
3. Literature Review
This chapter focuses on how other scholars have researched regarding the core concepts and their
propositions about framework design. I try to construct some ideas about frameworks and observe the
core concepts regarding framework design. I also find some classification of framework that may help
to imagine other context for using different frameworks for different needs. Further I specially focus
on MVC (Model View Controller) architecture and introduce ORM (Object Relational Modeling) in
this chapter.
3.1. General thoughts about frameworks
Here I focus on the architectural development of any framework researched by others. The
architectural development of any framework is just simply a necessity to make processes reusable,
easily modifiable, and structuring code with acceptable standard. Further framework enforces design
mechanism to handle each developer to convey some important aspects like maintaining interfaces,
avoiding high couplings, etc. Also the design mechanisms won’t provide free room for unintended
problems. At the end framework may ensure more stable applications, fewer bugs, and more
flexibility. A properly designed framework frees developers from figuring out some basic tasks and
promotes creativity for the better use of writing well performing methods, classes, designing
interfaces, processes, etc.
“A framework is a set of common and prefabricated software building blocks that
programmers can use, extend or customize for specific computing solutions. With
frameworks developers do not have to start from scratch each time they write an
application. Frameworks are built from collection of objects so both the design and code of
the framework may be reused.”
Java Framework [1]
A framework tries to hold different building blocks or processes that can be easily used or tailored
according to the nature of the problem. It also motivates to follow a standard to make any process
extendable and reusable. In order to achieve reusability of any process it needs to be less dependent on
other processes. Framework also provides great advantages while starting out any new project since
most of the common tasks can be managed by a framework. In this given proposition of defining a
framework it can be observed that the reusability of processes or components can be used by different
techniques followed by a standard architecture.
“A skeleton of an application into which developers plug in their code and provide most of
the common functionality.”
E. Gamma, "Design Patterns", Addison-Wesley, 1995 [2]
Frameworks provide a skeleton by which the developers can design the interfaces to plug in their code
and use the common functionalities. Since a skeleton is a template or roadmap for developing any
application and the developer’s aim is always to make difference processes reusable. So the developers
10
use their code by setting up some standard parameters and develop a plugin so this can be used in
similar applications.
“An object-oriented framework is a set of collaborating object classes that embody an
abstract design to provide solutions for a family of related problems. The framework
typically consists of a mixture of abstract and concrete classes. The abstract classes usually
reside in the framework, while the concrete classes reside in the application.”
Design Patterns in Object-Oriented Frameworks by Savitha Srinivasan IBM [3]
This definition shows the techniques while developing any framework. The abstract classes are often
used to serve purpose depending on the abstract methods overridden by the extended class. The very
basic concept in object oriented programing is polymorphism which can be achieved by overriding an
abstract class or abstract methods.
Another important aspect of any framework is the simplicity. It allows developer to use different
plugins or components easily. So developers can better concentrate on the business logic rather than
the technical difficulties. Now a day any good framework provides different facilities to let the
developers do something quickly. But it is important how easy it is to use those components and
plugins. The authors of design patterns define application design as bellow.
"If applications are hard to design and toolkits are harder, then frameworks are hardest of
all. A framework designer gambles that one architecture will work for all applications in the
domain. Any substantive change to the framework’s design would reduce its benefits
considerably, since the framework’s main contribution to an application is the architecture
it defines. Therefore it’s imperative to design the framework to be as flexible and extensible
as possible. "
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides [21]
Frameworks provide a basic layout which needs to be very simple and easy to understand to work
with. Because when a design gets harder it leads to a loss of more benefits. So it is very important that
the design has to be more simple and consistent. Actually frameworks make the development easier
while working with complex technologies. It holds a set of objects together into something more
meaningful and useful. It forces any development team to maintain the standard provided by the
framework. Eventually it helps to reduce bugs and bring more consistency. Moreover anyone with a
meaningful expertise can join the team and start working with minimal guidance.
11
3.2. Characterization of frameworks
There are different types of framework that are suitable in different development contexts. Buschmann
[10] classified “architectural frameworks” depending on overall principles for the internal structure of
an object-oriented framework. The described architectural frameworks [10] are:
The Layered architectural framework.
The Pipes and Filters architectural framework
The Model-View-Controller architectural framework
The Presentation-Abstraction-Controller architectural framework
The Reflective architectural framework
The Microkernel architectural framework
The Blackboard architectural framework
The Broker architectural framework structures
Each architectural framework has different meaning of structuring tasks, subtasks or processes in the
application. Layered architectural frameworks classify tasks into different groups of subtasks with
different levels of abstraction. The pipes and filters architectural frameworks classify the tasks into
totally independent subtasks that can be done in parallel or sequential manner. The Model-View-
Controller (MVC) architectural frameworks define a structure for interactive applications that
decouples their user interfaces from their functional core [8]. This thesis pays attention to MVC
frameworks, since they are commonly adopted in modern web development.
Other architectural frameworks like the Presentation-Abstraction-Controller enable multiple controls
and presentations of their abstraction models of the system [8]. The Reflective architectural
frameworks consider future adaptation to the changes of environments, technologies but without
explicit modification [8]. The Microkernel architectural framework provides different views upon their
functionalities which need to be adapted to new system (i.e., operating systems) [8]. The Blackboard
architectural frameworks help to structure complex applications that involve several specialized
subsystems [8]. The Broker architectural framework structures distributed software systems in which
decoupled components interact via remote operation calls in a client-server fashion [8].
12
3.3. MVC architecture
Model-View-Controller (MVC) is considered as a software architectural pattern used in software
engineering. It isolates each layer (Model, View, and Controller) for different purpose permitting
independent development, maintenance and testing. The model layer represents the business logic
which is separated from the user interface (View). The controller layer controls the communication
between the other two layers (Model and View).
The Model is responsible for acting on certain logical conditions or rules by managing data from the
application domain. It takes some information, possibly stores information, gives some new
information and changes its current state according to the instructions given by the Controller. The
View shows the Model’s state in a suitable format so that the users can easily understand.
The Controller maintains the state at any given time. It takes requests, receives inputs from the View
and then responds by calling several Model objects to take care of those inputs or data. By doing so
the Controller gives instruction to the Model and the View to perform actions based on the logical
conclusion of those data.
MVC architectural pattern is now often seen in web applications. In general, views consist of HTML
or XHTML. The controller receives POST/GET/CURL [24] as inputs and determines what to do by
making calls to the Model objects which contains the business rules. Then the Controller renders
Views from the logical conclusion of the Model’s state by using different techniques such as
generating templates, XML pipelining, generating PDF, AJAX callbacks, etc.
3.4. Object relational modeling by OOP
Object oriented programming is now commonly accepted by many programmers. Many programming
languages especially for web application have now reached the level of giving OOP pattern. PHP5,
C#, JAVA all are well matured languages to fulfill the OOP needs of the programmers.
Object relational mapping or object role modeling (ORM) is a powerful software programming
technique or method to query database models at the conceptual level and converts data between
incompatible typed data system to object typed data system. In other words ORM translates the SQL
query data to the conceptual level of object oriented data. So that ORM data models can be easily
understood by object oriented programmers and even by the non-technical users.
13
4. Description of PHPWebPad
In this chapter I focus on the PHPWebPad framework to describe the common terms and practices
which are used. For example how MVC works in this framework and which design patterns is used. I
also discuss about different techniques. For example, load by demand, error handling, and convention
over configuration, etc.
4.1. PHP implementation of MVC
In MVC structure the request URL (that we write in the address bar in any browser) always looks for
any controller class. I.e., if the request is mysite.com/User/Profile/2 then the controller class name is
UserController. Then followed by the controller name, is the action name or function name which is
Profile. So any request can be mapped by a controller class containing a function within that class. In
this case the URL mysite.com/User/Profile/2 has been mapped to a class call UserController which
contains a function which is called profile. The request URL can also have some other information. In
this example, 2 is the value which is passed to the Profile function of the User controller class.
URL: mysite.com/User/Profile/2
Responsible class and function:
public class UserController extends Controller{
public function Profile($id){
/**
* We are here by mapping the url mysite.com/User/Profile/2
*/
}
}
Now a view or output for the request should be rendered back to the user. Each method or function for
the UserController class has a view file. The view file has the same name as the function name. So if
the function name is Profile than the view file name will be profile.php.
Besides the MVC structure developers also need to know how the files and folders are organized in
PHPWebPad. There are three basic folders in PHPWebPad. These folders are Model, View, and
Controller. In the Controller folder all the controller classes are placed. Similarly in the Model folder
all the model classes are placed. And in the View folder all the view files are placed inside the folders
according to the name of the controllers respectively.
14
URL: mysite.com/User/Profile/2
Folder structure:
+ controller
- UserController.php
- model
+ view
+ user
- profile.php
So for the given example the folder structure looks like above. The UserController class is inside the
controller folder. Since the action name is profile, the view file prfile.php is inside the user (since user
is the controller name) folder. And this user folder is inside the view folder. However since there is no
model class, the model folder is empty.
4.2. Abstract design pattern
Abstract design pattern is one of the software engineering techniques to give some beneficiary
behavior for the extended class and also restricting the children to accept the standard implementation
of the abstract methods from the parent class.
Figure 2: Use of abstraction of the Controller class.
In this Figure 2, simple abstraction of a controller class has been explained to handle http requests.
Each Request object is passed through the Router class to verify the http request. If the Request
object is valid then the Router class looks for the Controller class which is abstract. Now this
Controller class knows how to render a view (or give output) for any valid request. But it doesn’t
know which view file to render. However the Router class actually looks for a concrete controller
class that must extend the Controller class. So the concrete controller class (ApplicationController
in this case) feeds the abstract methods of the Controller class. As a result the Controller class knows
which view file to render for any given request.
15
4.3. How it works
In PHPWebPad there are three major classes that take care of all the requests and responses. The
Request class receives the URL and converts it into Request object. The new Request object is then
passed into Router class. Typically, Request object has several properties like controller name, action
name, and so on. So the Router class then determines the validity of the Request object. If the Request
object is valid, then the Router class reads the controller name from that Request object and creates a
new Controller object. Below a simple example that explains how a request and response work in
PHPWebPad.
Figure 3: Sequence diagram of how request works in PHPWebPad
Figure 3 explains the request and response by showing a simple sequence diagram. Let’s consider a
URL as /Application/index. From this URL a new Request object is created by the Request class. The
Request object has several properties like controller_name, action_name, etc. In this case the
controller_name is Application and the action name is index. So this new Request object is now
passed into the Router class. The Router class reads the controller name from the properties of the
Request object and creates a new Controller object (in this case ApplicationController which extends
Controller). This newly created Controller object is passed into the Controller class. The Controller
class is the parent of any controller object. In this case the Controller class is the parent of
ApplicationController. The Controller class is responsible to call the appropriate action and view.
Since the controller object is an instance of ApplicationController then Controller class calls
renderAction method to execute the index method of ApplicationController object. Similarly
Controller class calls the renderView method to execute the view of the index method of
ApplicationController object. This is how the request and response work in PHPWebPad.
16
4.4. Load by demand
PHPWebPad loads only the necessary files. Developers don’t have to include files or packages at the
top of the program or class. The reason is that any required class will be automatically be loaded by
the framework.
<?php
......
/**
* autoload for model classes.
* load by demand
* Since we don’t want to include our model class
* by ourselves. This __autoload($class) function will
* do the magic for us. It will include all the require classes
* automatically.
* @param string $class
* @exception if the class not found.
*/
function __autoload($class){
if(file_exists(ORM.$class.'.php') == true) {
include_once(ORM.$class.'.php');
} else if(file_exists(MODEL.$class.'.php') == true) {
include_once(MODEL.$class.'.php');
} else {
throw new Exception('Class '.$class.' can not be found.');
}
}
......
?>
4.5. Error handling
In this framework the default error handler of php has been modified. PHPWebPad is strict with the
noticeable problems when developers write php scripts. So it will throw exceptions for the noticeable
problems inside the php scripts by the framework even though php error handler ignores those.
<?php
......
/**
* We are strict with the noticeable problems
* inside the script. So we are defining our
* own error handler to throw exception when such
* problems occur.
*/
function error_notice($num, $str, $file, $line) {
echo("$str in $file line $line");
}
set_error_handler("error_notice", E_NOTICE);
......
?>
17
4.6. Convention over configuration
Convention over configuration is a software design technique which helps developers to decrease the
number of decisions they need to make. It brings simplicity but not necessarily losing flexibility.
PHPWebPad has some convention for each type of files in this framework. The benefit is that
developers don’t need to include any class or package at the top of the php script. If all conventions
are maintained by putting classes in the right folders then the framework includes the necessary
classes automatically.
Bellow some lists of conventions are mentioned for different types of files in this framework.
Controller
Any controller must extend the Controller class.
The default controller name is Application.
Allowable name : User, User_settings, Usersettings
Not allowable name: UserSettings, User_Settings, userSettings
The controller name is going to have 'Controller' suffix at the end of its name. So the
controller class name become like these: UserController, User_settingsController
File name: The class name should be the file name. e.g: UserController.php,
User_settingsController.php
File path: /application/controller/UserController.php or
/application/controller/User_settingsController.php, etc.
Action and view
Any action name should be in small letters. The view file names should also be in small
letters.
Default action name is index.
File path: e.g. If your action name is login then the view file should be in
application/view/{controllername}/login.php.
Layout and element
Default layout name is layout. Any layout or element file name should be in small letters.
File path for layout: /application/layout/layout.php.
File path for element: /application/element/{yourpage.php}.
Models
Any model must extend the Model class and implement getTableDefination() method.
Class name and the model name should be the same.
File path: /application/model/{yourmodel.php}.
18
5. Scenario-based Evaluation of
PHPWebPad
In this chapter a complete example of a simple use case scenario has been covered with detail code
and explanation.
Figure 4: Simple login flowchart
This flow chart (Figure 4) explains a simple user login scenario. A User tries to login by sending
his/her username and password. Then next process tries to find the username and password in the
database. If the user is found into the database then the profile page for that user is shown otherwise an
error message is shown. There are seven necessary sections of the PHPWebPad framework; those are
explained as follows by showing the implementation of the example (given in the figure 4).
1. Controller: The aim is to write a controller class based on this example (Section 5.1).
2. Action: The aim is to write the logic for user to login into the system. This section also shows
how to pass values in the view files. E.g. how to send an error message to the view file
(Section 5.2).
3. View: This section shows how to present HTML page in the browser (Section 5.3).
4. Layout: Shows how to construct a page that contains a HTML header, footer, menu, etc.
(Section 5.4).
5. Element: Shows how to use a common HTML code multiple times (Section 5.5).
6. Model: This is the most interesting part of the framework. The model section describes how to
connect and communicate with the database in an object oriented manner (Section 5.6).
7. Ajax: This section shows the advance use of ajax technology in this framework (Section 5.7).
19
Then we also discuss some other sections (Database, Special route, Render action) apart from our
example in order to show some advance use of (Database, Special route, Render action) PHPWebPad.
1. Database: This section shows the advance use of query database in object oriented manner
(Section 5.8).
2. Special route: This is one of the advance sections of the framework which describes how to
rewrite the route for some special request (Section 5.9).
3. Render action: Another advance technique to use a same section of HTML code to be used in
several places with more control. Render action is different than rendering element (See
section 5.10).
5.1. Controller
Any controller must extend the Controller class and implement five abstract methods. Controller is the
main class that controls the communication between the models and the views. We will be doing a
user login application throughout this example (See flow chart in Figure 4). Here I mention all the
necessary methods for any controller class.
Abstract methods Purpose and rational
actions() Returns the allowable actions of this controller.
jsonAtions() Returns the allowable json actions of this
controller.
catchUnallowedActions($actionName) All the unallowable actions requests will call this
function.
beforeRender($actionName) This method will be called before the action
render.
afterRender($actionName) This method will be called after the action
render.
Table 4: List of abstract methods of Controller class.
These methods from Table 4 are all abstract. These abstract methods are very important to get
necessary information from the extended class. Through these methods the abstract controller class
knows all the actions and jsonActions from the extended class. Bellow some other methods of the
abstract Controller class are also mentioned.
Inherited methods Purpose and rational
setLayout() Set the layout file.
setView() Set the view file.
setLayoutVar($name, $value) Set the value for a variable in the layout file.
setViewVar($name, $value) Set the value for a variable in the view file.
20
afterRender($actionName) This method will be called after the action
render.
addLog($msg) Add some log message to the controller.
getLog($msg) Return all the log messages.
renderElement($path, $value) Render an element.
redirectAndExit($path) Redirect to a new URL.
Table 5: List of methods of controller class.
These methods (Table 5) are very useful and essential to work with any controller class. We will see
some of the uses of these methods in the code section while implementing the example (See the flow
chart in Figure 4).
Now we focus on the code by implementing a controller. We name the new controller class as
ApplicationController that extends Controller class. The ApplicationController class has six
methods in which only one method (index) does not belongs to base class Controller. Other five
methods are all extended methods from the base class. Please follow the comments in the code.
Path: application/controller/ApplicationController.php
Controller name: Application
<?php
class ApplicationController extends Controller {
/**
* Start of implementing abstract methods of the controller class
*/
/**
* Return the allowable actions in this controller.
* @return array
*/
public function actions() {
return array('index');
}
/**
* Return the allowable jsonactions in this controller.
* @return array
*/
public function jsonActions() {
return array();
}
/**
* Catch the un-allowed actions for advance use
* @param string $action_name
* @return void
*/
public function catchUnAllowedActions($action_name){
throw new Exception("FATAL: Action $action_name is not allowed.");
}
/**
* This function gets called before the action is rendered.
* Mostly we set the layout file in here.
* @return void
*/
public function beforRender($action_name) {
$this->setLayout('layout');
21
}
/**
* This function gets called after the action is rendered.
* @return void
*/
public function afterRender($action_name) {
}
/**
* End
*/
/**
* The default action is index.
*/
public function index() {
// Logic begins here.
}
}
?>
5.2. Action
In the action we do the logic part. Here we add two more methods login and submitlogin other than
index. The view for login method shows the HTML content of a login form to the user. In case of
submitlogin method we take certain information (username and password) from the request and we
pass that information to the model. Then model checks whether the given information are correct.
Depending on the logical conclusion of the information the submitlogin method decides what view
should be returned to the user. Note that we set the value in the controller (more specifically in
submitlogin method in this case) for the variables that will be used in the view file. In order to pass
information to the view, we use the setViewVar method extended from the base class. Please follow
the comments in the code.
Path: application/controller/ApplicationController.php
Controller name: ApplicationController
<?php
......
public function actions() {
// Allow default actions.
$actions = array('index', 'login', 'submitlogin');
// Check if any user has logged in to the system.
// Only in that case allow loggedin action.
if(User::currentUser()!= null) {
$actions = array_merge($actions, array('loggedin'));
}
return $actions;
}
public function index() {
// Redirecting default action to login action so that we can
// see nice URL in the address bar.
Controller::redirectAndExit('/application/login');
}
22
public function login() {
// Setting a msg variable to show the value in the view file.
$this->setViewVar('msg', 'Please enter your username and password.');
}
public function submitlogin() {
// Using the same view file as login.
$this->setView('login');
// Check if we come from by submitting the login form.
if(!isset($_POST['username']) || !isset($_POST['password'])) {
$this->setViewVar('msg', 'Secure authentication require');
return;
}
$username = $_POST['username'];
$password = $_POST['password'];
if(empty($username) || empty($password)) {
$this->setViewVar('msg', 'Please fill up all the fields.');
return;
}
// We are calling User model to check username and password.
$status = User::tryLogin($username, $password);
if(!$status) {
$this->setViewVar('msg', 'Wrong username or password');
return;
}
// Here we know the user is valid so redirecting to loggedin action.
if(User::currentUser() != null) {
Controller::redirectAndExit('/application/loggedin');
}
// we should not reach to this line. So we are throwing an exception.
throw new Exception('Something went wrong....');
}
public function loggedin() {
// We are sure user is logged in....
}
......
?>
23
5.3. View
In the view file we put all the html contents. Here we are creating a simple login form. The action of
the form is submitlogin which is a method in ApplicationController class. So the action should look
like /application/submitlogin (action name followed by controller name). We also show the message
by $msg variable that we set in our controller.
Path: application/view/application/login.php
<form action="/application/submitlogin" method="post">
<div id="showmsg" style="clear:both;">Message: <?php echo($msg);?></div>
<div style="clear:both;">
<input type="text" name="username">
<input type="password" name="password">
<input type="submit" name="submit" value="submit">
</div>
</form>
5.4. Layout
The layout file is the whole wrapper of the site. We include all the CSS or JAVASCRIPT files in here.
Then we choose where to render our view file. The view file content is stored in a layout variable is
named $__VIEW__. In our current example we have a simple layout file and we echo or print the
variable ($__VIEW__) into our html body tag.
Path: application/layout/layout.php
<html>
<head>
<title>Login example</title>
</head>
<body>
<?php echo($__VIEW__); ?>
</body>
</html>
5.5. Element
Element is a standalone html content to be used, in as many places as we want. For our current
example let’s change something which we have already done. Let’s make the login form as an
element. And then we render the element from our view file.
Path: application/element/form/login.php
<form action="/application/submitlogin" method="post">
<div id="showmsg" style="clear:both;">Message: <?php echo($msg);?></div>
<div style="clear:both;">
<input type="text" name="username">
<input type="password" name="password">
<input type="submit" name="submit" value="submit">
</div>
</form>
24
We can call this element from our login view page. Now we have an element that we can use any
number of times from any view page.
Path: application/view/application/login.php
<?php
// rendering the element and sending the $msg value that the element is
required.
echo Controller::renderElement('form/login', array('msg' => $msg));
?>
5.6. Model
Any model must extend the Model class and implement one abstract method. Model class is
responsible for any communication needed to the database. Every model in this framework is a
standalone model. In our example, we need to create a User model class that extends the Model class.
To be real simple, we have only two columns in our user table and we set the username column as
unique
Inherited methods Purpose and rational
getTableDefinition() return the TableDefinition object
Table 6: One abstract method of model class.
For our current example we have a User class that overrides a method is called getTableDefinition
which returns a TableDefinition object. This TableDefinition object is used by the Model class to
create or alter the table definition inside the database.
The User class has another method tryLogin which we call from our controller class. This tryLogin
method takes username and password as its parameter and check if the username and password can be
found in the database. Please follow the comments in the code.
Path: application/model/User.php
<?php
class User extends Model{
/**
* implementing abstract method getTableDefinition.
* @return TableDefinition
*/
public function getTableDefinition() {
// creating a TableDefinition object.
$table = new TableDefinition('user');
$table->addColumn('username', 'VARCHAR(255)');
$table->addColumn('password', 'VARCHAR(255)');
// setting username as unique
$table->addUniqueKey('my_unique_key', array('username'));
return $table;
}
/**
* Return true if the user exist.
* @param string $username
* @param string $password
25
* @exception if the username or password is empty.
* @return boolean
*/
public static function tryLogin($username = null, $password = null) {
if(empty($username) || empty($password))
throw new Exception('username or password cannot be empty');
// Establishing database connection
$database = Config::getDatabase();
// checking username and password exist or not.
// sql function restrict from the danger of sql injection.
$user = $database->loadOnly('User', sql('username = %s and password =
%s', $username, $password));
if($user) {
// yes we have such user than storing the user object to the session.
$_SESSION['current_user'] = $user;
return true;
}
// otherwise return false.
return false;
}
/**
* Return the current logged in user object.
* @return null | user object
*/
public static function getCurrentUser() {
if(isset($_SESSION['current_user'])) {
return $_SESSION['current_user'];
}
return null;
}
}
?>
26
5.7. AJAX
Modern frameworks for web site development need to support asynchronous server connections that
do not reload the entire page in the web browser. Such actions are typically called Json actions. A Json
action is not the same as a normal action. In a Json action there is no view file to be rendered. Every
Json action returns a JSONResponse object. Let’s change our normal submitlogin action to json
action. Follow the comments of the code. We will be using jQuery [25] post method from the client
side.
Path: application/ApplicationController.php
<?php
......
public function actions() {
// Removing submitlogin action from here.
// $actions = array('index', 'login', 'submitlogin');
$actions = array('index', 'login');
// Check if any user has logged in to the system.
// Only in that case allow loggedin action.
if(User::currentUser()!= null) {
$actions = array_merge($actions, array('loggedin'));
}
return $actions;
}
public function jsonActions() {
// adding submitlogin as jsonaction.
return array('submitlogin');
}
public function index() {
// Redirecting default action to login action so that we can
// see nice url in the url bar.
Controller::redirectAndExit('/application/login');
}
public function login() {
// Setting a msg variable value in the view file.
$this->setViewVar('msg', 'Please enter your username and password.');
}
/**
* The logic of the code is same but we return
* a JSONResponse object.
* @return JSONResponse.
*/
public function submitlogin() {
// We don’t need to set the view file since it’s a json action. And
// json action has no view file.
// $this->setView('login');
$json = new JSONResponse();
// Check if we come from by submitting the login form.
if(!isset($_POST['username']) || !isset($_POST['password'])) {
// Now we don’t set the view variable here.
// $this->setViewVar('msg', 'Secure authentication require');
27
$json->setVar('msg', 'Secure authentication require');
return $json;
}
$username = $_POST['username'];
$password = $_POST['password'];
if(empty($username) || empty($password)) {
$json->setVar('msg', 'Please fill up all the fields.');
return $json;
}
// We are calling User model to check username and password.
$status = User::tryLogin($username, $password);
if(!$status) {
$json->setVar('msg', 'Wrong username or password.');
return $json;
}
// Here we know the user is valid so redirecting to loggedin action.
if(User::currentUser() != null) {
// here we don’t use redirectAndExit method anymore
// Controller::redirectAndExit('/application/loggedin');
// Now we set msg variable as success and we also give the url
// where to redirect. Javascript will recieve this variables and
// redirect the request to our new url.
$json->setVar('msg', 'success');
$json->setVar('url', '/application/loggedin');
return $json;
}
// We should not reach to this line. So we are throwing an exception.
throw new Exception('Something went wrong....');
}
public function loggedin() {
// We are sure user is logged in....
}
......
?>
Now we will make a post request from the client side by using JavaScript. We use JQuery plugin to
write JavaScript in more effective way (further information can be found at the website jquery.com ).
This JQuery plugin has been integrated within the PHPWebPad framework. Please follow the
comments bellow.
Path: web/js/default.js
$(function(){
// when the submit button is clicked.
$("input[name='submit']").click(function () {
// taking the username and password
var name = $("input[name='username']").val();
var pass = $("input[name='password']").val();
// here we are posting the form by jquery post.
$.post('/application/submitlogin', {usernmae: name,
password: pass},function(response){
28
// taking the response string and converting to json object.
var obj = jQuery.parseJSON(response);
if(obj.msg == "success") {
// redirecting the user to the new url that
// we set in submitlogin action.
window.location = obj.url;
} else {
// showing the unsuccessful message to the user.
$('#showmsg').text(obj.msg);
}
});
});
});
29
5.8. Object-relational mapping
The Model class maintains the changes in database (e.g. MySql, MsSql, Oracle, etc) by making
necessary commands and query (DDL, DML) [26] into the database. In order to do this every class
should extend the Model class and override the abstract method (getTableDefinition). No xml or yml
file is required to map any table into the database model class. Let’s consider a user model class
which represents a table that has four columns (name, fullname, city, country).
<?php
class User extends Model {
public function getTableDefinition() {
$table = new TableDefinition('myusers');
$table->addColumn('name', 'VARCHAR(255)');
$table->addColumn('fullname', 'VARCHAR(255)');
$table->addColumn('city', 'VARCHAR(255)');
$table->addColumn('country', 'VARCHAR(255)');
$table->addUniqueKey('my_unique_name', array('name'));
return $table;
}
}
?>
5.8.1. Store a user
<?php
// Store a user.
$user = new User();
$user->name = 'mickel';
$user->fullname = 'mickel anderson';
$user->city = 'stockholm';
$user->country = 'sweden';
// Establishing database connection
$database = Config::getDatabase();
// here we get the id of newly inserted object.
$id = $database->store($user);
?>
5.8.2. Load all users
<?php
// Establishing database connection
$database = Config::getDatabase();
// Load all User.
$userList = $database->loadAll('User');
?>
30
5.8.3. Load all users with filter
<?php
// Establishing database connection
$database = Config::getDatabase();
$userList = $database->loadAll('User', sql('country = %s', 'sweden'),
sql('name'), 1, 20);
?>
5.8.4. Update a user
<?php
// Establishing database connection
$database = Config::getDatabase();
// Update a user model.
$user = $database->loadById('User', 1);
$user->name = 'hafij';
$user->fullname = 'hafijur rahman';
$user->city = 'uppsala';
// it will update this model but since we didn’t change the country,
// the country will remain same.
$database->update($user);
?>
5.8.5. Database transaction, rollback, commit
<?php
......
/**
* Considering a justKidding method in User model class.
*/
public function justKidding($name, $city, $country) {
// Establishing database connection
$database = Config::getDatabase();
// starting the transaction.
$database->startTransaction();
$user = new User();
$user->name = $name;
$user->city = $city;
$user->country = $country;
try {
// storing the object or inserting a row to the user model.
$database->store($user);
// throwing an exception without any reason.
throw new Exception('Just kidding...');
} catch(Exception $e) {
// Here we are; Now we rollback the transaction or remove the entry
// that we just inserted.
$database->rollback();
return;
}
// In reality we must come in here and commit.
$database->commit();
}
......
?>
31
5.9. Special route
All requests must look for a controller file. Sometime we can have a special route. But first the router
will check the available valid controller file to render. If it can't find any valid controller then it will
look for special request. i.g., /user/setting or www.something.com/user/setting. In this example, user is
the controller name and setting is the action. But there are other kind of valid requests which may take
place. The special route can look like /malcom or www.something.com/malcom. Some time we want
to show a nice and user friendly URL to the user. In this case malcom is just a nick name of the user.
So if we want the URL to work, we need to add a special route. The addRoute method takes a regular
expression as its first parameter then the controller name and the action name as its second and third
parameter respectively.
Path: index.php
URL: www.something.com/mickel
Controller name: Application
Action name: user
<?php
......
$router::addRoute('/^\/malcom$/i', 'Application', 'user');
......
?>
5.10. Render action
This is different from rendering an element. In case of rendering action, the action method will be
executed before the view page for that action appears. This is very useful when the partial page may
need lots of data from the action.
<?php
......
$request = new Request("/Application/Menu");
Router::render($request);
......
?>
32
6. Concluding discussion
In this chapter we look at the results that the thesis aims for. We highlight the important points about
the framework and the distinguishing results compare to other frameworks (Section 6.1). We also
discuss about the overall outcome of the research questions (Section 6.2). Then we find out the
contributions of this research as a design science artifact (Section 6.3). There are some short findings
about framework design since very little research has been done in this area. However the contribution
of this thesis may help other researchers who are seeking to work in this domain for developing any
system based on industrial practices.
6.1. Summary of results
In this thesis, a complete framework PHPWebPad has been developed based on OOP. PHPWebPad is
a PHP5 implementation of MVC. Since PHP5 is a scripting language it is often the case that the
developers find difficulties when developing applications in an object-oriented manner. The proposed
framework implements MVC architecture with an intuitive ORM system. It supports the developer
efficiently maintaining the relation between OO (Object Oriented) code and database. The
implemented code examples serve as an experimental evaluation [15] to demonstrate qualities of the
framework. The framework is lightweight and it has a number of characteristics (listed below) to
simplify the works for developers, and to code in an object oriented manner.
1. No auto generated code.
2. No need for XML or YML files to maintain the ORM.
3. Auto creation, modification of the database objects like tables, indexes, triggers.
4. Open source.
5. MVC driven architecture.
6. Object oriented PHP.
7. Custom error handler for noticeable problems in PHP language.
The most noticeable difference in this framework compared to others is the ORM. In typical ORM
there are common approaches for searching, sorting, inserting data. These common approaches are
well-established knowledge based on solid OOP principles. In this regard the ORM in this framework
is similar to others. But in handling table definition in the database this framework differs from other
frameworks. Often when we work with database we need to alter table frequently at some point. We
may add or remove or rename any field or constraint while working with a table in a database. Since a
table reflects a model class it becomes problematic when we alter any table definitions. Since, the
changes need to be reflected in the model class. Most of the ORM we see – for example LINQ to SQL
in LINQ framework, and other frameworks like REDBEAN, ZEND – require developers to configure
XML or YML files in order to maintain the changes we make in the table definitions. In PHPWebPad,
this is managed through the Model class which returns a TableDefinition object (See 5.8 section of the
33
Descriptive Analysis chapter). And the model class itself is responsible to alter the table in the
database. This removes the need to work in separate areas (XML/YML files) and allow the developer
to maintain changes in one place.
Further, PHPWebPad is based upon the ‘convention over configuration’ principle, which reinforces
systematic design and minimizes the need to update configuration files in general.
6.2. Re-visiting the research questions
Based on the discussions from static analysis and architectural analysis (Chapter 3), we discuss on the
basis of several schools of thought in regards to our first research question. The first research question
has been aimed to concentrate on the basic and current trends of thoughts regarding framework in
software development. The concept of framework in software development has always been
researched by the great developers and researchers all the time. These concepts or knowledge are very
essential which has been observed through different scholarly point of view. And it has been explained
in such a way so we may come to know how to design an artifact based on some principals and design
mechanism (design patterns).
This thesis also has been aimed to develop such web application framework that can actually help
developers practically. The aim is to develop such framework that can support current technologies
(e.g. Ajax, ORM), design principles (e.g. MVC), and object oriented programming. Thus the
framework has been evaluated by a subset of Hevner’s design evaluation methods in order to justify
our second research question.
6.3. Design science artifacts as contributions
In design science research, the contributions are typically defined as constructs, methods, models, and
instantiations. There are two types of results in this design science research.
First, the thesis contributes with a conceptualization of MVC architecture (constructs and models).
The notion of architecture in general and MVC architecture in particular, has been defined through
constructs and models.
Second, this work has provided an open source instantiation of an MVC framework (PHPWebPad).
And there are some pedagogical documentation for PHPWebPad that other developers have accessed,
and contributed with their thoughts and comments. PHPWebPad has been released as open source
program under GNU General Public License (GPL). So it is a completely free copyleft license for
general use. Meaning, derived works can only be distributed under the same license terms. All the
source codes are under version control.
34
Subversion access svn co
https://phpwebpad.svn.sourceforge.net/svnroot/phpwebpad
phpwebpad
Download access http://sourceforge.net/projects/phpwebpad/files/
Website http://phpwebpad.hafij.com
Documentation http://phpwebpad.hafij.com
Table 7: PHPWebPad resources
Table 7 shows the detail location to access the PHPWebPad source codes and the necessary resources.
6.4. Implication for research and practice
At this point, it can only be stated that the framework is available and communicated to practice. It is,
however, not enough evidence to determine whether or not the framework will have any significant
implications for practice. However, in accordance with Hevner et al (2004), we have contributed to
practice through this work.
With regard to implications for research, this thesis constitutes an effort to contribute to framework
development using guidelines for design science research (see Table 3). From a design science
research perspective, the research questions and the corresponding answers are contributions to the
knowledge base. The search for relevant literature has shown that there is little research on
architectures, at least in academic journals and conferences. Therefore, I believe that this contribution
(although small) can be important for other researchers seeking to research into this domain.
35
7. References
1. What is a Framework? http://www.jfwk.com/what_is.html.
2. E. Gamma, et al., "Design Patterns", Addison-Wesley, 1995.
3. Savitha Srinivasan IBM, “Design Patterns in Object-Oriented Frameworks”.
4. Cynthia K. Riemenschneider, Bill C. Hardgrave, Member, IEEE Computer Society, and Fred D. Davis. “Explaining Software Developer Acceptance of Methodologies: A Comparison of Five Theoretical Models”.
5. Software framework http://en.wikipedia.org/wiki/Software_framework.
6. Convention over configuration http://en.wikipedia.org/wiki/Convention_over_configuration.
7. E. Gamma R. Helm, R. Johnson, J. Vlissides, “Design Patterns: Abstraction and Reuse of Object-Oriented Design”, Proceedings of the 7th European Conference on Object-Oriented Programming, Kaiserslautern, Germany, 1993.
8. Michael Mattsson, “Object-Oriented Frameworks – A survey of methodological issues”.
9. S. Cotter, M. Potel, “Inside Taligent Technology”, Addison-Wesley, 1995.
10. F. Buschmann, R. Meunier, “A System of Patterns, Proceedings of the First Conference on Pattern Languages and Programming”, Addison-Wesley, 1994.
11. D. Adair, “Building Object-Oriented Frameworks”, AIXpert, February and May 1995.
12. Taligent Inc., “Building Object-Oriented Frameworks”, A Taligent White Paper, 1994.
13. D. A. Wilson, S. D. Wilson, “Writing Frameworks – Capturing Your Expertise About a Problem Domain, Tutorial notes, The 8th Conference on Object-Oriented Programming Systems, Languages and Applications”, Washington, 1993.
14. R.E. Johnson, “How to Design Frameworks”, Tutorial Notes, 8th Conference on Object-Oriented Programming Systems, Languages and Applications , Washington, USA, 1993.
15. Alan R. Hevner, Salvatore T. Mrach, Jinsoo Park, Sudha Ram, “MIS Quarterly”, Design Science in Information Systems Research.
16. B. Evjen, S. Hanselman, and D. Rader. “Professional asp.net 3.5: In c# and vb”, 2008.
17. J. Holmes, “Struts: The complete reference”, 2nd
edition 2006.
18. D. Thomas, D. Heinemeier Hansson, L. Breedt, M. Clark, J. Duncan Davidson, J. Gehtland, and J. Schwarz. “Agile Web Development with Rails”. The Pragmatic Bookshelf, 2nd edition, 2006.
19. “Software Engineering Institute”, Process Maturity Profile of the Software Community 1999 Year End Update, Mar. 2000, http:// www.sei.cmu.edu/sema/pdf/2000mar.pdf.
20. M.C. Paulk, C.V. Weber, S.M. Garcia, M.B. Chrissis, and M. Bush, “Key Practices of the Capability Maturity Model,” Technical Report CMU/SEI-93-TR-25, Version 1.1, Software Eng. Inst., Carnegie Mellon Univ., Feb. 1993.
21. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. “Design patterns, Elements of Reusable Object-Oriented Software”.
22. CMM (Capability Maturity Model): The Software Engineering Institute’s Capability Maturity Model (CMM) explains the importance of methodologies. The CMM measures the effectiveness of an organization’s software development capability by identifying five levels of maturity that lay successive foundations for process improvement.
23. Backward compatibility: Backward compatible refers to a hardware or software system that can successfully use interfaces and data from earlier versions of the system. A new version of a program is said to be backward compatible if it can use files and data created with an older version of the same program.
24. POST/GET/CURL: These are all Http methods with some differences from each other to ask any server for resources. If the resource on the server is found than the server will give back the resource for the request on user’s browser. The resource can be HTML, media, images, etc.
25. jQuery: jQuery is a coding language that is a branch from JavaScript. jQuery help to accomplish a task with less code than what it would take with pure JavaScript code. Please visit jquery.com.
36
26. DDL / DML: DDL (Data Definition Language) are those statements used to define the database structure or schema. E.g. CREATE, ALTER, DROP, TRUNCATE, etc. DML (Data Manipulating Language) are those statements used for managing data within schema objects. E.g. SELECT, INSERT, UPDATE, DELETE, etc.
8. Appendix
Please visit phpwebpad.hafij.com.