On our way to becoming successful developers, we will come across different tools to get the job done. What we learn today will not necessarily be relevant in a couple of years (maybe less). Such is the nature of the beast.

In this changing world, our greatest ability, the one that we must cultivate with greater zeal, is to learn – and UNLearn when necessary -.

Of course, even in this world of rapid change, there are certain things that are more constant.

Let me exemplify the above points.

Take for example the case of frameworks.

A framework is intended to provide the developer with a structure that allows them to write clean code that is easy to scale and maintain. Furthermore, it provides functionality in the form of classes, components, etc; to speed up the work.

Are frameworks absolutely necessary? Of course not. In fact, the creator of PHP himself considers that they are unnecessary and even counterproductive.

Obviously, I disagree, as do many other developers.

I am convinced of the need to use frameworks for different reasons:

If you work on your own, dealing directly with clients for whom applications are developed, the obvious way to maximize profit is to do the greatest amount of work in the least amount of time possible. And in that sense the frameworks as well as the RAD tools are invaluable to generate more income.

If you work as a freelancer, doing outsourced work, you will most likely find that the client already has a product made with some framework; and even if it is a new product, the client will probably have preferences or fixed ideas about the framework to use.

If you work for a company, or aspire to work in one, it is almost unthinkable not knowing how to use one or more frameworks.

You can see that I have used purely economic reasons. This is not because there are not technical ones – there are many – but to be honest, our professional activity must be profitable or we will soon find ourselves doing something else.

However, a “danger”, or in any case a concern, when learning a framework, especially for someone with little experience with the language, is to see any problem only depending on the framework used or preferred.

Example: we have been programming in PHP for a couple of months (or less) and we jump head over heels to learn Yii or Laravel or Cake…. Is there something wrong with this? Not at all. But in this case it is more likely that every time we come across a problem, or a new project, we immediately start thinking about things like “what module can I use for this? Which widget will be the most suitable? Again, is there something wrong with this? Not necessarily, but it seems to me that it can make us lose flexibility, and the lack of flexibility IS something dangerous. A lot.

One way to avoid this is to become as competent as possible in the language. This does not mean that we should memorize the syntax and the name of each function – although knowing as much as possible about it does not hurt – but something more important. THE PRINCIPLES and THE PATTERNS.

By principles, I mean the principles that govern object-oriented programming. Those that make our modeling of the problem domain, in terms of the language, more adequate.

By patterns, I mean design patterns that have proven useful in building higher quality products. One of these principles is the Model View Controller (MVC).

The foregoing, seeks to emphasize the fact that, regardless of whether we choose a framework from the various existing ones, the benefit we can get from them (the possibility of extending them, adapting them for our own purposes, or even using only some of its components in case they offer that possibility) will increase exponentially as our knowledge of the language increases.

And this brings us to our next point.

Let me insist on some reasons why this is a good idea:

We are in a highly competitive environment such as web development. The pace at which new technologies emerge can be overwhelming, and we cannot afford to be left behind.

It is unlikely – I would say impossible – that we will master all the frameworks with which web applications are developed.

An interesting alternative is to stay on top of new trends, and always skilfully manage a set of tools that allow us to carry out our work efficiently.

Today, I would say that, to be a full stack web developer, we must know:

• PHP Frameworks: Laravel, Yii, Zend, Cake, Symfony (There are others, but with these we cover a large part of the demand).
• Version Control: Git with Github or Bitbucket are the standard today.
• JavaScript frameworks: Angular, React.
• HTML5, CSS3, Less
• Databases: MySQL, PostgreSQL, and NoSQL engines like MongoDB

Quite a long list, of course, and even then it’s not exhaustive. Now, with respect to PHP frameworks, beyond the preference that one may have for one or the other, the function of all of them is to facilitate the development process. We want to develop more and better, and in this sense they provide us with extraordinary help.

But, and here is the origin of the need, my concern is that we could end up being absorbed by a framework; that we get to look at EACH project from the perspective of the framework and not from the client’s needs.

In this sense, if when we start to gather requirements for a project, we start thinking things like “ok, which widget will be appropriate for this?” or “hmm, the xyz framework doesn’t allow us to do that”, we’re in trouble.

We must remember that a framework, however good it may be, is built on a language. In this case, PHP. In addition, it uses design patterns that go beyond this language, such is the case of the MVC pattern (Model View Controller).

For this reason, and in order to take advantage of the power that frameworks give us, but understanding the principles on which they are based, we are going to build our own.

NOTE: The framework we are going to build will start very simple and then progress until it is ready for production. It is an exercise in design and programming, but will see it in action building a real project with it. All the code will be on Github, and if anyone wants to get their hands on it and take it further, they are of course more than welcome to do so.

As its name suggests, this book is primarily intended for those who want to understand the MVC pattern, and advanced concepts that every professional developer should know. If that is your case, you can skip chapters 02 and 03 entirely.

However, if you are starting from scratch, chapter 02 gives an introduction to the language, which is enough to build the basis.

Chapter 03 deals with object oriented php, presenting concepts and examples that will help you greatly to understand how the paradigm is used to model the real world and build applications.

If you already have a development environment installed and configured, no matter what it is, then you can skip the corresponding chapters and go directly to the ones where the language is started. Nevertheless, I will show you what my environment looks like.

In order to work through the book, we will need:

• A web server capable of serving php files, such as Apache or IIS.
• A database server, we will be using MySQL for all our examples.
• A text editor or IDE to write the code of our applications.

XAMPP

A good option to configure our development environment is to install an application called xampp.

For those who don’t know, xampp allows us to configure our local machine with Apache, PHP and MySQL; quickly and easily.

In addition, it is available for all major platforms, so we can use it whether our environment is Windows, Linux or Mac.

The installation process is pretty straight forward. At the end you will have the option to start the control panel (Figure 1) right away:

Click on Apache and MySQL will start the web and database servers. Then you can type localhost/phpmyadmin on your browser and you should see the following screen (Figure 2):

IDE

If you already have an IDE or text editor of your choice, you can probably work with it without any problem. However, the examples in this book are made using the IDE Visual Studio Code. It is a free and open source application, and it really is excellent.

Each line of code included in the book has been carefully reviewed. However, errors can occur and in that case I would greatly appreciate being contacted and informed of any problem in order to be able to correct it immediately.

Everyone will benefit from it.

On the other hand, where the code of the example exceeds a few lines of code, in addition to presenting it in the book, I will be providing a corresponding Gist, so that you can refer to that link and copy the code more comfortably if you wish. For those who do not know what a Gist is, it is a way to share files, parts of files and even complete applications. You can find all the relevant information here. Writing the code on your own, following the examples presented, would be an excellent way to gain confidence and get used to the syntax, but you will always have the complete code of the applications to be able to use it.

For any questions regarding this book, as well as for pointing out errors or making suggestions, please send a message to vihugarcia@gmail.com.

I will do my best to answer within 48 hours of receipt.

This chapter had a lot of discussion and not enough action, but we’ll get there. I hope the points exposed served their purpose of presenting the big picture.

In the next chapter we’ll begin with the foundations of the language, covering everything you’ll need to follow along the book.

See you soon!

In this chapter we’ll cover the installations needed to configure our development enviroment, and start learning the language.

I recommend you to try to type the code instead of copying it. It may seem like a waste of time, but it will help you to memorize the syntax and feel comfortable with PHP.

