Designing framework for web development

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

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

1

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

2

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 startingout 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].

3

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.

4

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.

5

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

Experimental

Testing

Static analysis which examine See chapter 3. the structure of artifacts for static quality [15]. 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.

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.

Functional testing or black box Done, but in a non-systematic manner. The testing. expected behavior of the framework has been tested through the development and 6

execution of example applications, which is comparable to black box testing. Structural testing or white box Done, but in a non-systematic manner. The testing. code has been subject to continuous inspection and re-factoring in a number of design iterations. Descriptive

Informed arguments. Use See chapter 4. information from the knowledge base to build a convincing argument for the artifact’s utility 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.

7

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 This research has led to an viable artifact. open-source MVC framework and a straightforward 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.

Design Evaluation

A design artifact must be rigorously I evaluate the framework demonstrated via well executed using several methods evaluation methods. proposed within DSR.

Research Contribution

Must provide verifiable contribution in See Chapter 6. the area of design artifacts.

In the introduction section, we discuss the need for frameworks to improve software processes.

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.

8

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

9

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.

10

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-ViewController (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].

11

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.

12

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.

13

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.

14

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.

15

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.

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.

16

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

17

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

18

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.

19

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

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

22

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

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 Login example

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

23

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

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

25

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

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

// 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); } }); }); });

28

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

5.8.1. Store a user

5.8.2. Load all users

29

5.8.3. Load all users with filter

5.8.4. Update a user

5.8.5. Database transaction, rollback, commit

30

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

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.

31

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 32

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.

33

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.

34

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

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.

36