Как-то поучаствовал в споре на партнерском форуме 1С на тему управляемого интерфейса. Мне тогда безапелляционно заявили, что управляемые формы - это лучшее, что произошло на платформе 1С:Предприятие со времен перехода с 7.7 на 8.0.

Но если управляемые формы - это настолько прорывная и восхитительная технология, то почему со времен 8.2 тянется ворох багов и ошибочных решений, которые никто даже не планирует исправлять?

1. Ок, допускаю, что технологически сложно было сделать обвертки над объектами, чтобы поместить их в данные формы, и потому придумали новые типы, которые используются только в качестве реквизитов формы, но почему не дать тут же на форме удобный АПИ для преобразования? Почему нас путают двумя методами для преобразования, которые делают одно и тоже (только один явно требует целевой тип, а второй может сам о нем догадаться)?

2. Почему самый базовый тип для работы с коллекцией данных, Таблицу Значений, запрещено передавать между клиентским и серверным контекстом формы? При том, что она может жить и на сервере, и на клиенте (как реквизит формы, или создание через конструктор Новый). Сколько еще десятилетий результат выгрузки запросов и табличных частей нужно будет дополнительно преобразовывать в массив структур?

3. Почему нельзя создать переменную модуля формы, которая будет жить и на сервере и на клиенте? Почему сохранение данных предусмотрено только для клиентских переменных, а серверные живут только на протяжении серверного вызова?

4. Если для массивов, структур и соответствий, которые должны существовать одновременно на клиенте и сервере, предлагается использовать реквизиты формы, то почему для них нет нормальных типов и нужно использовать тип Произвольный? Почему из этой тройки напрямую в реквизит можно записать только Структуру, а остальные только в качестве значений этой структуры?

5. Почему для Элементов Формы нельзя просто взять и проверить путь к данным на стороне клиента (важно для элементов, которые создаются расширениями и обработками)? Почему для этого обязательно нужно делать серверный контекстный вызов?

6. Почему для Элементов Формы нельзя просто взять и получить в коде на форме значение Заголовка, если оно явно не скопировано в свойства элемента? Почему для этого нужно делать серверный вызов, считывать путь к данным, а дальше делать исследование через метаданные?

7. Почему вообще нет простого способа через код узнать "Что видит и что доступно пользователю?". В некоторых сценариях Видимость=Истина для невидимых элементов и ТолькоПросмотр=Ложь с Доступность=Истина для недоступных для редактирования. Если видимость и доступностью управляются условным оформлением в табличных частях, то тут вообще тяжелый случай: нужно делать серверный контекстный вызов, считывать текущее условное оформление, перебором выискивать есть ли оформление элементов из табличной части и есть ли управление видимостью/доступностью и выполняются ли правила применения (которые могут быть очень сложными) к текущей строке таблицы.

8. Почему для програмного управления формой все настолько сложно, что все пишут собственные велосипедные библиотеки? Почему все нужные свойства нельзя передавать в конструкторы элементов формы, а не требовать держать под рукой черновики для копипасты, так как для разных типов элементов внезапно стают доступны или недоступны свойства, которые описаны в справке (проверка синтаксиса естественно промолчит и ошибка будет только во время выполнения).
(продолжение)