И Data Transfer Object к структуризации кода, управляемой формы в среде 1С 8.2.

Введение

Начнем с небольшого описания понятия «управляемая форма» и связанных концепций платформы 1С. Знатоки платформы могут пропустить этот раздел.

В 2008 году стала доступна новая версия платформы 1С: Предприятие 8.2 (далее Управляемое приложение), которая полностью меняет весь слой работы с интерфейсом. Сюда относится и командный интерфейс, и формы, и оконная система. При этом не только меняется модель разработки пользовательского интерфейса в конфигурации, но и предлагается новая архитектура разделения функциональности между клиентским приложением и сервером.
Управляемое приложение поддерживает следующие типы клиентов:

• Толстый клиент (обычный и управляемый режим запуска)
• Тонкий клиент
• Веб-клиент

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

• Декларативное, а не «по пикселям» описание структуры. Конкретное размещение элементов выполняется системой автоматически при отображении формы.
• Вся функциональность формы описывается в виде реквизитов и команд . Реквизиты – это данные, с которыми работает форма, а команды – выполняемые действия.
• Форма выполняется и на сервере и на клиенте.
• В контексте клиента, недоступны практически все прикладные типы, и соответственно невозможно изменить данные в информационной базе.
• Для каждого метода или переменной формы обязательно должна быть указана директива компиляции , определяющая, место выполнения (клиент или сервер) и доступ к контексту формы.

Перечислим директивы компиляции методов формы:

• &НаКлиенте
• &НаСервере
• &НаСервереБезКонтекста
• &НаКлиентеНаСервереБезКонтекста

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

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

Обозначим проблему

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

Рассмотрим структуру кода (модуль формы) в нескольких формах одной типовой конфигурации и попробуем найти закономерности.
Под структурой будем понимать секции кода (чаще всего это блоки комментариев) выделенные разработчиком для группировки методов и директивы компиляции этих методов.
Пример 1:
Секция обработчиков событий Метод – наклиенте Метод – насервере Метод - наклиенте Секция служебных процедур и функций Вспомогательные функции управления вводом
Пример 2:
Служебные процедуры и функции Документы оплаты Ценности Обработчики событий
Пример 3:
Служебные процедуры на сервере Служебные процедуры на клиенте Служебные процедуры на сервере без контекста Обработчики событий шапки Обработчики событий команд
Пример 4:
Процедуры общего назначения Обработчики событий формы Процедуры подсистемы «контактная информация»
По сути, структура кода отсутствует, или мягче говоря, она аналогична тому, что было в формах 8.1:

• Неинформативные слова «Общие, Служебные, Вспомогательные».
• Робкие попытки разделить клиентские и серверные методы.
• Часто методы группируются по интерфейсным элементам «Работа с табличной частью Товары, Контактной информацией».
• Произвольное расположение методов и групп кода. Например, Обработчики событий могут быть в одной форме вверху, в другой внизу, в третьей вообще не выделены и т.д.
• И не будем забывать, что это все в рамках одной конфигурации.
• Да бывают конфигурации, в которых слова «Общие, Служебные, Вспомогательные» всегда находятся на одних и тех же местах но…

Зачем нужна структура кода?

• Упрощение сопровождения.
• Упрощение обучения.
• Фиксация общих/важных/удачных принципов.
• …ваш вариант

Почему существующий стандарт разработки от фирмы 1С не помогает?

Посмотрим опубликованные на дисках ИТС и в различных «Пособиях разработчика…» принципы, рекомендуемые при написании управляемой формы.

• Минимизируйте число серверных вызовов.
• Максимум вычислений на сервере.
• Неконтекстные вызовы сервера быстрее контекстных.
• Программируйте с учетом клиент-серверного взаимодействия.
• и т.п.

Это лозунги, абсолютно верные, но как их реализовать? Как минимизировать число вызовов, что значит программировать в клиент-серверном режиме?

Шаблоны проектирования или мудрость поколений

Клиент-серверное взаимодействие используется в различных программных технологиях не один десяток лет. Ответ на обозначенные в предыдущем разделе вопросы давно известен и суммирован в двух базовых принципах.

• Remote Facade (далее Интерфейс удаленного доступа)
• Data Transfer Object (далее Объект переноса данных)

