Продолжаю подкидывать идеи фирме "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).
Пока на этом с подсистемами остановимся. Как бонус - еще одна идея (возможно, это уже слишком). Для объекта метаданных "Отчет" или "Обработка" так же, как и для подсистем добавить возможность указания необходимых подсистем и их версий.
