1. Undo/Redo изменений в конфигурации
1.1. Глобальное для конфигурации
1.1.1. Древовидная организация глобальной истории для ограниченной возможности undo/redo в отдельном редакторе для определенного набора cases (например редактирование скрипта)
1.1.1.1. Возможность локального отката изменений для специфичных редакторов (например скриптовых модулей) с сохранением общего подхода для всех остальных редакторов и View
1.1.1.2. Все же отход от единого подхода, хоть и частичный
1.1.2. Линейная история
1.1.2.1. Единый подход для пользователей (всегда предсказуемое поведение системы)
1.1.2.2. Невозможность отката нужных изменений в случае наличия изменений (несохраненных) в нескольких редакторах
1.2. Локальное для редактора
1.2.1. Хорошее понимание того, что именно будет откачено в результате действий пользователя
1.2.2. Невозможность вразумительного отката комплексных изменений в конфигурации (затрагивающего другие объекты, кроме основного редактируемого), как и изменений, сделанных вне контекста редактора
1.2.3. Невозможность Undo/Redo изменений из View, если только не используется рефакторинг
1.2.4. + Механизм локальной истории изменений
1.3. Смешанное (для части элементов приложения локальное, для остальных - глобальная история)
1.3.1. Редактирование контента - только через редактор, при внесении изменений через View и проч. элементы - использовать только рефакторинг для возможности отката через глобальный контекст конфигурации
1.3.1.1. Неочевидность ограничений для пользователя
1.3.1.2. Усложнение действий для пользователя
1.3.2. Редактирование контента с историей через редактор, при редактировании через View и проч. - автосохранение без возможности отката
1.3.2.1. Ограничение возможностей пользователя выполнять действия из удобного в данный момент контекста (и увеличение потребных телодвижений)
1.3.2.2. Неочевидность контекста для пользователя - отличить редактор от View для нормального пользователя проблематично
1.3.3. Редактирование контента с историей через редактор, при нахождении View в контексте редактора - как редактор, отдельно - автосохранение и/или рефакторинг
1.3.3.1. Различное поведение одних и тех же элементов в зависимости от контекста - хуже, чем просто разное, но стабильное поведение элементов
2. Редактирование комплексных объектов/нескольких объектов в редакторе/View
2.1. Нет
2.1.1. Просто не вариант - система будет жутко ограниченной с точки зрения usability
2.2. Да
2.2.1. Возможность создания комплексных редакторов/View/проч - несомненный плюс
2.3. Смешанное
2.3.1. В зависимости от реализации редактора/View
2.3.1.1. Усложнение принятия решения о том, какая реализация нужна для разработчика расширений к платформе (скорее всего вегда будут брать комплексный вариант по факту, чтобы не заморачиваться)
2.3.2. Нельзя в редакторе, можно во View
2.3.2.1. Заметно ограничивает удобство пользователя и ухудшает Usability
2.3.3. В редакторе - полное, во View - только из контекста редактора, без контекста - редактирование запрещено (или рефакторинг)
3. Связь модели и структуры ресурсов
3.1. Жесткая, 1-1 (один объект - один ресурс)
3.1.1. Невозможность оптимизировать формат хранения данных для удобства работы вне IDE/системах версионного контроля
3.1.2. Невозможность смены медиума хранения конфигурации (например БД/облако)
3.1.3. Привычная структура для текущих разработчиков конфигураций
3.2. Многоаспектная стандартизированная ( выделяются несколько стандартных типов ресурсов - например объекты и репозитарии, все данные мапятся на эти стандартные типы ресурсов)
3.2.1. Позволяет оптимизировать структуру под использование VCS
3.2.2. Все также не позволяет легко сменить медиум хранения
3.3. Нет (структура модели и структура ресурсов напрямую не зависят)
3.3.1. Дает гибкость решения в будущем даже без пересмотра формата хранения данных сейчас
3.3.2. Позволяет работать только с моделью для разработчиков расширений для конфигурации и не задумываться о двух жизненных циклах - модели и ресурса (упрощение API для разработчиков сторонних расширений)
4. Изменение данных без открытого редактора (включая сценарии запуска комплексных бизнес-процессов, например генерация контента по другому контенту)
4.1. Нет
4.1.1. Заметное ограничение возможностей системы
4.2. Да
4.2.1. Обычно без этого сложно представить серьезную систему
4.2.2. Напрямую
4.2.3. Рефакторинг обязательно
4.2.4. Когда как
5. Dirty State и его актуализация
5.1. Актуализация по Save в редакторе, до этого никто другой не знает об изменениях. Dirty state в редакторе
5.1.1. Проблема доступа к изменениям, сделанным в неизвестном редакторе (по факту для надежности необходимо сохранить все изменения во всех редакторах)
5.2. Dirty state измененных объектов конфигурации доступен всем интересующимся, Save актуализирует Dirty State только для элементов, измененных в контексте конкретного редактора. Dirty state в редакторе
5.2.1. Поддержка частичной актуализации dirty state
5.2.2. Неочевидность того, что именно будет сохранено
5.3. Dirty state измененных объектов конфигурации доступен всем интересующимся, Save актуализирует Dirty State только для элементов, связанных с ресурсом, редактируемым редактором. Dirty state в редакторе
5.3.1. Поддержка частичной актуализации dirty state, но для ограниченного круга применений
5.3.2. Полная неочевидность того, откуда взялись измененные объекты, и почему (раз они появились при работе данного редактора) они не актуализируются. По факту следующим действием пользователя будет нажатие кнопки сохранить все
5.4. Dirty state измененных объектов конфигурации доступен всем интересующимся, Save актуализирует всю модель, Dirty state в модели (всей или отдельных объектах)
5.4.1. Невозможность частичной актуализации Dirty State
5.4.2. Единая модель поведения для пользователя
6. Изменение данных через редактор и через View
6.1. Единая политика и визуальное поведение
6.1.1. Дает возможность воспринимать понятие редактора и View с точки зрения бизнес-области, а не как техническое разделение, что упрощает работу для сторонних разработчиков
6.1.2. Полностью ожидаемое поведение для пользователей - они не задумываются о том, что у них открыто
6.2. Различное поведение
6.2.1. Четкое разделение - Editor меняет, View отображает (или через рефакторинг), либо меняет если есть контекст редактора
6.2.1.1. Серьезное ограничение Usability для конечных пользователей
6.2.2. В зависимости от ситуации
6.2.2.1. Требует аккуратного проектирования пользовательского интерфейса и затрудняет принятие решения об использовании того или иного сторонними разработчиками
7. Параллельная работа из IDE и на файловой структуре
7.1. Разрешена полностью
7.2. Разрешена частично (на определенном уровне детализации)
7.3. Запрещено
7.3.1. Слишком большие ограничения