Слово Мартину Фаулеру , его описание данных принципов:

• … каждый объект, потенциально предназначенный для удаленного доступа, должен иметь интерфейс с низкой степенью детализации , что позволит максимально уменьшить количество вызовов, необходимых для выполнения определенной процедуры. … Вместо того, чтобы запрашивать счёт и все его пункты отдельно, надо считать и обновить все пункты счёта за одно обращение. Это влияет на всю структуру объекта.…Запомните: интерфейс удаленного доступа не содержит логики домена .
• …если бы я был заботливой мамой, то обязательно сказал бы своему ребенку: «Никогда не пиши объекты переноса данных!» В большинстве случаев объекты переноса данных представляют собой не более чем раздутый набор полей … Ценность этого омерзительного монстра состоит исключительно в возможности передавать по сети несколько элементов информации за один вызов - прием, который имеет большое значение для распределенных систем.

Примеры шаблонов в платформе 1С

Прикладной программный интерфейс доступный разработчику при разработке управляемой формы, содержит много примеров данных принципов.
Например метод ОткрытьФорму(), типичный «огрубленный» интерфейс.
ПараметрыОткрытия = Новый Структура("Параметр1, Параметр2, Параметр3", Значение1, Значение2, Значение3); Форма = ОткрытьФорму(ИмяФормы, ПараметрыОткрытия);
Сравните с принятым в v8.1 стилем.
Форма = ПолучитьФорму(ИмяФормы); Форма.Параметр1 = Значение1; Форма.Параметр2 = Значение2; Форма.Открыть();

В контексте управляемой формы множество «Объектов переноса данных». Можно выделить системные и определяемые разработчиком .
Системные моделируют на клиенте прикладной объект, в виде одного или несколько элементов данных формы. Создать их вне привязки к реквизитам формы нельзя.

• ДанныеФормыСтруктура
• ДанныеФормыКоллекция
• ДанныеФормыСтруктураСКоллекцией
• ДанныеФормыДерево

Преобразование системных объектов переноса данных в прикладные типы и обратно выполняется методами:

• ЗначениеВДанныеФормы()
• ДанныеФормыВЗначение()
• КопироватьДанныеФормы()
• ЗначениеВРеквизитФормы()
• РеквизитФормыВЗначение()

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

Объекты переноса данных, структура которых определяется разработчиком это небольшое подмножество типов доступных и на клиенте и на сервере. Наиболее часто в качестве параметров и результатов методов «огрубленного» интерфейса используются:

• Примитивные типы (строка, число, булево)
• Структура
• Соответствие
• Массив
• Ссылки на прикладные объекты (уникальный идентификатор и текстовое представление)

Пример: метод принимает список заказов для изменения статуса и возвращает клиенту описание ошибок.
&НаСервереБезКонтекста Функция СерверИзменитьСтатусЗаказов(Заказы, НовыйСтатус) Ошибки = Новый Соответствие(); // [заказ][описание ошибки] Для Каждого Заказ Из Заказы Цикл НачатьТранзакцию(); Попытка ДокОб = Заказ.ПолучитьОбъект(); …. другие действия, возможно не только с заказом… Исключение ОтменитьТранзакцию(); Ошибки.Вставить(Заказ, ОписаниеОшибки()); КонецПопытки; КонецЦикла; Возврат Ошибки; КонецФункции // СерверИзменитьСтатусЗаказов()

Структурируем код

Главные цели, которые должен отражать модуль управляемой формы и подходы к решению.

• Четкое разделение клиентского и серверного кода. Не будем забывать, в момент выполнения это два взаимодействующих процесса, в каждом из которых существенно отличается доступный функционал.
• Четкое выделение интерфейса удаленного доступа, какие методы сервера можно вызывать с клиента, а какие нельзя? Названия методов удаленного интерфейса начинаются с префикса «Сервер». Это позволяет, читая код сразу видеть переход управления на сервер, и упрощает использование контекстной подсказки. Отметим, что официальная рекомендация (ИТС) предлагает именовать методы с постфиксами, например, так ИзменитьСтатусЗаказовНаСервере(). Однако повторим не все серверные методы можно вызывать с клиента, и поэтому более важна логическая доступность, а не место компиляции. Поэтому префиксом «Сервер» отмечаем только методы доступные для клиента, метод-пример назовем СерверИзменитьСтатусЗаказов().
• Удобочитаемость. Дело вкуса, принимаем порядок, когда модуль начинается с процедур создания формы на сервере и методов удаленного доступа.
• Сопровождаемость. Должно быть однозначно определено место для добавления нового кода. Важный момент, автоматически создаваемые конфигуратором заготовки методов добавляются в конец модуля. Т.к чаще всего автоматически создаются обработчики событий элементов формы, то соответствующий блок расположен последним, чтобы не перетаскивать каждый обработчик в другое место модуля.

