Как добавить табличную часть из расширения на форму документа без лишних зависимостей?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При доработке типовых конфигураций через механизм расширений разработчики часто сталкиваются с дилеммой: нужно добавить новую табличную часть в документ, но при попытке вывести её на форму платформа требует заимствовать объект документа целиком. Это, в свою очередь, тянет за собой в расширение огромное количество зависимых справочников, перечислений и других объектов, превращая маленькое расширение в громоздкую структуру. Рассмотрим, различные подходы к изменению типовых форм (поможет утилита для кастомизации и управления элементами форм в пользовательском режиме) и то, как решить эту задачу «минимально инвазивно», сохраняя чистоту кода и архитектуры.

Суть проблемы: лишние объекты в расширении

Давайте проанализируем ситуацию, описанную автором. Задача кажется тривиальной: добавить в типовой документ дополнительную табличную часть. Мы создаем расширение, заимствуем документ (только сам объект, без реквизитов) и форму. В дереве метаданных расширения добавляем новую табличную часть.

Однако, когда мы открываем заимствованную форму в редакторе, мы не видим в дереве реквизитов (справа) нашу новую табличную часть внутри реквизита Объект. Чтобы она появилась, платформа требует добавить в расширение ДокументОбъект (свойства объекта). Как только мы это делаем, механизм проверки целостности ссылок автоматически добавляет в расширение все типы данных, которые используются в реквизитах этого документа. В результате в расширении появляются десятки «лишних» справочников и перечислений. Чтобы контролировать этот процесс, рекомендуется проводить анализ состава расширений и их зависимостей.

Можно ли этого избежать? Да, и для этого существует элегантный программный метод, а также способ очистки метаданных.

Решение 1: Программное добавление элементов формы

Это наиболее профессиональный и «чистый» способ, рекомендованный опытными разработчиками. Идея заключается в том, что нам не нужно видеть табличную часть в визуальном конструкторе формы. Мы добавим её на форму динамически в момент создания формы на сервере. Для упрощения этой работы можно использовать общие функции для программного изменения форм (удобно через конструктор кастомных интерфейсов и рабочих столов).

Рассмотрим алгоритм действий подробно:

  1. В расширении заимствуем сам Документ (пустой, только как контейнер).
  2. Добавляем к нему в расширении новую Табличную часть и её реквизиты.
  3. Заимствуем форму документа, на которой хотим отобразить таблицу.
  4. В модуле заимствованной формы создаем расширение метода ПриСозданииНаСервере. Обычно используется аннотация &НаСервере и тип перехвата После.

Далее напишем код, который создаст таблицу формы и свяжет её с данными объекта. Подобное программное создание колонок в табличной части позволяет сохранить значения в документе, не создавая лишних визуальных связей. Если элементов много, удобно использовать конструктор для программной модификации форм (поможет инструментарий разработчика для программной модификации управляемых форм), работающий по паттерну «Текучий строитель».

Пример программного кода для модуля формы:


&НаСервере
Процедура Расш1_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
    
    // 1. Добавляем саму таблицу на форму
    НоваяТаблица = Элементы.Добавить("МояНоваяТаблица", Тип("ТаблицаФормы"), Элементы.ГруппаСтраницыИлиВкладки);
    НоваяТаблица.ПутьКДанным = "Объект.ДобавленнаяТЧ"; // Важно: указываем путь к ТЧ из расширения
    НоваяТаблица.ПоложениеЗаголовка = ПоложениеЗаголовкаЭлементаФормы.Верх;
    НоваяТаблица.Заголовок = "Дополнительные данные (Расш)";
    
    // 2. Добавляем колонки в эту таблицу
    // Например, добавим колонку "Номенклатура"
    НоваяКолонка = Элементы.Добавить("МояТЧ_Номенклатура", Тип("ПолеФормы"), НоваяТаблица);
    НоваяКолонка.Вид = ВидПоляФормы.ПолеВвода;
    НоваяКолонка.ПутьКДанным = "Объект.ДобавленнаяТЧ.Номенклатура"; // Путь к реквизиту ТЧ
    
    // Добавим числовой реквизит
    НоваяКолонкаКол = Элементы.Добавить("МояТЧ_Количество", Тип("ПолеФормы"), НоваяТаблица);
    НоваяКолонкаКол.Вид = ВидПоляФормы.ПолеВвода;
    НоваяКолонкаКол.ПутьКДанным = "Объект.ДобавленнаяТЧ.Количество";

КонецПроцедуры

Преимущества этого метода:

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

Решение 2: Очистка лишних объектов (Ручной режим)

Если вам сложно писать код построения интерфейса вручную или таблица очень сложная, можно пойти путем «визуального добавления», но с последующей уборкой. Разберем, как это сделать аккуратно.

Когда вы заимствуете ДокументОбъект, платформа 1С помечает все зависимые объекты как контролируемые. Однако многие из них нужны только для обеспечения ссылочной целостности внутри редактора. Вы можете попробовать следующий подход:

  1. Заимствуйте объект целиком, чтобы увидеть ТЧ в редакторе.
  2. Перетащите нужную ТЧ на форму мышкой, настройте колонки.
  3. После этого откройте дерево метаданных расширения. Обратите внимание на множество добавленных справочников.
  4. Попробуйте удалить явно лишние объекты из расширения. Платформа предупредит, если удаляемый объект критически необходим для существования заимствованного реквизита.
  5. В свойствах заимствованных объектов, которые нельзя удалить, снимите флажки «Проверять значение» (Контролировать). Это скажет платформе, что вам не важно соответствие этих объектов объектам основной конфигурации при обновлении.

Также, как справедливо замечено в обсуждении, в дереве метаданных расширения есть кнопка фильтрации (значок воронки), которая показывает только собственные объекты расширения или только измененные. Это помогает визуально отделить «зерна от плевел».

Архитектурный вопрос: Табличная часть или Регистр сведений?

В ходе решения задачи мы также должны рассмотреть важный архитектурный аспект: где хранить данные? Есть два основных подхода:

  1. Табличная часть в расширении.

    Плюсы: Привычная работа для пользователя, данные хранятся вместе с документом, работают транзакции (если документ не записался, данные ТЧ тоже не запишутся).

    Риски: Если расширение будет удалено (даже случайно) или повредится таблица соответствия ID расширения, данные табличной части исчезнут безвозвратно. Физически это отдельная SQL-таблица, которая удаляется командой DROP TABLE при удалении расширения.

  2. Регистр сведений (независимый).

    Плюсы: Данные хранятся в основной конфигурации (если добавить регистр туда) или в независимой таблице. Это более безопасно. При удалении расширения, если регистр был в основной конфигурации, данные останутся.

    Минусы: Сложнее реализация интерфейса. На форме придется программно читать данные из регистра при открытии и писать их при записи документа. Транзакционная целостность требует дополнительного кода.

Рекомендация: Если данные критически важны и не должны зависеть от жизни расширения, рассмотрите вариант создания Регистра Сведений в основной конфигурации (через механизм «Дополнительные сведения» или доработку). Если же требуется быстрое решение с удобным интерфейсом и база регулярно резервируется — табличная часть в расширении (с программным выводом на форму) является отличным современным решением.

Особенности работы с данными расширений

Давайте запомним несколько важных правил безопасности при работе с расширениями данных:

Используя программный подход (Решение 1), вы добьетесь «минимальной инвазивности», о которой говорилось в начале, сохраняя конфигурацию чистой и легкой для поддержки.

← На главную