In order to work through the book, we will need:

• A web server capable of serving php files, such as Apache or IIS.
• A database server, we will be using MySQL for all our examples.
• A text editor or IDE to write the code of our applications.

A good option to configure our development environment is to install an application called xampp.

For those who don’t know, xampp allows us to configure our local machine with Apache, PHP and MySQL; quickly and easily.

In addition, it is available for the main platforms, so we can use it whether our environment is Windows, Linux or Mac.

Installing xampp is very straightforward. After finishing the install process, you should be able to start the control panel (Figure 3).

Just press Start next to Apache and MySQL. They are our web server and database server respectively. Now you can open your web browser and type: http://localhost/phpmyadmin. You should see the screen shown in Figure 4.

Note: If you are unable to start Apache and/or MySQL, one possible reason is that the default ports are in use by another application.

In the case of Apache, you can click on Config (Figure 5).

And then httpd.conf. A text file will open, where you can change the port the application is listening to, for example, from 80 to 8080 (Figure 6).

phpMyAdmin

phpMyAdmin is a web application packed into xampp, that allows us to create and manipulate databases in our development environment. It’s very useful, and enough to get started, but with time it can become limited. I strongly recommend using another tool. For example, DBeaver Community Edition is a very powerful tool. You can try it and see if it fits you.

Where to put the exercises

All the code that we want to be interpreted by Apache will go inside the htdocs folder, inside xampp. This represents our document root.

Let’s start by creating a folder named “php-bases” inside htdocs. We’ll be placing all of our scripts there.

If you are on windows, the path should look something like this: C:\xampp\htdocs\php-bases

On the browser, you can access the site by typing http://localhost/php-bases.

You can shorten this by creating a virtualhost for this if you like. Although it’s not mandatory, I’ll show you how you can do it under windows. Remember, these steps consider that you’re using xampp.

You need to go to the folder: C:\xampp\apache\conf\extra

This could be different if you have installed xampp on another path. Inside the extra folder, you will find a file named httpd-vhosts.conf. Open it.

At the bottom of the file, add these lines:

Next, you need to edit your hosts file. It’s located on C:\Windows\System32\drivers\etc

You need to open it with administrator rights. At the end of the file, add the following line: 127.0.0.1 php-bases.test

These will allow you to access the site by typing php-bases.test on the browser. You will need to restart Apache if it’s running.

Now, you can open the folder with your IDE or editor. I’m using Visual Studio Code.

In order to generate dynamic content (ie on demand), the PHP code must be executed on the server; being able to be included or “embedded” within the HTML code; or hosted on the server as a separate file.

In either case, executing the PHP code will produce HTML output, which will be sent from the server to the client. Only the HTML output will be visible to the client, not the PHP code that produced it.

When the code is included within an html page, there must be a way to delimit it. We do it with the following tags:

The closing tag is not mandatory, and in fact not using it can prevent some header issues when using and including multiple files.

Let’s start by creating a folder named basics. Inside that folder, let’s create a file called syntax.php with the following content:

As you can see, this is pure html code. No opening or closing php tags. Let’s add the following line between the body tags:

This will give you the following output (Figure 8):

echo is a function that produces an output. It can take many parameters, although generally you will not use it like that. As you can see, you can produce html tags. In fact, you can write an entire html page using echo, but that’s not the normal way of working with the function. As an example, replace the line with the following:

Note that inside the alert, I’m surrounding the message with backticks. I could have used simple or double quotes, but in that case they should be escaped with a slash . If you refresh the browser, you should see that the button works (Figure 9).

There are basically two types of comments you can use: single line, or multiple line:

Everything between /* and */ will be ignored.

A variable is a symbolic representation of a memory location to which any value or data can be assigned; We can think of a variable as a container for a piece of data or a set of data. During script execution the variable can change both its type and its value. In PHP, the $ character is prefixed to variable names. A valid name must begin with a letter or underscore, followed by any number of letters, numbers, or underscores. Variable names are case sensitive, so $var and $Var will be interpreted as two different variables.

As in any programming language, it is convenient to choose meaningful variable names, which increases the readability of the code.

Create another file called variables.php with the following content:

As you can see, the variables are replaced with the corresponding values. This happens with any variable between double quotes. It’s called expansion of variables. Of course, we can store different types of values in variables, and perform operations with them. Let’s add the following lines to the file.

You’ll see the output shown in Figure 10:

PHP is a loosely typed language.

That means we can do this:

And we’ll get no errors. It also means that in the case of functions, we could potentially pass a value of an incorrect type. We’ll see how to avoid these problems later.

The data types that a variable can store are the following:

• Integer Positive and negative integers
• Float Decimal or floating point numbers
• String Text strings
• Boolean True or False values
• Array Special type of collection of values
• Object Special type of complex data

The size of integers and floats is platform dependent. This means that the number of bits used to store an integer or a float will depend on the machine where the script is executed.

PHP is a language that performs type conversion based on the operands and the operator. To see the type of a variable we can use the gettype($variable) function.

If you still want to force the conversion of a variable to a certain type, you can use the settype($variable, ‘variable type’) function.

The output produced is as follows:

$var has the value 10 and is an integer

Note the backslash in front of the variable, this is to prevent its value from being displayed as is the case with variables inside double quotation marks.

These are data whose values ​​remain constant throughout the execution of the script and that you may want to use a large number of times. They are declared as follows:

The name of a constant follows the same rules as that of a variable, and like variables, it is case sensitive. It does not have a dollar sign in front of it.

An operator receives one or more expressions, and returns a value from them. The precedence of the operators indicates which ones will be applied first, that is, how the expressions will be grouped. For example 2 + 3 * 5 = 17, because the multiplication operator has higher precedence than the addition operator. The following table shows the operators ordered from highest to lowest precedence. Those on the same line have equal precedence.

Associativity means that the expression is evaluated from left to right, right associativity means the opposite.

structures allow us to vary the “flow” of script execution, which would otherwise be sequential; giving it a dynamic that otherwise would not have. In addition, they offer the possibility of repeating a set of actions as many times as desired or necessary.

if

if is a control structure used to make decisions depending on whether a condition (or several) is met or not. Its basic structure is as follows:

Example

Create a filled called if.php with the following content:

The script checks whether the user is using Chrome as a browser or not, and displays a message in each case. Again the $_SERVER superglobal array is used, and within it the ‘HTTP_USER_AGENT’ variable that contains information about the browser of the person accessing the page. Note the use of the function strstr(‘source_string’, ‘string_to_search’), which searches for one character string in another, and returns ‘true’ or ‘false’ according to the search result.

switch

Used to compare an expression with different values. It is similar to multiple if statements one after the other. Its syntax is as follows: switch(expression){ case value1: statement to execute when the expression has value value1; break; case value2: statement to execute when the expression has value value2; break; default: statement to execute when none of the above conditions are met; }

Note that it is necessary to include the break statement after each comparison, otherwise the execution will continue with successive comparisons. It is unnecessary after the default statement.

Example

Save the following as switch.php

The function rand(int min, int max) returns an integer between the indicated limits, including these.

For loop

The for loop is used to repeat the same operation a given number of times. Its syntax is as follows: for(initialization; condition; update){ statement to execute while the condition is true; } Let’s analyze its 3 parts:

Initialization: It is executed only when the loop is started for the first time. In this part, the variable that will count the number of times the loop is repeated is usually placed.

