И 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С начиная с версии 8.2.

Стандартные хранилища настроек

Итак, по умолчанию, в конфигурации имеются следующие хранилища настроек:

• ХранилищеВариантовОтчетов — для доступа к настройкам вариантов отчетов.
• ХранилищеПользовательскихНастроекОтчетов — для доступа к пользовательским настройкам отчетов.
• ХранилищеНастроекДанныхФорм — для доступа к пользовательским настройкам данных форм.
• ХранилищеОбщихНастроек — для доступа к общим настройкам.
• ХранилищеСистемныхНастроек — для доступа к системным настройкам.
• ХранилищеПользовательскихНастроекДинамическихСписков — для доступа к пользовательским настройкам динамических списков.

К каждому из этих хранилищ можно обратиться как к свойству глобального контекста.

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

Для работы с хранилищами настроек (как со стандартными, так и с добавленными программистом) используются следующие методы.

Запись и получение настройки:

ХранилищеОбщихНастроек.Сохранить(НазваниеОбъекта, НазваниеНастройки, ЗначениеНастройки, ОписаниеНастройки, ИмяПользователя); ЗначениеНастройки = ХранилищеОбщихНастроек.Загрузить(НазваниеОбъекта, НазваниеНастройки, ОписаниеНастройки, ИмяПользователя);

Удаление лишней/ненужной настройки:

ХранилищеОбщихНастроек.Удалить(НазваниеОбъекта, НазваниеНастройки, ИмяПользователя);

Получение списка настроек:

СписокЗначенийНастроек = ХранилищеОбщихНастроек.ПолучитьСписок(ИмяОбъекта, ИмяПользователя);

Параметры «НазваниеОбъекта», «НазваниеНастройки» и «ИмяПользователя» должны строковой тип.

В базе данных, все настройки хранятся в отдельно таблице.

Хранилища настроек создаваемые программистом

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

• необходимо перемещение настроек между базами данных;
• необходим ссылочный контроль при хранении настроек;
• требуется особая структура настроек 1С.

Хранилища настроек добавляют в соответствующем разделе конфигурации.

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

В остальном же, принципы работы с созданным хранилищем практически не отличается от работы со стандартными хранилищами настроек.

Доступ к созданному хранилищу можно получить таким образом:

ХранилищаНастроек.НазваниеХранилища.Загрузить();

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

Управляемые формы имеют два свойства:

• Автоматическое сохранение данных — если выбрано значение «Использовать», то данные будут сохраняться автоматически в стандартное хранилище настроек данных форм;
• Сохранение данных в настройках — если выбрано значение «Использовать список», то в окне реквизитов формы появится столбец «Сохранение», с помощью которого можно указать какие реквизиты формы должны сохраняться, а также появиться возможность выбрать хранилище настроек для этих данных.

На этом все, надеюсь данная статья Вам помогла.

Платформа 1С:Предприятие позволяет программно добавлять и изменять элементы управляемой формы. Разберемся для чего это может потребоваться.

Программная модификация формы может потребоваться в нескольких случаях:

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

В управляемой форме можно программно добавить, изменить и удалить:

• реквизиты;
• локальные команды;
• элементы.

Все указанные операции возможны только на сервере.

Программное изменение формы имеет ограничения:

• Удалить можно только программно добавленные реквизиты/команды/элементы. Нельзя программно удалить объекты, созданные в конфигураторе.
• Нельзя назначить реквизит основным.

Изменение команд формы

Для управления составом команд у объекта УправляемаяФорма есть коллекция Команды

Добавить(< ИмяКоманды >)

Количество ()

Найти(< ИмяКоманды >)

Удалить(< Команда >)

Коллекция Команды доступна как на клиенте, так и на сервере. Изменять коллекцию (методы Добавить () и Удалить () ) можно только на сервере. Искать и получать количество элементов (методы Найти () и Количество () ) можно как на клиенте, так и на сервере.

В качестве примера работы с командами формы создадим новую команду ИсторияИзменений с заголовком «История изменений…», которая будет вызвать обработчик ОтобразитьИсторию () . Создание выполняется при открытии формы.

&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
Команда = Команды. Добавить(«ИсторияИзменений» );
Команда. Действие = ;
Команда. Заголовок = «История изменений…» ;
КонецПроцедуры
&НаКлиенте
Процедура Подключаемый_ОтобразитьИсторию(Команда )
// действия команды
КонецПроцедуры