Ниже приведена базовая структура модуля, реализующая перечисленные цели.

• Графический вариант – наглядно показывает основной поток выполнения.
• Текстовый вариант - это пример оформления шаблона для быстрой вставки структуры в новый модуль формы.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="" Дата=""/> // <Описание> // // //////////////////////////////////////////////////////////////////////////////// // ПЕРЕМЕННЫЕ МОДУЛЯ //////////////////////////////////////////////////////////////////////////////// // НА СЕРВЕРЕ //******* СОБЫТИЯ НА СЕРВЕРЕ ******* &НаСервере Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка) //Вставить содержимое обработчика КонецПроцедуры //******* ИНТЕРФЕЙС УДАЛЕННОГО ДОСТУПА ******* //******* БИЗНЕС-ЛОГИКА НА СЕРВЕРЕ ******* //////////////////////////////////////////////////////////////////////////////// // ОБЩИЕ МЕТОДЫ КЛИЕНТА И СЕРВЕРА //////////////////////////////////////////////////////////////////////////////// // НА КЛИЕНТЕ //******* БИЗНЕС-ЛОГИКА НА КЛИЕНТЕ ******* //******* КОМАНДЫ ******* //******* СОБЫТИЯ НА КЛИЕНТЕ ******* //////////////////////////////////////////////////////////////////////////////// // ОПЕРАТОРЫ ОСНОВНОЙ ПРОГРАММЫ

Связанные вопросы

В заключение обозначим несколько направлений, о которых полезно подумать при программировании клиент-серверного взаимодействия.

• Варианты реализации интерфейса удаленного доступа . Асинхронность, степень детализации...
• Кэширование. В 1С приняли неудачное архитектурное решение, введя кэширование только на уровне вызова методов общих модулей и не предоставив возможности управления (время актуальности, сброс по требованию).
• Неявные серверные вызовы . Не забывайте о технологических особенностях, многие «безобидные» операции на клиенте провоцируют платформу на обращение к серверу.

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

ЭтаФорма

Используется в модуле формы, в процедурах &НаКлиенте и &НаСервере .

Позволяет обращаться и к элементам формы и к реквизитам.

Обращение к элементу формы происходит через объект Элементы и выглядит так:

ЭтаФорма.Элементы.НомерВерсии.Заголовок = "v."+ВерсияПрограммы;

Обращение к реквизиту, существующему на форме, происходит так:

ЭтаФорма.ТекстОбъявления="Здравствуйте, товарищи!";

Упрощенное обращение к элементам формы и реквизитам

В модуле формы, в принципе, можно не указывать ключевое слово ЭтаФорма . Можно обращаться к элементам формы и к реквизитам упрощенно:

// Элемент формы

Элементы.НомерВерсии.Заголовок = "v."+ВерсияПрограммы;

// Реквизит формы

ТекстОбъявления="Здравствуйте, товарищи!";

Особенности получения реквизитов форм (важно!)

Если реквизит формы имеет простой тип - Строка , Число , Дата ... то получить (установить) значение реквизита можно просто по имени:

Текст=НаименованиеТовара; // Наименование товара - это реквизит формы

Однако, таким образом невозможно получить реквизиты "сложного" типа - ТаблицаЗначений , ДеревоЗначений . При попытке получить реквизит с таким типом по наименованию, будет возвращен объект типа ДанныеФормыКоллекция .

Чтобы получить значение реквизита со "сложным" типом, нужно воспользоваться функцией РеквизитФормыВЗначение() :

ТекущаяТаблица=РеквизитФормыВЗначение("ВыбранныеОбъектыСтроительства");

