Продолжаю подкидывать идеи фирме «1С» по улучшению платформы 1С:Предприятие. Сегодня пройдусь по «Подсистемам». Задумка хорошая, но реализация, как обычно, подкачала. Очень сильно подкачала. На мой взгляд, в том виде, как есть сейчас «Подсистемы» в 1С — пустое место. Пользоваться неудобно и бессмысленно (только ради отображения в интерфейсе).
Для начала надо… создать (вернуть, т.к. это было в ранних версиях 1С8.0 и 1С8.1) отдельный раздел «Интерфейс», который и будет, собственно, основой меню, интерфейса пользователя. Здесь у нас остается такая функция как «Командный интерфейс», в которой можно задать последовательность, видимость, доступность и т.д. тех или иных команд пользователю. По сути, мы возвращаемся к тому, что было в 7.7 и 8.0 (8.1) — был отдельный раздел «Интерфейсы», в котором описывались доступные пользователю пункты меню. Эти интерфейсы можно было включить в ту или иную подсистему. И это верный, логичный подход. Я до сих пор не понимаю, почему отказались от этого раздела. Ведь сейчас получается полная ерунда — в подсистему включается куча справочников, документов, но они не отображаются в интерфейсе. Зачем это надо?
А теперь описание того, чего не хватает в реализации подсистем. Здесь у меня «хотелок» гораздо больше.
- Убрать из подсистем «Командный интерфейс» — т.к. интерфейс должен описываться отдельно (смотри выше).
- Добавить в подсистему свойство «Номер версии». Необходимо как воздух.
- Добавить для подсистем свойство с возможностью выбора множества значений «Зависит от подсистем». В этом свойстве разработчик должен выбирать другие подсистемы, необходимые для работы текущей, а также указывать минимальный номер версии «ведущей» подсистемы, с которой можно работать (т.к. не все зависимости можно выстроить по простой иерархии). Получится, что платформа сможет отслеживать наличие всех требуемых подсистем в конфигурации и соответствуют ли их версии. Как пример — указывать, что для подсистемы «Присоединенный файлы» необходимы подсистема «Базовая функциональность» версии 2.1.4 и «Работа с файлами» версии «1.6.2» и если эти требования не выполняются, то, например, функционал данной подсистемы недоступен для пользователя (или вообще невозможно запустить приложение). Есть сложность — при задании свойства необходимо отслеживать указанную зависимость на наличие «кольца», чтобы не получилось, что для «подсистемы 1» нужна «подсистема 2», для «подсистемы 2» — «подсистема 3», а для «подсистемы 3» — «подсистема 1».
- Для каждой подсистемы сделать предопределенные модули (как «Модуль менеджера» или «Модуль объекта») по типам модулей. Модуль «Клиент», «Сервер», «КлиентСервер», «ПовторныйВызов» (хотя бы на время сеанса). Плюсы этого подхода — модули сразу привязаны к подсистеме и открываются из окна свойств (что удобно), у нас очень сильно уменьшится список «Общие модули» (сейчас он получается очень большой и неудобно искать нужный модуль). А также добавить модуль «ОбновлениеПодсистемы», в котором должна быть предопределенная процедура «ОбновлениеВерсии», вызываемая автоматически при запуске программы, если — читай следующий пункт. Порядок вызова процедур обновления должен соответствовать зависимостям подсистем (пункт 3).
- Добавить в подсистему свойство «Номер рабочей версии». Это свойство невозможно установить в конфигураторе, а только вызвав в коде какую-нибудь процедуру «УстановитьНомерВерсииПодсистемы». С помощью этого свойства можно автоматически отслеживать версии и запускать процедуру обновления (смотри пункт 4).
Пока на этом с подсистемами остановимся. Как бонус — еще одна идея (возможно, это уже слишком). Для объекта метаданных «Отчет» или «Обработка» так же, как и для подсистем добавить возможность указания необходимых подсистем и их версий.