What is CRUD

The letters CRUD mean Create, Read, Update, Delete - "create", "read", "update", "delete". These are not just letters, but the ideology of designing the user interface and server backend.

At the same time, these are not some rules, but simply the logic of the exchange with the server. It may be different, but it should remain just logic.

Our note_update.php file adds a new entry, and according to the CRUD formula, it should be named note_create.php . And the rest of the files on the server would be named like this: note_update.php , note_read.php , note_delete.php . For each CRUD action, we would refer to a file with the appropriate name.

It must be understood that the names of the files do not mean anything, we choose them based on our logic. But they can play a role. When we really support CRUD throughout the project, then it is enough for us to know only the name of the object and the action that needs to be performed with it. If the object is called note, then we can, for example, automatically generate links for it: note_create.php , note_read.php , note_update.php , note_delete.php .

CRUD controller

Each individual file from the example above can also be called a controller (see below). MVC design pattern ). But each of them performs only one action, and in this case, the idea is that one controller can perform all CRUD actions on one data model.

But with one controller, how do you figure out exactly what action you want to perform?

As we know, the edit form passes parameters to the controller using a POST request. Nothing prevents adding one more parameter to these parameters, which will indicate the action. For instance,

action=update

Parsing the received POST request, the controller will parse the action parameter and understand what action is required.

However, nothing prevents you from passing the action through a GET request:

note_controller.php?action=update

I think this is even better because the server logs will show exactly what actions were requested from the browser.

Both the option with several specialized controllers and the option with one universal controller can be convenient. For further implementation, we will choose the second option, since we have actually mastered the first one in the previous part.

Making a controller

Let's not call it note_controller.php , but let's make a controllers folder and in it the note.php file. Then the URL for the notes controller will look like this:

http://catalog/controllers/note.php

And in the same folder, we will be able to place all the other controllers that will appear later.

Let's make a list of actions that are supported by the controller:

view, update, delete

Why not create, read, update, delete? We are not required to follow the CRUD definitions literally, we are only required to support the chosen logic. In this case, we don't need a create action. Just update is enough. The logic is simple: if a record with an empty id is being edited, then it is not in the database and it will be created, but if the id is full, then this record already exists and needs to be updated.

Such a case is possible: as a result of some kind of failure, an update request with an empty id was received. Then a new record will be created, although it should not have been. Then a separate create action would really help us. The update action would always require a non-empty id. But we do not risk anything now and therefore we do not consider such cases.

And instead of read there will be view. No difference, it's just more familiar. This is a single post view.

Let's write the logic for processing actions.

We immediately get the values ​​for $action and $id from $_GET . They may not be there, and when accessing, say, $_GET['action'] , an error will occur. Therefore, we wrap such calls in the get_param() function , which first checks for the presence of parameters using isset() . To make the function more universal, i.e. worked not only with $_GET , but also with any array, we gave it the $data parameter , in which you need to look for the key $name .

Next, the value of $action is checked and the corresponding function is called. If no match is found, then we call the default function: index().

So far, these functions have not been written, but in this piece of code, we have done everything that is required. Now we can write functions one at a time.

Let's start with index(). Firstly, this is a default function that will work right away, and secondly, we need to make HTML pages display data. Each page will be a view of the MVC template, and we'll look at the index() example .

The index() function is very simple: it gets a list of records in the note table from the base and calls the render() function to display that list. Everything.

The render() function, in turn, includes an external file. This mechanism needs to be analyzed in more detail.

In PHP, there are two ways to include other code in your code: include() and require(). It works elementary: in the place where you wrote, for example,

include('cat.php');

This will take the text from the cat.php file and put it right there. And your program will start executing it. The difference between include() and require() is that if the file is not found then include() will issue a warning, while require() will issue a fatal error.

So index() called render() and passed three parameters there: 'main', 'index', $resultset . In terms of render() , the first parameter is the container ( $container ). What is a container and what should it contain? Let's see. Since $container is currently equal to 'main', this will include the file

../views/main.php

And you need to go to it.

Representation

Let's make the views folder on the same level as the controller's folder. This is where the views will be stored. The main.php file will contain the skeleton of a typical HTML page.

Everything here is minimal. This is the text that will be included in the render() function. What will happen? Since this is not PHP code, it is outside the <?PHP ... ?> tags . And everything that is outside is simply sent to the browser for output. This means that the browser will receive this HTML page. In which there is nothing. Or is there?

Looking closely, we see that this text also contains the following line:

<?php require("$view.php"); ?>

$container and $view . Since we are including the container text from within the function, all options are available to us. And as we remember, the $view parameter is now equal to 'index'. That is, the main.php container will now include the index.php file . And here it is already displaying a list of 

This HTML code does not have a proper header, as it is embedded in the main.php container (in fact, that's why it is a container). In other words, the container contains a blank HTML page template, and the content of the page is added by including one of the views.

The list of records is the $data variable, which is also received as a parameter by the render() function and is therefore available.

Let me briefly explain the HTML code: we display a table (<table>). A table is made up of rows (<tr>) and rows are made up of columns (<td>). You can see it in the structure of the text, I hope.

The first row of the table contains headings, so instead of <td> we use <th> there - it's like <td> , only with a font style for headings.

After the header line, we loop through as many lines as there are entries in $data . To do this, we use the PHP foreach() construct with an alternative syntax: instead of the opening curly brace "{", a colon is put, and instead of the closing "}", endforeach is put . Both options are equal, this one is considered more readable in the middle of the HTML code.

Don't forget what I said before: it might look like it's HTML code that includes PHP instructions. But no. This is a PHP program and nothing else. Anything outside the <?php ... ?> tags is simply sent to the output, which is equivalent to writing in PHP:

echo "<table><tr><th>ID</th><th>... ... ... ...";

In this form, you would immediately understand that this is the program in front of you. But that's exactly what she is. Just for your convenience, don't write echo. And we do inserts <?php ... ?> only where we need to control the execution of the program.

In addition to the foreach() control construct , we use PHP inserts to display records, but they look a little different:

<?= $note['id'] ?>

This is equivalent to writing like this:

<?php echo $note['id'] ?>

And it was also done for our convenience. In the right places of the HTML template, we insert the data received from the database into the general output stream. As a result, our page will look something like this.

So far it's clumsy, but then we will make styles according to beauty. This is a completely separate issue. The main thing now is that the functionality works.

Pay attention to the last three columns in each line - there are links to view, edit and delete each entry. With the correct action and id in the URL already. True, we cannot use them yet, since the corresponding functions have not been written. But today we set the foundation, so the rest will follow the rails.

Let's recap what happened:

The render() function, having received the container name, view name, and data, included the container file. The container, in turn, included a view file. We have received the final text of the HTML page, made up of fragments. All this text went to the output in the browser. In some places, data from the database was inserted into the output stream using PHP. As a result, the browser received the HTML page and showed it.