Для установки значения "сложного" реквизита, можно воспользоваться функцией ЗначениеВРеквизитФормы(<Значение>, <ИмяРеквизита>) , оба параметра обязательны.

Функции РеквизитФормыВЗначение() и ЗначениеВРеквизитФормы() доступны только на Сервере.

Объект

Строго говоря, такого ключевого слова в пределах формы нет. Просто, когда создается форма, например, форма элемента, 1С автоматически создает на форме реквизит с именем Объект . Через данный реквизит доступны свойства текущего объекта, который редактируется на форме.

или, более полная запись:

ЭтотОбъект

Содержит сам объект. Предназначено для получения объекта в модуле объекта или модуле формы.

Использование: Только чтение.

Доступность: Сервер, толстый клиент, внешнее соединение.

Общий реквизит в 1С 8.3 — это объект метаданных платформы, позволяющий использовать один реквизит для многих объектов конфигурации (справочников, документов, планов счетов и т.д). Объект создан в основном для облегчения труда разработчика и разделения данных.

Общие реквизиты были первоначально реализованы в версии 1С 7.7, но сразу в платформу 8 версии разработчики его не включили. Механизм общих реквизитов был введен разработчиками 1С только в релизе 8.2.14.

Общие реквизиты очень удобно добавлять, чтобы не изменять стандартные объекты в конфигурации, я часто их использую наряду с .

После добавления общего реквизита его можно использовать и в запросах и выводить на форму объектов — внешне он ничем не отличается от обычного реквизита.

Единственное ограничение общих реквизитов — невозможность использования их в .

Рассмотрим основные настройки и свойства общих реквизитов, отличные от других объектов конфигурации:

Состав — список объектов, к которым будет использован общий реквизит, настройка напоминает настройку плана обмена.

Получите 267 видеоуроков по 1С бесплатно:

Автоиспользование — настройка определяет, будет ли использоваться общий реквизит для тех объектов, у которых в составе указан режим использования «Автоматический».

Разделение данных — эту настройку рассмотрим отдельно.

Разделение данных в 1С с помощью общего реквизита

Разделение данных — механизм, аналогичный механизму . Однако производительность данного механизма более эффективна, и он настраивается проще.

Механизм позволяет настроить отображение только элементов, которые может видеть пользователь. К примеру, можно разграничить все объекты (документы, справочники и т.д.), где установлена определенная организация.

Настройка разделения данных с помощью общих реквизитов 1С

Для настройки в общем реквизите необходимо указать разделение данных — Разделять . Сразу после нажатия система предложит создать параметры учета по умолчанию:

При этом необходимо будет при старте системы указать параметры сеанса, как это сделать, с примером было описано в статье .

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

Пример использования общего реквизита

Разберем настройку общего реквизита в 1С 8.3 на примере каркасной конфигурации и реквизита Организация:

В системе имеется 3 документа, где необходимо указание реквизита Организация: это Приходная Накладная, Расходная Накладная, Начисление Зарплаты.

Настройка проста:

1. Создаем новый Общий реквизит, указываем тип — СправочникСсылка.Организация.
2. В составе расставляем для наших документов — Использовать .

Все, настройка окончена!

Смотрим результат:

Система отображает общий реквизит «как свой»: и в запросах, и в реквизитах формы, и в других местах. Вот такое волшебство! 🙂

Не добавляется общий реквизит 1С 8.3

Как добавить дополнительный реквизит к элементу справочника в 1С Бухгалтерия 8.3 (редакция 3.0)

2016-12-07T18:20:33+00:00

Бывает так, что нам не хватает возможностей уже имеющихся в 1С. И не всегда при этом нужно обращаться к программисту. Я расскажу про один из таких случаев применительно к новой 1С:Бухгалтерия 8.3 (редакция 3.0).

Пусть нам не хватает полей для внесения информации о наших контрагентах. И мы хотим добавить новое поле, которое будет называться "Статус" и иметь одно из трёх значений - "Высокий", "Средний" и "Низкий". О том как добавить такое поле, не заходя в конфигуратор, я расскажу ниже по шагам.

1. Зайдите в раздел "Администрирование" и выберите там пункт "Общие настройки" ():