Condition: It is the condition that will be evaluated each time the loop starts. This condition is what determines the length of the loop.

Update: It is used to indicate the changes that we want to execute in the variables each time the loop is executed.

An example of its use would be the following:

In this way I would write all the numbers between 1 and 10.

While loop This loop is used when we want to repeat the execution of some statements an indefinite number of times. Its syntax is as follows: while(condition){ // statements to execute }

To better understand the use of while we will use the following example:

Does the same thing as the for loop in the previous example.

Do…while loop

This loop is used when we don’t know the number of times a loop is going to be executed but what we do know is that at least once the action will be executed.

Its syntax is as follows:

do { // loop statement } while(condition)

break and continue

break

Used to escape the current for, while or switch loop. Accepts an optional parameter that determines how many control structures to escape.

continue

Serves to return to the beginning of the iteration from any part of the loop.

A function is basically a block of code grouped under a name, which can be called as many times as desired, and which usually returns a value as the result of its call. This allows you to reuse code, in an efficient way. Functions can receive values ​​– called parameters – when they are called, and that will intervene in the value that the function returns.

The syntax of a function is as follows:

function name(parameters) { function instructions }

The call to the function has the following form: name(parameters)

Let’s see some examples. Create a folder named functions, at the same level that the basics folder, and inside it add a file may.php

We will create a function that receives two numbers and returns the larger one.

A relevant fact that should be noted is that the variables that we declare within the function will only exist or have that value within the function.

Another thing to take into account, is that right now, if we call the functions with the params: echo greater(2,‘1’);

The script will run without errors, despite one of the parameters being a string.

Most of the time, it’s a good idea to declare the type of parameters that the function expects. Rewrite the function as follows.

This is known as type hinting. We still don’t see any error, but the function can be better documented.

If you want to restrict the values, then we can add this line after the opening php tag:

declare(strict_types = 1);

Now we’ll get an error as shown in Figure 11:

In fact, most of the IDEs should be able to pick this error (Figure 12):

Using strict_types has advantages and disadvantages that we’ll discuss later. For now, we won’t be using strict_types, but we’ll use type hinting.

Besides type hinting, we can declare functions with default values. Create a file called area.php with the following content:

The first call should print 25, and the second 4.

pow is a built-in function. php has over 1000 functions, and that gives it tremendous power. Of course, it’s impossible to know all these functions by heart, but the number of built-in functions normally used is smaller.

In the execution of a script in PHP, on multiple occasions there are variables that have related information. For this, PHP has an element called array.

An array is a set of variables grouped under a single name. Each variable within the array is called an element. Variables of different types can exist within the same array.

It is necessary to differentiate between the two types of existing arrays:

Indexed: The one whose access to the elements is carried out by the position they occupy within the structure (they always start from position 0). Example: $clientes[0]

Associative: It is the one in which the elements are made up of key-value pairs and access is made by providing a specific key. Example: $customers[‘age’]

So, we can now say that superglobals are associative arrays.

There are two ways to create arrays in PHP:

Implicitly, it consists of assigning values ​​to the array indicating the position or key of the element.

Example: $names[0]=‘Javier’;

If you do not indicate a position, the array will take the value following the last value entered.

Example: $names[]=‘Lucas’ /* would take a value of 1 since the last input was 0. */

If $names does not exist, it will be created at the time of the first assignment.

Through array() in which the elements are passed as parameters. In the case of an indexed array, they take the position they occupy in the creation of the array, while those of the associative array are assigned their value by means of “=>”.

Example: $client=array(‘Name’=>‘Juan’,‘Last name’=>‘Perez’);

It should be noted that PHP is not only limited to the existence of arrays but that there are arrays of arrays, or what is the same, multidimensional arrays.

Example: $friends[2][‘Pedro’];

Traversing an array

We have several tools to be able to access the elements of an array

At each moment a reference of the element of the array to which we have access is maintained, therefore, to traverse an array it will suffice to modify said reference. In the case of an indexed array, the traversal will be carried out through a loop and for this we must know the number of total elements that the array has. To do this, we rely on the function count(variable) where “variable” represents the variable from which we want to obtain the number of elements. If “variable” is an array, it returns the number of elements it has, it returns 1 if it only has one element (even if it is not an array) and 0 if it has no value.

Browsing on arrays

When it comes to indexed arrays, navigation is simple since it is only enough to access the element that we want to show, but since it is an associative array, the same treatment cannot be applied. For this, there is a set of prefabricated functions that allow us to carry out a multitude of actions:

Syntax Action

reset(array); The internal pointer returns to the first position

end(array); The internal pointer goes to the last position

next(array); The pointer goes to the next element

prev(array); Access the previous element

current(array); Returns the content of the current element

Insertion of elements

For the insertion of elements inside an array there are a series of functions that allow us to add elements. Among them we highlight:

array_push(matrix,variable1,variableN);

Add elements to the end of the array, and its length is increased by as many elements as have been added. Returns the number of elements in the array.

array_unshift(array,variable1,variableN);

It introduces elements at the beginning of the matrix, displacing the other as many positions as there are elements. Returns the number of elements in the array. array_pad(array,new_size,pad_value);

Fills the array using a supplied value, according to the specified size.

Elimination of elements

array_shift(array);

Removes the first element of the array

array_pop(array);

Removes the last element of the array

array_splice(input,ini_pos,[size],[substitutes]);

It is used to replace or delete the content of an array portion, for this we must specify the position from which we want to start the deletion or replacement, the size or number of elements that will be affected and the substitutes (in case we want to replace it with some item).

array_keys(array,[lookup value]); It is used when we want to eliminate an element whose position we do not know.

array_values(array);

Returns an indexed array with all the values ​​stored in the array passed as a parameter.

Mass manipulation of arrays

array_walk(array, function_name, parameter_list);

It is used to apply the same function to all elements of an array.

Obtaining sub-arrays

array_slice(array,position,size);

Allows to extract a sequence of elements from an array. The parameters to be passed are the matrix from which we want to extract these elements, the position from which the extraction starts and the size of the extraction (positions that we cover from the initial one).

Array Sorting

Other functions

In this section a series of functions are discussed (not all of them because it would be impossible) that can be useful at a certain moment .

compact() Returns an associative array from an indeterminate number of parameters

extract() Creates variables from associative array

array_unique() Returns array without repeated data as some are removed

array_reverse() Returns array with same elements but in reverse order

shuffle( ) Modifies the order of elements randomly

array_count_values() Returns an associative array containing repetition frequencies of the values ​​of the array

in_array() Allows checking if a value is in the array

array_merge() Combines elements of two arrays into 1.

Forms are not part of PHP, but of the HTML language. However, since in most cases our scripts will process data coming from forms, we will dedicate a few lines to the HTML code linked to them.

Every form begins with the tag. With ACTION we indicate the script that is going to process the information that we collect in the form, while METHOD tells us if the user of the form is going to send data through POST (post) or GET (get).

The difference between these two methods lies in the way of sending the data to the page, while the GET method sends the data using the URL, the POST method sends it through the STDIO standard input (POST is therefore safer than GET). Another difference is the size limit. In the case of $_GET is browser dependent, with some of them allowing up until 2000.

The tag indicates the end of the form.

From the tag come the data input fields that can be:

Text box:

Text box with bars scroll:

Checkbox:

button:

Dropdown menu:

Command button:

Hidden field:

This last type of field is especially useful when we want to pass hidden data in a form.

As you may have noticed, all field types have a modifier called name, which is none other than the name of the variable with which the data will be collected in the script indicated by the ACTION modifier of the FORM tag. With value a default value is established.

Next we will see an example.

Create a folder named forms at the same level as the basics and functions folders. Then add a file named forms01.php with this content:

Pay attention to the following line:

$_SERVER is a predefined superglobal variable, containing information about the server where the script is running. To use <?= is equivalent to <?php echo, just a little bit shorter. $_SERVER[‘PHP_SELF’] refers to the current script. So, we are sending the data to the same file.

The condition:

if ($_SERVER[‘REQUEST_METHOD’] == “POST”) { … }

Guarantees that the code executes only when there is data sent.

Next, we have:

if (isset($_POST[“name”]) && trim($_POST[“name”]) != ““) { … }

isset checks if a variable is set, in this case, checks if the superglobal $_POST (which is an array), has a key named “name”. This is because we have an input text whose name is, precisely, “name”.

trim will remove any leading or trailing space.

So, we check if the variable is present and is not empty, and in that case, we print it.

We are ready for a more complex example.

Create a file called forms02.php with the following content:

Most applications that we’ll be working on will interact with some type of persistent storage. One of the most common forms of storing data is a database. There are different types of databases. For all the examples we’ll use MariaDB. MariaDB is a project from the same creator of MySQL. MySQL use to come in the xampp package, but since it was acquired by Oracle the Apache org has replaced it with MariaDB. Fortunately, it is fully compatible.

Let’s open phpMyAdmin typing http://localhost/phpmyadmin on the browser.

Clicking the tab Databases we will see the following screen (Figure 13):

Type “test” as the name of the database and click the Create button.

The next step we’ll be to create a table. We can do it from the following screen (Figure 14):

Type “clients” as the table name, leave the number of columns as 4, and press Go. Complete the form as follows (Figure 15):

Then press Save.

We are ready to work.

PHP has different libraries to work with databases. We will be using PDO. PDO is an extension to interact with relational databases. We can establish a connection with a database server, create tables, read and write values in tables, and many others tasks.

Create a folder named databases at the same level as the others.

The add a file called name config.php with the following content:

These variables contain the data necessary to connect with the server and manipulate the database.

Now add a file called connection.php with the following content:

This function uses a try catch block. If the connection can not be set, then the catch block we’ll catch the exception. We display a custom error in that case.

We create an object (we have a complete chapter on oop) of class php. We set the attribute to handle errors, and return the object.

Now we’ll set up a file to handle common functions like insert, update, delete and list data.

Add a file called db.php:

Let’s see what this function does. There are two ways we can present an insert statement.

One is:

INSERT INTO table_name (column1, column2, column3,…) VALUES (value1, value2, value3,…)

The other one is:

INSERT INTO table_name SET column1 = value1, column2 = value2, …

We use this second form in the function. In the first sentence we initialize the sentence. Then, we use a foreach loop to extract the key and values of the associative array that we’ll pass to the function to perform the insert. That means an array like this:

[“first_name” => “Peter”, “last_name” => “Parker”, “email” => “test@test.com”]

Note that in the foreach loop:

We wrap the values with single quotes. That is necessary for the insert sentence to work. Also, it should be noted that this loop leaves the query with a trailing comma. Now, the rtrim function is normally used to remove unwanted blanks from the right left of a string. But, if we pass it a second parameter, the function will search and remove that character from the right.

Finally, we prepare and execute the sentence. To prepare the sentence, allows us to prevent sql injections attacks, and also, prepared sentences will run faster the second time they are cold, thanks to the cache.

Now, is time to write the function to update data:

As you can see, it looks very similar to the previous function. When something like this happens, it is a sign that we need to refactor the code. But first let’s see the difference.

This sentence:

Is necessary to indicate what record should be updated in the database. You may have noted the use of :value.

It’s not a variable (there is no $ sign). This means that “value” will be assigned a value after it has been sanitized.

It’s what we accomplish with:

Now, as we mentioned before, we can refactor the code.

Add the following function:

We can use this function as a replacement for the other two. However, instead of deleting them, we can rewrite them like this:

Now we can put our little library to test. Add a file called test.php with the following content:

If we run the script in the browser, we should see the message “Data inserted” displayed.

We can see that the data has been inserted in the “clients” table (Figure 16):

Our next step is to be able to read the data. Add the following function to db.php:

We receive the connection, the table from which to fetch the data, and optionally an array with the fields that we want to retrieve. It’s not common and is not even recommended to retrieve all the fields from a table, for performance and security, but we can do it if we want.

Now is time to put our function to test. Add a file called read.php with this content:

If we run the script, we should get this output (Figure 17):

We are merely printing the two dimensional array with the results, but just as easily we could show an html table, encode the data as json, and so one. This is not the responsibility of the function. We could have another file with utilities, and different formatting functions in it.

Now, in most cases we’ll want to retrieve one record in particular. Let’s write the appropriate function.

It’s very similar to the previous function, but we are returning just one record. The supposition here is that “key” represents a field with a unique value for the table. Now add these lines to the read.php file:

The output should be like this (Figure 18):

It may not seem like much, but we have accomplished a great deal. We can read, insert and update data. The last piece is a function to delete data:

Now you can play around with these functions. Try to insert, update, read and delete data. There is no other way to improve than to practice.

In this chapter we’ve covered the installations needed to configure our development enviroment, and started learning the language.

The next chapter will deal with object oriented programming (OOP). It is a tremendously popular paradigm, and rightfully so, and is a requisite if you want a job as a developer. We’ll go step by step until you feel comfortable with it. See you soon.

Object oriented programming is a paradigm that has been tried and proved for years. If we want to make a living as professional php developers then there is zero chance that you won’t be using it.

So, what is it exactly?

In the procedural paradigm, we write functions to accomplish our goals. Functions receive parameters and execute (ideally) one specific task. Functions perform operations on data.

In order to use a particular function, we need to include the file containing that function. That means that we can encounter clashes if we include two files containing functions with the same name. This is because functions reside in the global scope.

Object-oriented programming groups functions and data in a single entity, that represents an aspect of the problem. In this form, we can organize our code more efficiently, and with less repetition.

The entities are called objects, and are abstractions of the real world. We build those objects (instantiate them) from a blueprint. This blueprint is called a class.

The code inside a class is hidden from the global scope; that is, the code is encapsulated in the class scope. We access this code instantiating the object.

We’ll see some examples.

Create a folder called “oop” at the same level of the databases folder.

Let’s say we are working on a simple blogging system. We can identify that our blog we’ll have at the very least users, posts and comments.

Create a folder called “blog” inside the oop folder. Add a file called User.php

We can write the class user like this:

$first_name, $last_name and $email are attributes of the class User, known as properties. They are declared public. “public” is an access modifier. Access modifiers are used to determine if we can access the property or function from outside the class. Normally we won’t be having many public properties, but we leave it like this for now.

Then we have a function called __construct. Functions inside classes are called methods. The constructor method is a special method that is executed automatically when an object is instantiated.

In the constructor, you can see the keyword $this. Let’s talk about it.

$this represents the current object of the class. The $this keyword allows access to properties and objects of the current object of the class using the operator ->

So, in the example, to reference the “first_name” property we use $this->first_name.

Now we’ll add a new class representing the posts.

And the comments:

Let’s put these classes to test adding a file called blog.php:

You can see that we use a foreach loop to go through the different posts of the array. We need to display the title and the text, so we reference this as $post->title and $post->text.

Internally, the class sees these sentences as $this->title and $this->text. The interpreter knows who the current object is, so we display the appropriate property values for each object.

We get the following output (Figure 19):

Not very impressive, I know, but we are integrating concepts to build increasingly larger applications.

At the moment, we can change properties values from outside the object. For example we could write something like this:

We don’t normally want this, because that means we are exposing the system to uncontrolled changes outside the class. We should have very good reasons to leave the properties as public. And that brings us to the next subject.

Access modifiers determine from where we can access the properties or methods of a class. We have 3 access modifiers:

public: We already saw these in action. We can access public properties and methods from outside the class.

protected: A property or method declared as protected can be accessed from inside the class and derived classes. We’ll see examples when we talk about inheritance.

private: This is the most restrictive of all. Properties and methods declared as private can be accessed only from within the class.

Going back to our Post class, let’s change the “title” and “text” properties from public to private:

Now if we run blog.php we get an error (Figure 20):

This is because private properties can not be accessed from outside the class. So, how can we access this property?

We can use setters and getters to change and obtain the value of a private property. Add the following two methods to the Post class:

With these two methods, we have access to the “title” property. Now add other two methods to deal with the text property:

Now, we need to make a change to our blog.php script. Change these lines:

Now the error should go away.

You may be wondering why to use setters and getters if that makes our code longer. Well, one of the purposes of the oop paradigm is to provide encapsulation, and public properties go against it. Ahoner reason is that we can enforce checks on validations on the setters, maintaining data consistency. As an example, change the setTitle method as follows:

Now, in the blog.php script add these lines after the foreach loop:

If you run the script, you should see the title being cut.

If you are curious, the wordwrap wraps a string to a given number of characters using a string break character, this character defaults to newline “\n”.

Then with substring we take the firstline.

Magic methods are special methods in a class that override the normal behavior. The names of these methods start with a double underscore. We already saw one of them in action, the __construct method, used for initialization.

The constructor has its counterpart, the destructor. You can use the destructor to do some clean up, for example, closing a file:

Another magic method is __get, which is invoked when writing a value to a non-existing or inaccessible property.

We can use this method, for example, to shorten our class definition if we don’t need any checking to read a private property. Remove the setters from the Post class, and add this method:

The magic method we’ll search for a getter. For example, if it receives the parameter “title” we’ll search for a method called getTitle. If the method exists then it returns it. If there is not method, then it returns the property indicated by the parameter “name”.

Note that in the final line we write $this->$name and not $this->name. This is because $name will hold the name of whatever method or property we are requesting. But if we write $this->name then we are looking for a property called “name”.

Just to be sure, this is the complete code of the Post class:

We are now ready to build something a little more complicated. In many applications, there is the need for an upload file functionality. We could follow a procedural approach, but this is the kind of functionality that is perfect to be encapsulated. Think of a set of reusable classes that you can bring to a new project, that you can use without worrying about function names clashing.

Add a folder called uploader inside the oop folder. Then add a file called FileUploader.php. We start with this content:

We have the class definition, with four private properties. One to hold the filename, that is, the value of the “name” attribute of an input of type file in a form; and the folder to which the image should be uploaded. The targetFile represents the full path to the uploaded file. Finally, a property to hold and display any possible errors. The constructor deals with the initialization of these properties. Note the use of the globarl constant DIRECTORY_SEPARATOR. This constant represents whatever character the operating system of the server uses as the separator for directories in a path, that is “/” or “\”.

After the constructor, add the following method:

This method will check if the file is indeed an image, using the function getimagesize. This function will return false on any file that is not an image. We could have used a single line:

But we want to save an error message. Then let’s add a function to allow only some types of images:

For this example, we will only allow jpg, jpeg or png images. This could be a place to future improvement, for example this could be the default values, and allow for the user to define the desired types in the constructor.

On to the next method.

We use this method to check if the file already exists. Again, we could set the value of a property to indicate if we want to override the file, but this is enough for now.

Until now, with the exception of the constructor, all methods are declared as private. Our last method is a public one, and is in fact the responsible for the upload of the file:

That’s it, it’s a very simple class, but a very useful one. Now we’ll put it to the test.

Inside the “uploader” folder, add a file called form.php

Now add a folder called “uploads” at the root of the site, at the same level of the oop folder (Figure 21).

Just to be sure, here are the gists to the FileUploader and the Form

Go ahead and try the form. You should see the file uploaded to the “uploads” folder.

I hope you can see how a class like this can be useful, favoring code reuse and maintainability.

Inheritance is one of the most useful characteristics of a language. It can be defined as the process of deriving classes from other classes, creating a hierarchy. We indicate that one class is derived from another using the keyword extends.

Going back to our blog example, it is reasonable to conclude that our classes will have to interact with some kind of permanent storage. So, it will be a good practice to create a base class to handle all the basic crud (create, read, update, delete) operations. Add a class called Model.php in the blog folder:

If we make our Post and Comments classes extend from this base class, then they will inherit these methods. Let’s change our Post class:

We can make some tests to see everything in action. Add a file called test.php at the same level as the blog.php script:

Now we can see that, because the Post class extends from the Model class, we can use the all method (Figure 22).

Interfaces allow you to specify what methods a class should implement. You can think about interfaces as contracts. If a class implements an interface, or a group of interfaces, then it is mandatory for that class to implement all the methods that are declared on those interfaces. Now, why is this useful?

Think about a big codebase. Normally, there will be a group of people working on it. One of the aspects that need to be carefully planned is the architectural one. Whether the title is “software architect” or something else, there should be someone in charge to define the bigger picture. Interfaces can be used to outline what the principal classes of the application should look like. Interfaces enforce a clear design, leaving the implementation to other members of the team and at the same time maintaining consistency. This is sometimes called “programming to the interface”.

We’ll build a db class, the object oriented equivalent to the functions that we used in the passed chapter to interact with a database. This class will adhere to an interface, so we’ll start with it. In the oop folder, add a directory called db. Then add a file called IDatabase.php

As you can see, we use the keyword interface. Also, the methods are only declared, not implemented. We don’t even have the curly braces for them. This interface is a contract. Every class implementing it must implement the corresponding methods or an error will be thrown.

Now add a file called PDOConnect.php

The code should look very familiar. In the constructor we initialize the $conn property as a new PDO object, which represents the connection to the database. When we need that connection, we call the method getConnection (a simple getter) to retrieve it.

Then we have methods that are very similar to the functions that we presented in the previous chapter to manage database operations.

We have made a lot of progress. We have an understanding of what classes are, and how they are declared and used. The examples presented try to reflect real world problems, and with that goal in mind, we have to look further and realize that projects tend to grow in complexity. As such, we need to organize our code better. This is of paramount importance in a project with a whole team working on it.

Just think about this situation. You have classes dealing with html tables, such as Table, Row and Col. At the same time, you have another set of classes dealing with Excel files with similar names: Table, Row and Col.

This is known as name colitions. We use identifiers to deal with this problem. A namespace groups a set of related classes. It’s very similar to how directories work. Different directories group files. The name of the files need to be different inside a directory, but different directories can have files with the same name. We’ll be expanding in our blog example to see these concepts.

First create a new folder named blog inside the htdocs folder.

Inside that folder, we’ll be adding four directories to organize the code: application, config, library and public.

Add a file named config.php with the following code:

This file has the connection parameters to a database that doesn’t exist yet, but we’ll create it later.

Inside the library folder, add a file named bootstrap.php with the following content:

It doesn’t do much yet, but it will later.

The the public folder will have an index.php file with the following content:

We define two constants and require the bootstrap.php file that we already saw, and another file named index.php, which is in the application -> views folder.

Put the followings content in that file:

Let’s see what we have until now. We’ll be adding a virtual host in our httpd-vhosts.conf, which is located in C:\xampp\apache\conf\extra. This is not mandatory, but is convenient.

The lines to add are:

As before, we also need a line in our hosts file:

If we go to the browser and type blog.test we should see the following (Figure 23):

Now, add a folder named core inside the library folder. To be sure, the folder structure should look like the following (Figure 24):

Now, copy the file Model.php from the Inheritance section inside the core folder. The file as of now has the following content:

Now, we need to add just one line before the definition of the class:

We are using a namespace to group a set of classes. In this case, all the classes that are part of the library, will have the namespace core to differentiate them from the application classes. We will never modifying the classes in the core space. Instead, we should extend from the core classes.

This allows reuse of the structure. The classes that are particular to the application we are building we’ll be in the application folder.

In the application folder, add another named models. We can reuse the Comment, Post and User classes from the previous sections (the ones in php-bases->oop->blog). Just copy these models and paste them in the models directory.

The Post.php file right now has the following contents:

Now, we have a require_once line, since the class Post extends the model class. We need to change the path, since the two classes are no longer in the same folder.

But using require_once statements to include the necessary files. For example, the file with the PDOConnect class requires the IDatabase interface, because it implements it. If we are dealing with a big codebase, it can be very problematic to manually require all the files needed, and it can lead to problems if we forget to require one of those files. A mechanism often used is something called autoloading.

Autoloading of classes is a mechanism to automatically include or require the files containing classes that are referenced in the code. There are different options to attain it. We’ll be writing our own autoloading.

Remove the require_once line on the Post.php file, and then add these lines right after the php tag.

The first line defines the Post class as belonging to the models namespace. Then we have the use sentence. Why? The Model class belongs to the core namespace. So, we are defining an alias to use as a shortcut. It is important to note that we are NOT including or requiring the file, that will be the purpose of the autoloader. We are simply establishing the instead of the fully qualified name core\Model, we’ll refer to the class simple as Model. The use sentence is also useful when we need classes with the same Name, but belonging to different namespaces. For example we could use something like this:

Let’s take a test. Modify the index.php file in the views folder as follows:

We get an error in the browser, and it is expected because we are not including or requiring the files.

We have a bootstrap.php file that doesn’t do much. In fact, it only has one line. Modify it as follows:

spl_autoload_register allows you to register autoloaders. It receives the name of a function as a parameter.

Our autoload function defines the directories in which the files containing the classes are located. When a class is referenced in the code, it searches in all the directories listed and requires the corresponding file if it exists.

As you can see, we follow the convention that a class named Post is defined in a file named Post.php.

With those changes, we finally have the output shown in Figure 25:

This is not the only method to achieve autoloading. Most frameworks use Composer, and we’ll see examples later on. But for now, we have everything we need in order to begin building our mvc framework.

Navigating the Internet, a simple search like “create MVC framework” yields thousands of results, not all of the same quality.

A very interesting article can be found here. However, these articles were written in 2009, and thus lack important features such as the use of namespaces, use of composer for autoloading, dependency injection, and so on.

In addition, it contains other problems typical of the years that have passed. Therefore, in many important respects, we will make fundamental changes.

First of all, we need to create a directory for our web server. We can call it anything. Throughout this entry we will consider that directory to have been called simplemvc.

Within it, we must create the following directory structure (Figure 26):

Let’s briefly analyze each directory:

application: contains the code of the application that we are developing. Here we can see directories called controllers, models and views. Each controller, model, and view in this directory is specific to the particular project, and will extend a framework class that provides basic functionality. config: contains files with configuration data, such as environment constants, or connection to the database. library: contains the framework’s own files. Within this directory we see two others: core and widgets. Within the first we will place the fundamental classes of the framework, and within the second some utility classes, such as widgets for creating tables, and others. public: This directory is meant to be the application’s entry point directory. It is the one that is accessible to the public. tmp: Contains temporary files such as cache files, errors, and session information.

Let’s create a file called .htaccess (this is a special file used for configuration directives) and place it in the root of our project. That is, we will have a file called .htaccess at the same height as the directories mentioned above.

This file will be in charge of configuring our server to direct all requests to the public. The contents of the file are as follows:

NOTE: This is considered to be dealing with an Apache server. In case of using another environment, such as an IIS server, or Nginx, the necessary configuration must be carried out for each of them.

Inside the public directory, let’s add the following content to the .htaccess file:

With it we are instructing our server to direct all requests (with the exception of files and directories) to a single entry point, the index.php file.

This file will receive as a url parameter, a route in the form controller/action. For example, if we write localhost/simplemvc/items/index, index.php will receive the value in the url variable ‘items/index’.

This file is very simple and has the following content:

The first two lines define two constants:

DS: This constant will refer to the directory separator, which can vary from one operating system to another. For example, it will take the value “\” or “/”. ROOT: It will refer to the root of the site. To do this, it uses the dirname function, which returns the parent directory of the route passed as a parameter. FILE is a PHP magic constant that represents the full path of the current file. Therefore, by using dirname(dirname(FILE)) we are moving up two levels from the location of the index.php file, effectively referencing the root of the application.

In the next line, we are creating a default route in case none is requested. All routes in our application will have the form (assuming we are in our local environment).

localhost/simplemvc/controller/action

If the controller/action is not indicated, the ‘site/index’ will be called by default, that is, the site controller and within it the index action.

In the next line we save the url (controller/action) received.

Finally, we include the bootstrap.php file located in the library directory.

Let’s add the following code to bootstrap.php:

This file is a bit longer, and more complex. It starts by defining a function called autoload.

This function will be in charge of automatically loading the necessary classes to start our application.

What does that mean?

Well, suppose we have an application where we define classes A, B and C. Each of them is defined in their respective files: A.php, B.php and C.php.

In each file of our application where we want to use these classes, we must include the necessary files, for example:

require_once(‘library/A.php’); require_once(‘library/B.php’);

As the number of classes increases, we can easily forget one of these statements.

One approach to avoid this problem is to take advantage of a php feature known as ‘autoloading’.

PHP defines a default function called __autoload, which we can override to perform class loading. That is, if we implement an __autoload function, PHP will try to use this function to load undeclared classes.

However, according to the PHP documentation, the __autoload function has limitations that make it deprecated and may be removed in the future. One of these limitations is that __autoload only allows you to implement a single autoloader.

Alternatively – and this is the option we have chosen – we can write our own function (named whatever we want) and register it as an autoloader using the spl_autoload_register function.

Our function is called autoload. (Note the difference with the function name __autoload).

Our autoload function receives a $class parameter, which contains the name of a class that we intend to use in the code. Inside this function, we define an array that references a set of directories where we’ll look for the necessary classes:

Next, we loop through this array with a foreach.

In this foreach we have the following line:

This line creates the path to the file where the referenced class is located.

For example, if we later write: $app = new Core\Application , the autoload function will receive as a parameter: ‘core\Application’.

From it, the variable $file will end up containing (in the case of my environment) the string: C:\xampp\htdocs\simplemvc\library\core/Application.php

Then, if the file exists, it will be included with require_once($file).

Now, for the autoload function to be called every time a class is referenced, it must be registered as an autoloader. We do this with the statement:

spl_autoload_register(‘autoload’);

Following that statement, we include the configuration file ‘config.php’.

This file, located in the config, contains the following:

A constant is defined that indicates that we are in the development phase, and then a constant, an array, with the data necessary for the connection with the database.

After that, we have a constant that points to the web root of our application. This is necessary if we have our app in another folder different from our root.

Finally, we have a constant to identify our session. We will use this when we are dealing with authentication or authorization. For now, I will just simply use a random string of 20 characters. Later, we’ll employ a method to ensure every session is unique.

Back in the bootstrap.php file, the last few lines are:

These are the ones in charge of instantiating an Application object, and calling the necessary methods to start our application.

At this point I think it’s necessary to explain what we are trying to achieve. I would not dare to advise someone to start using a professional framework such as Yii, Laravel, Zend and others, without having a solid foundation of the language.

Why? Because if you don’t have this foundation, the framework ends up becoming the language. We begin to think of EVERYTHING from the perspective of the particular framework that we use.

What does solid foundation mean?

Let’s see:

• Variables
• Constants
• Data types
• Control structures
• String manipulation functions (very important)
• Arrays (very important!)
• Form processing
• File upload and manipulation
• Sessions and cookies
• Databases
• Manipulation de xml
• Ajax

Sounds like a lot, but it’s not only necessary, it’s worth it. There are many resources online to achieve this learning. For example, the w3schools tutorial covers these and other points.

Once mastered, it is a good idea to return to these references and practice exercises from time to time to “keep in shape”.

After the basics, it is very important that we learn as much as possible about object-oriented programming. Classes, objects, namespaces, inheritance, interfaces, polymorphism, magic methods, traits, etc., must be part of our daily language.

Finally (yes, there is still more…but it is really the last thing) to take our skills to a new level, we must know and know how to apply DESIGN PATTERNS.

I highlight it, because design patterns allow building scalable and maintainable applications, two characteristics that facilitate the work of all project participants.

One of these design patterns is precisely the MVC pattern (Model, View, Controller) that we have talked about on several occasions.

As we already know, the MVC pattern seeks to separate the functionality of our application into three different components.

The model, in charge of implementing the business logic. It is in charge of reading and writing data to persistent storage.

The view, responsible for presenting the data to the user.

And the controller, in charge of delegating responsibilities to the model and the view in response to a user request.

Most frameworks use this pattern, but it’s important to know that they might not. Things could be done differently.

Another design pattern is called the Front Controller.

This design pattern consists of providing a single entry point to our application. That is, all the requests that arrive at the browser are directed to a single place from which they are derived to the appropriate component to handle them.

I think it is very important to point out that the MVC and the Front Controller are two different patterns that can be implemented independently.

It just so happens that they are frequently used together.

Again, most MVC frameworks, including Yii and Laravel, also use the Front Controller.

To clarify some doubts, let’s see the following graph (Figure 27):

Here we see a diagram that represents the cycle of a request in a framework that uses the Front Controller and MVC patterns. The business logic is represented by the Model.

However, if we were to refer to the Front Controller alone, we could render it like this (Figure 28):

Sorry for the long exposition, I hope I haven’t lost you guys yet. What I wanted to make clear is that design patterns are fundamental tools, and knowing them allows us to be better at our work.

I also wanted to emphasize that my concern lies in the fact that if one simply dedicates oneself to using a framework without taking the time to understand the language, one can be left with the impression that things work by some kind of “magic”.

Of course, frameworks precisely hide much of the complexity of their inner workings, accelerating development, but this concealment can lead to stagnation, a kind of “paralysis” when we see the need to extend or modify something. It would be extremely useful to have a clear idea of ​​how a framework works, bringing out some of that “magic”.

Now, we’ll turn to discussing the Application object, the heart of our application.

Let’s remember the structure of our application, of which we previously explained the function of each directory (Figure 29).

The library, as we can see, has two directories called core and widgets. Inside the core directory are all the classes that make up the core of our framework. That is, those classes that are not specific to our application but will be present in each project that we carry out (Figure 30):

Go ahead and create the files, we can leave them empty for now.

Let’s remember the contents of the bootstrap.php file:

This file is in charge of instantiating the Application object, which in turn will be in charge of instantiating the appropriate controller and calling the correct method of said controller, according to the request received.

Let’s look at the content of Application.php. It’s not too long and we’ll go through it piece by piece:

In the first line we identify the namespace to which our class belongs:

In a simplified way, we can think of a namespace as a way of grouping classes. Thus, our core namespace groups together the Application, Controller, db, Model, and Template classes.

Two classes with the same name cannot exist in the same namespace, but they can exist in different namespaces.

After identifying the namespace to which the class corresponds, we have its definition:

Then we find the first method of our class:

The purpose of this method is establishing the way in which the errors of our application will be registered, according to the value of the DEVELOPMENT_ENVIRONMENT variable, which, as we remember, is defined in the config.php file.

If the value of this constant is true, then we do two things: We

set the error reporting level to E_ALL. That is, all types of errors will be reported.

By setting display_errors to on, we are indicating that we want all errors to be displayed as part of the screen output. This is very useful in the development phase when we are debugging bugs.

Conversely, if DEVELOPMENT_ENVIRONMENT is false, then display_errors will be set to off, hiding error messages from the user. However, it is important to be able to parse such errors, so we add a new line:

With it, we are indicating in which file the errors that occur at runtime will be dumped, for later analysis.

Next we have a very short method:

This method receives a parameter, which can be an array or a single element. In the case that it is a vector, we make use of the array_map function. This function receives two parameters: a function to be applied, and an element on which to apply it.

Note that the function to be applied is stripSlashesDeep itself. That is, we have a recursive call. Also notice that the first parameter passed to array_map has the form:

This is because we are calling a function that is a method of a class, so we must use “$this”. $this is a pointer that represents, at run time, the calling object. Next, we have the name of the function.

As the second parameter of array_map, we have the value (which we already established to be an array) $value.

In short, array_map receives two parameters: a function and an array. And I return an array as a result, where the function indicated in the first parameter has been applied to each of the elements.

On the other hand, if $value is not an array but a single value, the stripslashes function is applied to that value. This function removes character escape slashes in strings:

For example, if we have the string O'Brian, after stripslashes we will have the string O’Brian.

The following method:

Simply call stripSlashesDeep method for requests received via $_GET. We won’t be doing it for $_POST because this could give us an empty $_POST array, or $_COOKIE because later we will use cookies to implement the Remember me functionality.

Finally we have the run method:

Let’s analyze it carefully:

This method receives as a parameter the url that the user has requested, for example, given our application called simplemvc, when entering in the browser:

localhost/simplemvc/items/index, the received parameter ($url), it will have the value “items/index”.

Then we have the following statements:

Using the explode function, we convert the received string into a vector. Following the example, if $url has the value “items/index”, then we will have the following vector:

$url[0] = “items” $url[1] = “index”

Then we have $controller = array_shift($url) ;

The array_shift function returns the first element of an array, and removes it from the array. Following the example, in $controller we will have saved “items”.

Then we have:

What we do here is get the name of the class that represents the desired controller. We know that requests arrive in the form “controller/action”. From the indicated controller, we must obtain the name of the class that corresponds to the controller.

Following the example, $controllerClass will contain the value “controllers\ItemsController”, which corresponds to the name of the class including its namespace (controllers).

Note the use of the ucwords function, which converts the first character of each word in a string to uppercase. In this case “items” becomes “Items”.

Let’s continue:

Now we get the name of the action, in our example, “index”. Recall that array_shift takes and extracts the first element of an array.

At the beginning we had the array: [“items”, “index”]. After the first call to array_shift we will have: [“index”]. After the second call we will have an empty array.

Finally, $queryString will contain…an empty string? Yes, in this case. But suppose that instead of “items/index” we would have received “items/edit/1” as a request. In this case, we would have:

$controller = “items” $controllerClass = “controllers\ItemsController” $action = “edit” $queryString = 1

Let’s continue:

In the outermost if we check if the requested class (the controller) exists. Otherwise we finish the execution of the script showing a message.

In case the class exists, we have the following line:

The class_parents function returns an array containing the names of all classes that are ancestors of the class passed as a parameter.

What does this mean?

Suppose we have a class “A”. Then we have a class “B” that inherits from “A”. Finally we have a class “C” that inherits from “B”.

class_parents(“C”) will return the following array: [“A”, “B”].

Next we evaluate another condition:

What we are looking for is to see if in the $parents array, which contains the ancestor classes of $controllerClass, the class “core\Controller” is present.

This means that each controller in our application must extend from the base class “Controller”. We have already seen this many times in Yii, where we have for example a controller class “Client” defined in this way:

class ClientController extends Controller

If the class does not extend “Controller”, then we interrupt the execution of the script with an error message.

If it’s a class extending from “Controller”, we have the last if:

What we do here is use the method_exists function. Such a function determines whether a given method is present in a given class.

We make sure that the requested action is a method of the desired controller. If this is not the case, we terminate the execution with an error.

If it is present, then we instantiate a new object of the desired controller class. In this case ItemsController.

The call_user_func_array function receives two parameters. The first is an array, where the first element corresponds to the instantiated controller object, and the second to the method that should be called for that controller. The second parameter corresponds to the value that said method will receive as a parameter.

This may sound confusing, but what it means is the following:

From the “items/index” request, the “index” method of “ItemsController” will be called. In that case the index method will receive an empty parameter.

If the request had been “items/edit/1”, then the edit method of ItemsController would have been called, and the method in question would receive the value 1 as a parameter.

Of course, using die to show a message and end the execution is far from an elegant solution, in fact, is not a solution at all, but we’ll take care of that later.

We are closer to the first functional version of our framework. In the next chapter, we’ll be working on the database connection class.

Almost every application that we develop we’ll consume data from a source, normally a database. For this book, we will be using MariaDB as our database engine although ideally, our application should be database agnostic. We can accomplish this by introducing abstraction layers. We’ll build a database class that uses PDO internally. PDO provides one abstraction layer, and our class will simplify working with that extension.

We still don’t have the database simplemvc. That’s ok, we don’t need it just yet.

Now, in the core folder, put the following content in the db.php file:

We use our constructor to get a new PDO instance. We take a parameter named CONFIG, which is an array. Note that we are using type hinting to let php know what kind of parameter we should expect. Also, take note of the inverted slash \ at the beginning of the PDO class name. We need this because we are working in the core namespace, so every reference to a class we’ll be interpreted as a reference to a class in that namespace. The slash indicates that we are referencing a class in the global namespace.

There is not much in this function. We,ve wrapped everything in a try catch block, and we trigger an error if the connection fails. trigger_error creates a user-level error message. At this point, you could also write an entry in a log file. But it’s enough for now.

Let’s add another method.

In this function we simply return the connection.

Now, we will build a method to return a resultset, containing all the records from a table.

We receive the table name, and optionally an array of field names. We build the query string to return all or some columns of the records, we retrieve the connection, prepare a sentence with the query string, execute it and return the result. Note that we are setting the fetch mode to FETCH_ASSOC, this means we can reference every column of the rows as properties, so we can have something like this:

Now, on to the next method:

Now, this method is pretty similar to the previous one (we could definitely use a refactor but we leave it for later), except that we return a single row, based on some field (normally the id).

The next one is a little bit more complex:

Let’s analyze this part:

We use the parameter $data, which is an associative array, to build the part of the query where we assign values to the fields. This relies on the fact that the array $data has keys that correspond to the field names. But, as we’ll see later, we rarely use the database class directly. Our models will deal with it.

In this other block:

We determine if we are dealing with an insert or an update, based on the presence or not of a key.

Now we’ll present two other short methods:

We are building upon the save method. This is always good, as we should reuse as much as possible.

The last one:

We delete a record based on the value of the key.

And that ’s it. We have everything we need for any kind of interaction with the database.

In the next chapter, we will focus on the Model, View and Controller classes. But, just to be sure everything is right, here is the corresponding gist of the db class.

See you in the next chapter.

As we said in the last chapter, we will start working on the Model, View and Controller classes. We have already discussed that the library folder contains the classes that build our framework.

Inside that folder, we have two other directories, core and widgets. The core folder, as its name suggests, contains the core classes. Our Model, View and Controller classes will provide the basic functionality, the common behavior that the derived classes - the models, views and controllers of every particular project - will follow.

But first, let’s do some cleanup on our Application class.

In our run function, we have this piece of code:

We really need to get rid of those die statements. If you don’t have it already, create a file named ResourceNotFoundException.php in the core folder with the following content:

It’s a very simple class, extending from the Exception class. Note the use of the slash \ at the beginning of the name of the class we are extending. This is necessary because we are in the namespace core, so every reference to a class will be interpreted as a class residing in that namespace.

We have our constructor, which simply invokes the parent constructor. At this point you might be wondering why have a constructor whose only purpose is to implement the parent’s constructor. But it’s a good practice, and we could easily add new functionality.

Let’s add another file named Response.php in the core folder with the following content:

We have an only function, setResponseHeader. This function will set a header with the code indicated in the first parameter. At this point, we will only use this function to display 404 errors, but we could easily extend it to include all 4xx errors.

For a complete list of http status codes you can visit this link.

Now we can rewrite our run function as follows:

Instead of spitting a message we throw an exception of type ResourceNotFoundException. The exception is captured by our catch sentence, and then an adequate response is shown.

At this point, you might be tempted to execute the application. Go ahead, open the browser and type http://localhost/simplemvc/nocontroller/noaction. You should see something like this (Figure 31):

Before we continue, let’s make a small change. It is not mandatory, but convenient. Right now, our config.php file has the SITE_BASE constant defined as:

We’ll use a virtual host, something that we already saw in previous chapters. Change the line to:

Now open the httpd-vhosts.conf file and add these lines:

The final step is change the hosts file to include this line:

127.0.0.1 simplemvc.test

You can choose to skip these steps, it will only affect the address that you must type in the browser. With these changes we can simply use simplemvc.test, which is shorter.

Now we can concentrate on the main purpose of this chapter. Since chapter 05 dealt with the database class, it is a good idea to continue the Model class.