Comments 5
Еще один сложный момент — это управление памятью на стыке JS и C++, вот тут автор осветил тему, пытался разрулить, но переусложнил как по мне. Наверное проще всегда управлять объектами в C++, чтобы не было внезапных падений.
Как я понимаю, при использовании QQmlListProperty не получится повесить анимации на добавление и удаление объектов, только полная перезагрузка вьюхи, что не очень хорошо смотрится.
При этом у QAbstractListModel с ролями в классическом виде есть недостаток при использовании на мобильных платформах, когда мы хотим отредактировать какой-нибудь элемент списка на отдельном экране, нам придется создавать JS объект, заполнять его полями модели, передавать в редактор, потом в обратном порядке. Поэтому можно сделать модель с одной ролью, сразу отдающей наследника QObject с полями в Q_PROPERTY. Вот интересный вариант посыпанный сахаром.
Хорошо бы еще добавить древовидный пример (как на скрине), причем может быть не на стандартном TreeView, потому что в новых контролах его нет и непонятно когда будет.
TreeView можно реализовать при помощи обычного ListView, только нужна прокси-модель, которая из дерева сделает список.
При этом у QAbstractListModel с ролями в классическом виде есть недостаток при использовании на мобильных платформах, когда мы хотим отредактировать какой-нибудь элемент списка на отдельном экране, нам придется создавать JS объект, заполнять его полями модели, передавать в редактор, потом в обратном порядке.
Необязательно, можно выставить диалогу редактирования нужные параметры и потом показать его.
Кстати, можно использовать Q_GADGET для структуры данных и передавать ее как var в QML (нужно будет зарегистрировать этот тип).
Поэтому можно сделать модель с одной ролью, сразу отдающей наследника QObject с полями в Q_PROPERTY.
Тоже вариант, я когда-то так делал. Но есть много нюансов — например, мы же привязываемся к свойствам этого объекта и вызываем его методы в делегате. А значит, надо обрабатывать ситуации, когда объекта еще/уже нет. Если устанавливать обработчики на сигналы этого объекта, то могут быть всякие мутные ситуации, когда объект есть, обработчик сигнала тоже есть, а вот контекста, где вызван этот обработчик уже и нет (делегат был разрушен/очищен).
Я бы сказал, что лучше все-таки отдавать данные, если есть такая возможность.
Еще один сложный момент — это управление памятью на стыке JS и C++.
По умолчанию владение JavaScriptOwnership будет установлено, если явно вызываемый метод вернет QObject* без родителя. Т.е. для фабрики. Во всех остальных случаях, почему это у объекта вообще не установлен parent? :) На мой взгляд, тут вопрос проектирования.
Можно я бессовестно попиарюсь по поводу моделей? =)) Запилил небольшую либу для работы с JSON/XML REST используя Qt-модели и QML.
Поддерживает из коробки сериализацию JSON списочных данных, фильтрацию, сортировку, пейджинг и прочее. Точно совместима с Yii2-REST и Django REST API.
https://github.com/kafeg/qtrest
Model-View в QML. Часть четвертая: C++-модели