2. Найдите и установите галку "Дополнительные реквизиты и сведения", если она ещё не установлена. Нажмите ссылку "Дополнительные реквизиты":

3. В левой части открывшегося окна настроек выберите пункт "Контрагент". Нажмите кнопку "Создать" на панели инструментов.

4. Открылось окно создания нового реквизита для элементов справочника "Контрагенты". Введите "Статус" в поле Наименование. В качестве типа значения оставьте "Дополнительное значение", хотя на будущее учтите, что возможны и другие типы значений (строка, число, дата и прочее). Но нам нужно сейчас именно дополнительно значение, так как мы хотим предоставить пользователю ограниченный выбор из трёх вариантов.

5. Для создания каждого из вариантов перейдите на закладку "Значения", нажмите там кнопку "Создать", введите наименование значения (например, "Высокий") и нажмите кнопку "Записать и закрыть".

6. И так пока не создадутся все три значения с названиями "Высокий", "Средний" и "Низкий" как показано на рисунке ниже. Нажмите кнопку "Записать и закрыть".

7. Как видите, в списке дополнительных реквизитов у Контрагента появился реквизит Статус.

8. Теперь, если мы зайдем в любой элемент справочника контрагенты, мы увидим в самом низу формы новое поле Статус ( если не видите - раскройте свёрнутую на форме группу "Дополнительные реквизиты" ):

9. В это поле мы можем подставить одно из трёх значений, созданных нами. По этому полю можно делать отбор в форме списка, его можно выводить в отчеты и прочее.

Реквизиты формы

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

Важно! Необходимо помнить, что, в отличие от обычных форм, все данные управляемой формы должны быть описаны в виде реквизитов. Не допускается использование переменных модуля формы в качестве источников данных для элементов формы.

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

Расширение формы – это дополнительные свойства, методы и параметры формы объекта УправляемаяФорма, характерные для объекта, являющегося основным элементом формы.

В процессе разработки формы можно явно задать возможность просмотра и редактирования конкретных реквизитов формы, в разрезе ролей, с помощью свойств Просмотр и Редактирование (подробнее смотрите раздел «Ролевая настройка формы» главы «Редакторы»). Кроме того, доступность того или иного реквизита в самой форме можно настраивать с помощью функциональных опций (подробнее о функциональных опциях можно посмотреть в главе «Управление интерфейсом конфигурации»).

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

Типы данных, доступные в управляемой форме

Управляемая форма отличается от обычной формы также и типами данных, с которыми она работает. Если обычная форма работает с большинством типов, которые предоставляет 1С:Предприятие (в том числе и вида СправочникОбъект, ДокументОбъект и т. д.), то в управляемой форме можно выделить следующие категории типов:

• типы, которые непосредственно используются в форме – это те типы, которые существуют на стороне тонкого и Веб-клиента (например, Число, СправочникСсылка.Товары, ГрафическаяСхема, ТабличныйДокумент);

• типы, которые будут преобразованы в специальные типы данных – типы данных управляемой формы. Такие типы отображаются в списке реквизитов формы в круглых скобках, например (СправочникОбъект.Товары);

• динамический список (подробнее см. раздел «Динамический список» данной главы).

Преобразование прикладных объектов в данные формы

Некоторые прикладные типы (такие как СправочникОбъект и т. д.) не существуют на стороне тонкого и Веб-клиентов (подробнее см. главу «Концепция управляемого приложения»). Поэтому для представления в форме таких прикладных типов в платформе введены специальные типы данных, предназначенные для работы в управляемых формах. Эта особенность управляемого приложения обуславливает необходимость выполнять преобразование прикладных объектов в данные формы (и обратно).

Используются следующие типы данных:

• ДанныеФормыСтруктура – содержит набор свойств произвольного типа. Свойствами могут быть другие структуры, коллекции или структуры с коллекциями. Таким типом представляется, например, в форме СправочникОбъект.

• ДанныеФормыКоллекция – это список типизированных значений, похожий на массив. Доступ к элементу коллекции осуществляется по индексу или по идентификатору. Доступ по идентификатору может отсутствовать в некоторых случаях. Это обусловлено типом прикладного объекта, который представлен этой коллекцией. Идентификатором может быть любое целое число. Таким типом представляется, например, в форме табличная часть.

