Tables

The first record appeared in the database! But we don't see it, and it needs to be fixed. To do this, you need the Table component (a table that will display the necessary data). Immediately upon adding, it will ask you to decide what data will be in it and select a model and endpoint.

Table settings

The created table should immediately be issued in accordance with your requirements. For example, limit the number of records on one page (table can be very long and multi-page), as well as remove fields that are of no interest or set up the desired field for output from related tables.

At the same time, we remember that the mere addition of any component does not yet mean its complete readiness for work. You need to create appropriate business processes. For tables, a lot is created automatically, but as part of the training, we will create everything from scratch to better assimilate the material.

Table triggers

There are three triggers of greatest interest in tables - onDataUpdate, onShow, and onFilter. Let's start with onShow and define what should happen when the table is shown on the screen. This will require three blocks:

1) Table Update Properties. Set the desired properties of the table. For example, here you can limit the number of records on one page (set parameter the Records per page = 10) and also show that the page is in data loading mode (Loading = true)

2) Server request GET /country/. In order for the data to appear, they need to be taken somewhere. And to do this, make a request to the database for the corresponding endpoint. At the same time, pay attention to the number of input parameters of this endpoint. They provide more flexibility in the query and get only the data that is really needed.
In our case, we will set _limit = 10 because the number of entries per page is 10, and there is no point in loading more. In addition, we will make the correct output order, sort everything by name (_sort_by = name), and also set the sort order. The _sort_order parameter can take the value ASC (from the word Ascending, for direct sorting, from the smallest value to the largest) or DESC (Descending, reverse order). Direct alphabetical sorting is fine for us, so _sort_order = ASC.

The _with parameter deserves special attention. Executing the query without it, we could only get data about countries. But the country model is related with cities, and although this data does not belong to the requested table, we still want to see them. To do this, set _with = citys and immediately get data about what cities are in this country.

3) Table Update Data. The data is received, but it needs to be transferred to a table to be displayed on the screen. To do this, we pass all the information (data) received in the previous block, as well as the total number of records (count - Total Records), in order to understand how many pages should be in the table.

The next trigger is onDataUpdate. The data in the table can be updated as a result of various business processes. And when this happens, it is best to specify once what should happen and not put the same blocks in each business process. In our case, it will be correct to use the Table Update Properties block again, but this time in order to remove the loading mode (Loading = false), which was set earlier, and show that the table is ready to work.

The last trigger we need is onFilter. It defines what should happen at the moment of transition to other pages of the table. To do this, it has the _offset parameter, which, in accordance with the page number, indicates what offset is required when loading data.

For example, if, in our case, there are 10 entries on each page, then the third page will need entries from 21 to 30. This data will be obtained from _offset and can be passed to the Server request GET /country/ block. Otherwise, the business process will completely coincide with the process on the TableOnShow trigger. In such situations, it would be reasonable to have two different triggers launch the same business process.

But in our case, the important difference lies in the _offset parameter. If you leave everything as in the screenshot below, then the process will start according to the onShow trigger, but it will stop at the Server request GET /country/ block since it cannot get the _offset value (it is passed from another trigger).

This situation is best solved using variables. Let's look at a specific example. We need a variable of Integer type to save _offset value. Therefore, we use one Integer block to declare this variable, but two different Set Variable blocks to write its value, each associated with a different trigger.

According to the Table onShow trigger, we do not need any offset, the data in the table is shown from the very beginning and _offset = 0, so we set Value = 0 in the Set Variable block. 

When the Table onFilter trigger is launched, we already receive the _offset value and want to use it so we will pass the _offset value of the trigger as Value to the Set Variable block.

In the next steps, the business processes of triggers do not differ from each other, so two business processes are combined into one, each with its own value of the integer variable for the _offset parameter.