Обработчик команды должен располагаться в форме и иметь директиву компиляции &НаКлиенте .

Изменение реквизитов формы

Чтение состава реквизитов формы выполняется функцией ПолучитьРеквизиты (< Путь >) , возвращающей массив типа РеквизитФормы . Параметр функции указывает путь к родительскому реквизиту (в виде строки). Если параметр опущен или указана пустая строка, возвращаются реквизиты верхнего уровня.

Изменение реквизитов выполняется методом ИзменитьРеквизиты (<ДобавляемыеРеквизиты >, <УдаляемыеРеквизиты >) объекта УправляемаяФорма . В параметры ДобавляемыеРеквизиты и УдаляемыеРеквизиты передаются массивы с элементами типа РеквизитФормы .

Внимание!

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

Создадим новый реквизит формы с именем Покупатель:

ДобавляемыеРеквизиты = Новый Массив;
ДобавляемыеРеквизиты. Добавить(Новый РеквизитФормы («Покупатель», Новый ОписаниеТипов («СправочникСсылка.Контрагенты»), «Клиент»));

// Изменения состава реквизитов
);

Изменение элементов формы

Для управления составом элементов у объекта УправляемаяФорма есть коллекция Элементы . У коллекции есть несколько методов:

Вставить(< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

Добавить(< Имя>, < ТипЭлемента>, < Родитель >)

Количество ()

Найти(< Имя >)

Переместить(< Элемент>, < Родитель>, < МестоРасположения >)

Удалить(< Элемент >)

Коллекция Элементы доступна как на клиенте, так и на сервере. Изменять коллекцию (методы Вставить() , Добавить () , Переместить () и Удалить () ) можно только на сервере. Искать и получать количество элементов (методы Найти () и Количество () ) можно как на клиенте, так и на сервере. Элементами коллекции могут быть:

• ГруппаФормы;
• ТаблицаФормы;
• ПолеФормы;
• КнопкаФормы.

Элементам формы можно программно назначить обработчики событий. Для этих целей предназначен метод УстановитьДействие(< ИмяСобытия>, < Действие >) .

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

Добавление команды и связанной с ней кнопки:

// Создание команды
Команда = Команды. Добавить(«ИсторияИзменений» );
Команда. Действие = «Подключаемый_ОтобразитьИсторию» ; // В форме должна быть процедура с указанным наименованием
Команда. Заголовок = «История изменений…» ;
// Создание кнопки и связь ее с командой
Элемент = Элементы. Добавить(«ИсторияИзменений» , Тип(«КнопкаФормы» ));
Элемент.ИмяКоманды = «ИсторияИзменений» ;

Добавление реквизита и связанного с ним поля ввода:

// Описание добавляемых реквизитов
ДобавляемыеРеквизиты = Новый Массив;
ДобавляемыеРеквизиты. Добавить (Новый РеквизитФормы («Покупатель» , Новый ОписаниеТипов («СправочникСсылка.Контрагенты» ), «Клиент» ));
// Изменение состава реквизитов
ИзменитьРеквизиты(ДобавляемыеРеквизиты );
// Создание поля ввода и связь с реквизитом
Элемент = Элементы. Добавить(«Покупатель» , Тип(«ПолеФормы» ));
Элемент. Вид = ВидПоляФормы. ПолеВвода;
Элемент. ПутьКДанным = «Покупатель» ;

Назначение элементу формы обработчика события:

ЭлементПокупатель. УстановитьДействие («ПриИзменении» , «Подключаемый_ПокупательПриИзменении» );

&НаКлиенте
Процедура Подключаемый_ПокупательПриИзменении (Элемент )
// Действия события
КонецПроцедуры

Внимание!

Процедурам, которые устанавливаются в качестве обработчиков событий из кода с помощью метода УстановитьДействие() , рекомендуется задавать префикс Подключаемый_.

Внимание!

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

Формы, существующие в «1С:Предприятии», предназначены для интерактивной работы пользователя с данными информационной базы. Для обеспечения этой возможности форма «наполняется» необходимой функциональностью.

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

Связь между командами, реквизитами и элементами формы

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

• определяет состав формы в виде дерева элементов
• описывает поведение формы, задавая значения для ее свойств и/или реализуя процедуры на встроенном языке.

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

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

Функциональность по умолчанию

В «1С:Предприятии» можно не создавать формы для представления и обработки объектов данных. В этом случае при выполнении команд открытия форм система самостоятельно на лету создаст необходимую форму. Созданная форма будет обладать функциональностью и представлением по умолчанию. Что же определяет представление и функциональность формы?
Стандартное представление и функциональность формы определяют интерфейсный объект «Управляемая форма» (например, способность формы закрываться) и расширение формы (например, способность записывать данные формы в информационную базу).
Расширение формы – это дополнительные свойства, методы, параметры и команды, которые появляются у объекта Форма, когда ей назначен основной реквизит.

ВНИМАНИЕ!
В качестве основного может быть выбран только один реквизит
из состава реквизитов формы.

Важно понимать, что:

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

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

Команды формы

Для знакомства с командами формы создадим еще одну форму для документа Расход товара. Из контекстного меню узла Формы этого документа выберем пункт Добавить.

Добавление подчиненной формы

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

Окно конструктора формы

1С8: Окно конструктора формы

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

Редактор формы с автоматически созданной формой документа

ПРИМЕЧАНИЕ
В редакторе форм основной реквизит формы выделяется жирным шрифтом.

Если открыть документ Расход товара в режиме 1С:Предприятие, мы увидим, что для работы с документом используется созданная нами форма .

Форма редактирования документа «Расход товара»

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

Для обработки данных формы – стандартные команды форм ы

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

Стандартные команды формы в редакторе и интерфейсе

1С8: Стандартные команды формы в редакторе и интерфейсе

Эти команды предоставлены формой и расширением формы. Состав команд, предоставляемых формой, является стандартным и не зависит от данных формы – это команды:

• Справка
• Изменить форму…
• Закрыть
• Сохранить параметры…
• Восстановить параметры…

Состав команд, предоставляемых расширением, зависит от типа основного реквизита формы. В нашем случае основным реквизитом формы назначен реквизит Объект с типом данных ДокументОбъект.РасходТовара (см. рис. выше) Расширение, соответствующее этому типу данных, предоставило команды:

• Провести и закрыть
• Записать
• Перечитать
• Скопировать
• Пометить на удаление
• Снять пометку удаления
• Удалить
• Провести
• Отмена проведения.

ВНИМАНИЕ!
Необходимо различать стандартные команды объекта конфигурации и стандартные команды формы. Первые используются в глобальном командном интерфейсе и предоставляются объектом конфигурации. Вторые же используются в форме и предоставляются самой формой, ее расширением и расширениями элементов формы, имеющих тип Таблица.

Для облегчения разработки алгоритмов управления формами в стандартные команды формы включены команды:

• Нет,
• Отмена,
• Прервать,
• Пропустить,
• Повторить.

Если такая команда добавлена в форму, то при ее выборе пользователем выполняются следующие действия:

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

Если в составе элементов формы присутствуют таблицы, то в состав стандартных локальных команд формы добавляются команды, обеспечивающие обработку данных, отображаемых в этих элементах. У документа Расход товара есть табличная часть, которая в данных формы представлена реквизитом Товары. Для отображения списка товаров в форме используется элемент Товары, имеющий тип Таблица. В состав стандартных локальных команд формы включены команды обработки табличных данных – узел Товары в редакторе команд.

Стандартные команды таблицы в редакторе и интерфейсе

Для работы со связанными данными – глобальные параметризованные команды

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

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

Глобальные параметризуемые команды в редакторе и интерфейсе

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

Глобальные независимые команды в редакторе и интерфейсе

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

Способы формирования состава команд формы

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

ПРИМЕЧАНИЕ
Для формы есть еще один источник команд – разработчик, который может создавать произвольные локальные команды формы. Об этих командах мы поговорим немного позже (см. «Если не хватает стандартных команд»).

В самом общем случае существует три варианта:

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

Автоматический вариант является самым быстрым и наименее затратным с точки зрения разработки прикладного решения – система все делает самостоятельно. Комбинированный вариант, вероятно, используется чаще всего. При таком подходе разработчик вмешивается в работу системы только тогда, когда набор команд, сформированный системой, не обеспечивает требуемых функциональных возможностей по обработке данных формы. В подавляющем большинстве случаев вмешательство выражается в простом расширении состава команд формы. Ручной же вариант предоставляет максимум возможностей по управлению составом команд формы и их размещением. Однако он требует от разработчика выполнения значительного объема кропотливой работы.