• ДанныеФормыСтруктураСКоллекцией – это объект, который представлен в виде структуры и коллекции одновременно. С ним можно обращаться как с любой из этих сущностей. Таким типом представляется, например, в форме набор записей.

• ДанныеФормыДерево – объект предназначен для хранения иерархических данных.

Прикладной объект представлен либо одним, либо несколькими элементами данных формы. В общем виде иерархия и состав данных формы зависят от сложности и взаимосвязи прикладных объектов управляемой формы.

Например, документ, содержащий табличную часть, будет представлен объектом типа ДанныеФормыСтруктура (собственно документ), которому подчинен объект типа ДанныеФормыКоллекция (табличная часть документа).

Важно! Во время разработки конфигурации важно помнить, что прикладные объекты доступны только на сервере, в то время как объектами данных форм можно пользоваться и на сервере, и на клиенте.

Передача данных между клиентской и серверной частями управляемой формы

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

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

• Для реквизита, подчиненного динамическому списку (колонке динамического списка):
  • свойство включено – реквизит всегда считывается из базы данных и включается в данные формы;
  • свойство выключено – реквизит считывается из базы данных и включается в данные формы только тогда, когда есть видимый в данный момент элемент формы, связанный с реквизитом или его подчиненным реквизитом.

• Для реквизита, подчиненного коллекции движений:
  • свойство включено – движения документа считываются из базы данных и будут присутствовать в данных формы;
  • свойство выключено – движения документа не будут считываться из базы данных и не попадут в данные формы (если нет элемента формы, ссылающегося на движения документа).

• Остальные реквизиты формы:
  • свойство включено – реквизит будет присутствовать в данных формы вне зависимости от того, есть или нет хоть один элемент формы, который связан с реквизитом или его подчиненным реквизитом;
  • свойство выключено – реквизит будет присутствовать в данных формы только в том случае, если есть элемент формы, связанный с реквизитом или его подчиненным реквизитом. В отличие от реквизитов динамического списка, здесь не играет роли видимость элемента, связанного с реквизитом.

Примечание. Следует помнить, что свойство, установленное у родительского реквизита, действует на все подчиненные реквизиты. Например, если свойство Использовать всегда снято у табличной части документа, то система считает, что это свойство снято и у всех подчиненных реквизитов (несмотря на фактическое состояние свойства).

Методы для преобразования данных прикладных объектов в данные формы

Для конвертирования прикладных объектов в данные формы и обратно существует набор глобальных методов:

• ЗначениеВДанныеФормы(),
• ДанныеФормыВЗначение(),
• КопироватьДанныеФормы().

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

Во время конвертирования данных формы в прикладной объект нужно учитывать их совместимость.

• ЗначениеВДанныеФормы() – преобразует объект прикладного типа в данные формы;
• ДанныеФормыВЗначение() – преобразует данные формы в объект прикладного типа;
• КопироватьДанныеФормы() – производит копирование данных формы, обладающих совместимой структурой. Возвращает значение Истина, если копирование произведено, или Ложь, если структура объектов несовместима.

Примечание. При выполнении стандартных действий (открытие формы, выполнение стандартной команды Записать и т. д.) формы с основным реквизитом, преобразование выполняется автоматически.

Приведем пример, как использовать преобразование данных в собственных алгоритмах.

&НаСервере Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)

ОбъектТовар = Справочники.Товары.НайтиПоНаименованию(«Кофейник»).ПолучитьОбъект(); ЗначениеВДанныеФормы(ОбъектТовар, Объект);

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

&НаКлиенте Процедура Записать()

ЗаписатьНаСервере();

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

&НаСервере Процедура ЗаписатьНаСервере()

ОбъектТовар = ДанныеФормыВЗначение(Объект, Тип(«СправочникОбъект.Товары»)); ОбъектТовар.Записать();

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

Также у объекта УправляемаяФорма существуют методы, доступные на сервере:

• ЗначениеВРеквизитФормы() – выполняет преобразование объекта прикладного типа в заданный реквизит формы.
• РеквизитФормыВЗначение() – преобразует реквизит данных формы в объект прикладного типа.

