Меня зовут Илья, я отвечаю за инфраструктуру пользовательских продуктов в Яндекс Go. Мы строим цикл заказа такси — процессы, происходящие под капотом после того, как пользователь нажимает «Заказать». Поиск машины, назначение водителя, изменение адреса, оплата поездки — всё это части цикла. Ещё мы делаем инфраструктуру создания циклов, которая используется в Еде, Лавке, Доставке и других направлениях внутри Яндекса.

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

Как всё начиналось

В 2011 году мы запустили сервис заказа такси. В первой реализации в бэкенде был endpoint /create-order, внутри которого мы создавали заказ, искали ближайшую машину и отправляли заказ водителю (кстати, если вы не знали о том, как устроен поиск водителя, то обязательно почитайте).

Продолжаю тему создания моделей с использованием Qt MV. В прошлый раз была критическая статья по поводу того, как делать не надо. Переходим к позитивной части.

Для создания плоских моделей списков и таблиц можно использовать заготовки QAbstractListModel и QAbstractTableModel. Доведение их до готовности не составляет большого труда, поэтому рассматривать их подробно нет необходимости.

Создание же иерархических моделей – более сложная задача. О ней и пойдет речь в этой статье.

За последний год пришлось довольно много работать с Model/View фреймворком Qt. Приходилось как писать собственные модели, так и переделывать существующие. И вот, после созерцания очередного творения, решил представить общественности некоторые наработки.

Начнем с очевидного:

Не используйте виджеты

Все эти QTableWidget, QListWidget и QTreeWidget — не для вас.

Использование MVC фреймворка не составляет проблемы. В простейшем случае, можно использовать готовые модели, которые предоставляет Qt. Количество кода и его сложность при этом не растет, зато удается избежать всевозможных проблем роста. Разделение модели и отображения с самого начала позволяет с легкостью добавлять такие вещи как сортировка или фильтрация, не переписывая при этом половину кода.

Одни плюсы, а минусов, при этом, не замечено.

Задача

Задача звучит просто – напечатать таблицу. Напечатать так, чтобы она выглядела красиво и, по возможности, не расползалась.

После некоторых раздумий, решено было воспользоваться FOP для генерации PDF. Загвоздка в том, что Apache FOP не поддерживает table-layout:auto, то есть при построении таблицы необходимо вручную задать ширину столбцов (хорошо еще, что можно задать относительную ширину в процентах). Если же сделать все столбцы одинаковой ширины, таблица будет выглядеть несколько неэлегантно. Выходит, рассчитывать ширину придется вручную.

Основная идея в том, что ширину столбцов необходимо подобрать таким образом, чтобы как можно сильнее сократить число переносов строк внутри ячеек таблицы.