Таблицы

Отлично, в базе появились первые данные! Вот только мы их не видим, и это необходимо исправить. Для этого понадобится компонент Table (таблица, которая будет отображать необходимые данные). Сразу при добавлении она попросит определиться с тем, какие же данные в ней будут, выбрать модель и эндпойнт.

Настройки таблицы

Созданную таблицу стоит сразу же оформить в соответствии со своими требованиями. Например, ограничить количество записей на одной странице (а таблица может быть очень длинной и многостраничной), а также убрать поля, которые не представляют какого-то интереса или настроить нужное поле для вывода из связанных таблиц.

При этом помним, что само добавление любого компонента, еще не означает его полной готовности к работе. Нужно создать соответствующие бизнес-процессы. Для таблиц многое создается автоматически, но в рамках обучения, для лучшего усвоения материала, все будем создавать с нуля.

Триггеры таблицы

Наибольший интерес в таблицах представляют три триггера - onDataUpdate, onShow и onFilter. Начнем с onShow и определим, что должно произойти, когда таблица будет показана на экране. Для этого понадобятся три блока.

1) Table Update Properties. Устанавливаем нужные свойства таблицы. Например, здесь можно ограничить количество записей на одной странице (установим параметр Records per page = 10), а также показать, что страница находится в режиме загрузки данных (Loading = true)

2) Server request GET /country/. Чтобы данные появились - их нужно где-то взять. А для этого сделать запрос к базе данных по соответствующему эндпойнту. При этом обратите внимание на количество входных параметров данного эндпойнта. Благодаря им обеспечивается большая гибкость запроса и получение только тех данных, которые действительно необходимы.
В нашем случае установим _limit = 10, ведь количество записей на странице равно 10 и нет смысла загружать больше. Помимо этого сделаем правильный порядок вывода, отсортируем все по названию (_sort_by = name), а также установим порядок сортировки. Параметр _sort_order может принимать значение ASC (от слова Ascending, для прямой сортировки, от меньшего значения к большему) или DESC (Descending, обратный порядок). Нам подойдет прямая сортировка по алфавиту, поэтому _sort_order = ASC.

Отдельного внимания заслуживает параметр _with. Выполняя запрос без него, мы могли бы получить данные только о странах. Но модель стран связана с городами и, хоть эти данные не относятся к запрашиваемой таблице, мы все равно хотим их видеть. Для этого устанавливаем _with = citys и сразу получаем данные еще и о том, какие города есть в данной стране.

3) Table Update Data. Данные получены, но для отображения на экране их необходимо передать в таблицу. Для этого передаем всю информацию (data), полученную в предыдущем блоке, а также общее количество записей (count - Total Records), чтобы понимать сколько страниц должно быть в таблице.

Следующий триггер - onDataUpdate. Данные в таблице могут обновляться в результате действия разных бизнес-процессов. И когда это происходит лучше всего один раз указать, что должно произойти, а не ставить одинаковые блоки в каждом БП. В нашем случае будет правильным снова воспользоваться блоком Table Update Properties, но на этот раз для того, чтобы убрать режим загрузки (Loading = false), который устанавливали ранее, и показать, что таблица готова к работе.

Последний триггер, который нам необходим, это onFilter. Он определяет, что должно происходить в момент перехода на другие страницы таблицы. Для этого в нем есть параметр _offset, который в соответствии с номером страницы указывает, какое же требуется смещение при загрузке данных. Например, если в нашем случае на каждой странице находится по 10 записей, то на третьей странице понадобятся записи от 21 до 30. Эти данные будут получены из _offset и их можно будет передать в блок Server request GET /country/. В остальном бизнес-процесс будет полностью совпадать с БП на триггере TableOnShow. В подобных ситуациях разумно было бы сделать так, чтобы два разных триггера запускали один и тот же бизнес-процесс. Но в нашем случае все же именно в параметре _offset заключается важное отличие. Если оставить все так, как на скриншоте ниже, то процесс по триггеру onShow хоть и запустится, но остановится на блоке Server request GET /country/, так как значение _offset получить не сможет (оно передается из другого триггера).

Данную ситуацию лучше всего решить с использованием переменных. Давайте посмотрим на конкретном примере. Нам понадобится переменная типа Integer, чтобы записать в нее значение _offset. Поэтому мы используем один блок Integer для объявления данной переменной, но при этом два разных блока Set Variable для записи ее значения, каждый связанный со своим триггером.

По триггеру Table onShow нам не нужно какое-то смещение, данные в таблице показываются с самого начала и _offset = 0, поэтому и в блоке Set Variable установим Value = 0.

А вот при запуске триггера Table onFilter мы уже получаем значение _offset и хотим использовать именно его, поэтому и в блок Set Variable в качестве Value передадим значение _offset триггера.

В дальнейшем бизнес-процессы триггеров ничем не отличаются друг от друга, поэтому два бизнес-процесса объединяются в один, но каждый со своим значением переменной integer для параметра _offset.