Использование данных методов обычно удобнее, так как они, имеют, например, информацию о типе реквизита формы. Кроме того, метод РеквизитФормыВЗначение() выполняет установку соответствия данных формы и объекта, которая используется при формировании сообщений. Подробнее об этом можно прочитать в главе «Сервисные возможности навигации».

Приведем пример использования этих методов.

&НаСервере Процедура ПересчитатьНаСервере()

// Преобразует реквизит Объект в прикладной объект. Документ = РеквизитФормыВЗначение(«Объект»); // Выполняет пересчет методом, определенным в модуле документа. Документ.Пересчитать(); // Преобразует прикладной объект обратно в реквизит. ЗначениеВРеквизитФормы(Документ, «Объект»);

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

Программный интерфейс

ДанныеФормыДерево (FormDataTree)

• НайтиПоИдентификатору (FindById)
• ПолучитьЭлементы (GetItems)

Описание:

Предназначен для моделирования дерева в данных управляемой формы.

Данный объект может быть сериализован в/из XDTO. Тип XDTO, соответствующий данному объекту определяется в пространстве имен. Имя типа XDTO:

ПолучитьЭлементы (GetItems)

Синтаксис:

ПолучитьЭлементы()

Возвращаемое значение:

Тип: ДанныеФормыКоллекцияЭлементовДерева.

Описание:

Получает коллекцию элементов дерева верхнего уровня.

Доступность: клиент, сервер, тонкий клиент, веб-клиент.

НайтиПоИдентификатору (FindById)

Синтаксис:

НайтиПоИдентификатору(<Идентификатор>)

Параметры:

<Идентификатор> (обязательный)

Тип: Число. Идентификатор элемента дерева.

Возвращаемое значение:

Тип: ДанныеФормыЭлементДерева.

Описание:

Получает элемент коллекции по идентификатору.

Доступность: клиент, сервер, тонкий клиент, веб-клиент.

ДанныеФормыЭлементДерева (FormDataTreeItem)

Свойства:

<Имя свойства> (<Имя свойства>)

• ПолучитьИдентификатор (GetId)
• ПолучитьРодителя (GetParent)
• ПолучитьЭлементы (GetItems)
• Свойство (Property)

Описание:

Элемент дерева данных формы.

ДанныеФормыКоллекцияЭлементовДерева (FormDataTreeItemCollection)

Элементы коллекции: ДанныеФормыЭлементДерева

Для объекта доступен обход коллекции посредством оператора Для каждого … Из … Цикл. При обходе выбираются элементы коллекции. Возможно обращение к элементу коллекции посредством оператора [...]. В качестве аргумента передается индекс элемента.

• Вставить (Insert)
• Добавить (Add)
• Индекс (IndexOf)
• Количество (Count)
• Очистить (Clear)
• Получить (Get)
• Сдвинуть (Move)
• Удалить (Delete)

Описание:

Коллекция элементов дерева.

Доступность: клиент, сервер, тонкий клиент, веб-клиент.

См. также:

• ДанныеФормыЭлементДерева, метод ПолучитьЭлементы
• ДанныеФормыДерево, метод ПолучитьЭлементы

Особенности работы с деревом значений

Обновление дерева

Существует проблема падения платформы при обновлении дерева.

Если в дереве был развернут какой-либо узел и выбран подчиненный узел, то при обновлении дерева функцией ЗначениеВДанныеФормы происходит падение платформы.

Решение: перед обновлением нужно очищать дерево.

Например:

&НаСервере Процедура ОчиститьДерево(элементы) Для каждого элемент из элементы Цикл ОчиститьДерево(элемент.ПолучитьЭлементы()); КонецЦикла; элементы.Очистить(); КонецПроцедуры

&НаСервере Процедура ЗаполнитьДеревоПонятий() дзПонятия = срСвойства.ПостроитьДеревоПонятий(НаДату, Мета.ТекущаяИБ()); ОчиститьДерево(ДеревоПонятий.ПолучитьЭлементы()); ЗначениеВДанныеФормы(дзПонятия, ДеревоПонятий); КонецПроцедуры

&НаКлиенте Процедура НаДатуПриИзменении(Элемент) ЗаполнитьДеревоПонятий(); КонецПроцедуры