Желаемый функционал
by Alex Tretyakevich
1. Отрицательные моменты
2. Возможное решение
3. Гранулярное редактирование конфигурации
3.1. Гранула редактирования - это просто комплексный редактор, который формирует user experience данного раздела приложения
3.2. Гранула - это не только редактор, но и соответствующая часть модели
4. Изменение данных через редакторы, View и API (UI-less)
4.1. Изменение через редактор, View - только через рефакторинг или контекст редактора (подразумевает наличие разных action для одних и тех же действий в зависимости от контекста выполнения - редактор или view)
4.2. Изменение через контекст всей модели - в этом случае View от редактора отличить будет сложно с точки зрения логики поведения при изменении
4.2.1. Изменение через всю модель, но с учетом контекста редактора
4.3. Изменение через фрагмент модели (гранулу модели под гранулой редактирования. Все также проблема с View, которые не относятся к редакторам (например Navigator)
5. Undo/Redo на гранулу редактирования
5.1. Command stack на редактор, View и API - без него (кроме случаев, когда View работает в контексте редактора).
5.2. Command stack на контекст "гранулы" (те объекты, которые, как мы решим, входят в гранулу данных). View тогда также может быть с историей, но нужно думать о правильных ветвлениях, API - непонятно, нужен ли обший стек. Возможно и нужен.
5.3. Command stack на модель, но с ветвлениями под редакторы и View.
6. Работа с большими моделями данных (>1m элементов)
6.1. Решение с использованием Working Copy части данных, необходимых редактору (как решается вопрос прохода по всей модели - будет ли выгружаться уже загруженные Working Copy?)
6.2. Решение с выгрузкой данных и хранением скелета/индекса модели в памяти
7. Инкрементальная валидация для повышения отзывчивости UI
7.1. Индекс провалидированных ресурсов, что делать с первой загрузкой (например при импорте конфигурации)?
8. Быстрый запуск Runtime (с учетом необходимости публикации данных в другой формат
8.1. Инкрементальная публикация (непонятно, что делать при первом запуске после import)
9. Более-менее свободный формат ресурсов (1 ресурс - 1 модель, 1 ресурс - несколько однотипных моделей, 1 ресурс - поддерево модели, одна модель - несколько ресурсов, подкаталоги) для организации удобной структуры данных при работе с VCS).
9.1. Уровень DAL для развязки модели и структуры ресурсов на уровне ресурсов (умных)
9.2. Уровень DAL для развязки модели и структуры ресурсов на промежуточном уровне между ресурсами (тупыми) и моделью
9.3. Прямая привязка к ресурсам с лимитированием гибкости связи
10. Поддержка механизмов, подобных адаптерам EMF (или их самих) для прослушивания изменений модели и ее элементов
10.1. Использование нативного механизма для всей модели
10.2. Использование адаптеров только в пределах 'гранулы данных редактора'
10.2.1. Невозможность решить задачу с ExtInfo с помощью адаптеров, оставляя модель простой , неизменной, или без введения обязательного требования внесения подобных изменений через слой бизнес-сервисов
10.3. Использование аналогичного механизма собственной или сторонней разработки, учитывающего особенности стратегии, выбранной для решения вопроса скалабилити и связи между моделью и ресурсами
11. Построение derived data (динамически генерируемые и обновляемые объекты, создаваемые как результат создания/изменения других объектов модели)
11.1. Динамическое построение за счет подвешиваемых адаптеров (непонятно, что делать, если не вся модель загружена)
11.2. Смешанное, часть строится при загрузке фрагмента модели в редактор/workspace (непонятно, как в этом случае при не-загрузке модели/ресурса иметь ссылки на сгенерированные типы данных/объекты). Возможно индекс
11.3. Комплексная стратегия, с предварительным построеним данных при первой загрузке, хранении индекса и его инкрементального обновления (проблема с производительностью - нельзя поднимать всю модель, надо дейстовать выборочно)
12. Синхронизация dirty state в открытых редакторах/использование dirty state в API-вызовах без предварительной актуализации dirty state
12.1. Синхронизация через ресурсы (как в Варианте 1 и Xtext)
12.2. Синхронизация через модель
12.2.1. Прямая (изменение модели и есть dirty state)
12.2.2. Dirty state на копии фрагмента модели и механизм синхронизации копий