У меня есть структура кода, уже использующая SQLAlchemy для создания декларативных моделей.
Примеры таблиц / моделей:
- Репозиторий
- repository_id
- имя
- владелец
- конечная точка
- repository_id
- endpoint_id
- имя
- метод
- Контексты
- context_id
- endpoint_id
- parent_context_id
- config
- создал_он
- create_by
Я хотел бы создать QtTree для выбора репозитория> Конечная точка> Контекст> Вложенный контекст.
По аналогии с тем, как IDE может иметь вид браузера, который отображает обе папки / пакеты / файлы и дает разные меню для щелчка правой кнопкой мыши.
Я пытаюсь понять, каким будет «правильный» способ реализации этого.
Я посмотрел на GitHub, чтобы увидеть, что сделали другие люди, но большинство небольших приложений с открытым исходным кодом просто используют TreeWidget и имеют более e или менее жестко закодированные представления или крупные проекты, такие как «Eri c», которые делают такие вещи, как Lazy Loading ... и я не уверен, что это излишнее из-за того, что я хочу сделать - 1700+ Строки пользовательского кода реализации в Eri c, похоже, дают больше отзывов, чем что-либо еще, что я видел ... но у меня все еще есть проблема, что проблема с моей моделью уже частично определена ...
Поскольку я в основном использую SQLAlchemy для остальной части приложения, я должен сначала создать / использовать «SqlAlchemyTableModel» для создания каждой модели, а затем создать «BrowserModel», который выполняет logi c для их создания?
Должен ли RepositoryModel / EndpointModel / ContextModel быть подклассом или достаточно просто создать их с помощью обобщенного c класса?
В идеале я хотел бы, чтобы Repository / Endpoint / Et c чтобы в списке были разные значки и разные ContextMenus. Должны ли они быть установлены в их модели? Через родительскую модель? Через прокси декоратор? С точки зрения делегатов?
Я чувствую, что у меня есть миллион молотков, но я понятия не имею, смотрю ли я на гвоздь или винт.
Ссылка: https://github.com/davy39/eric/blob/master/UI/BrowserModel.py