Какие есть свойства у управляемой формы
Рассмотрены следующие отличительные особенности управляемых форм:
• Форма существует и на клиенте и на сервере.
Она осуществляет клиент-серверное взаимодействие
• Форма не работает с прикладными объектами
В форме используются специальные универсальные объекты ДанныеФормы
В управляемых формах на первый план выходит разделение контекста на клиентский и серверный. Для возможности работы по тонким каналам связи вся работа прикладных объектов теперь выполняется только на сервере. На клиенте отображается уже подготовленная на сервере форма, выполняется ввод данных и вызовы сервера для записи введенных данных и других необходимых действий
В модуле управляемой формы возможно объявление переменных, процедур и функций. Так как управляемая форма существует одновременно и на сервере и на клиенте, то каждая процедура и функция и объявление переменной должны предваряться директивой компиляции, определяющей среду исполнения.
Допустимы следующие директивы:
&НаКлиенте — Означает, что метод выполняется на стороне клиента, а переменная существует все время жизни клиентской части формы. Клиентская процедура исполняется в среде клиентского приложения. Доступны: Свойства и методы глобального контекста, доступные на клиенте; экспортные переменные; процедуры и функции модуля управляемого приложения, общих модулей скомпилированных на клиенте, общих модулей скомпилированных на сервере, если у них установлено свойство «Вызов Сервера»; свойства и методы расширения формы, определяемого основным реквизитом; свойства и методы объекта встроенного языка УправляемаяФорма; реквизиты формы; локальный контекст модуля.
&НаСервере — Означает, что метод выполняется на стороне сервера, а переменная существует только во время выполнения серверного вызова, при каждом серверном вызове значение переменной сбрасывается. Для серверных методов допустимы вызовы серверных, серверных внеконтекстных и клиент-серверных внеконтекстных методов. Контекст так же образуется свойствами и методами глобального контекста, экспортными процедурами и функциями общих модулей скомпилированных на сервере, свойствами и методами расширения формы, определяемого основным реквизитом, свойствами и методами объекта встроенного языка УправляемаяФорма, реквизитами формы. Клиентские процедуры, функции и переменные недоступны.
&НаСервереБезКонтекста — определяет серверную процедуру, исполняемую вне контекста формы. Переменные не могут предваряться такой директивой. Серверная процедура, исполняемая вне контекста формы, (внеконтекстная) исполняется в среде серверного приложения. В такой процедуре не доступен контекст формы (включая данные формы). Допустимыми являются вызовы только других внеконтекстных процедур. При вызове этих процедур не выполняется передача данных формы на сервер и обратно. Применение внеконтекстных процедур позволяет существенно уменьшить объем передаваемых данных при вызове серверной процедуры из среды клиентского приложения.
&НаКлиентеНаСервереБезКонтекста — используется, когда к процедуре необходимо обращаться как с клиента, так и с сервера. Означает, что метод исполняется как на клиенте, так и на сервере вне контекста формы. Переменные не могут предваряться такой директивой.
Таким образом, разработчик должен понимать, что он фактически работает с двумя контекстами исполнения: серверным и клиентским, и между ними происходит обмен данными
При этом нужно учитывать, что на клиенте поддерживается лишь ограниченный набор типов данных и интерфейсные функции. На клиенте не допускается непосредственная работа с базой данных, работа непосредственно с прикладными объектами, использование запросов, таблиц значений. Доступность описана в синтакс-помошнике и ее необходимо проверять.
При разработке необходимо заботиться об оптимизации клиент-серверного взаимодействия:
- Основные вычисления должны выполняться в серверных процедурах;
- Нужно уменьшать количество серверных вызовов, когда из процедур &НаКлиенте вызываются процедуры &НаСервереБезКонтекста и &НаСервере;
- Количество контекстных серверных вызовов нужно минимизировать, лучше использовать процедуры &НаСервереБезКонтекста и передавать значения через параметры
Еще одна важная особенность управляемой формы состоит в том, что в ней происходит лишь отображение объекта. Основным ее реквизитом является не сам объект, а данные формы, в которые он преобразуется.
Элементами данных формы могут быть
- ДанныеФормаСтруктура (СправочникОбъект, ДокументОбъект)
- ДанныеФормыКоллекция (Табличные части)
- ДанныеФормыСтруктураСКоллекцией (НаборЗаписейРегистра).
Поэтому, для управляемой формы напрямую свойства и методы объекта недоступны. Чтобы обратиться из формы к свойствам и методам объекта нужно сначала получить объект.
Реквизит формы может быть преобразован в объект и обратно путем использования функций ДанныеФормыВЗначение() и ЗначениеВДанныеФормы(). Также он может быть преобразован в значение и обратно парой методов – РеквизитФормыВЗначение() и ЗначениеВРеквизитФормы(). Преобразование прикладных объектов в данные формы и обратно выполняется автоматически при выполнении стандартных действий формы и должно вызываться разработчиком при написании собственных алгоритмов.
Во время разработки конфигурации важно помнить, что прикладные объекты доступны только на сервере, в то время как объектами данных форм можно пользоваться и на сервере, и на клиенте.
Цель статьи – показать применение шаблонов Remote Facade и 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) Автор=»<?»», ИмяПользователя>» Дата=»<?»», ДатаВремя,»ДФ=dd.MM.yyyy»>»/>
// <Описание>
// <?>
// </Описание>
////////////////////////////////////////////////////////////////////////////////
// ПЕРЕМЕННЫЕ МОДУЛЯ
////////////////////////////////////////////////////////////////////////////////
// НА СЕРВЕРЕ
//******* СОБЫТИЯ НА СЕРВЕРЕ *******
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
//Вставить содержимое обработчика
КонецПроцедуры
//******* ИНТЕРФЕЙС УДАЛЕННОГО ДОСТУПА *******
//******* БИЗНЕС-ЛОГИКА НА СЕРВЕРЕ *******
////////////////////////////////////////////////////////////////////////////////
// ОБЩИЕ МЕТОДЫ КЛИЕНТА И СЕРВЕРА
////////////////////////////////////////////////////////////////////////////////
// НА КЛИЕНТЕ
//******* БИЗНЕС-ЛОГИКА НА КЛИЕНТЕ *******
//******* КОМАНДЫ *******
//******* СОБЫТИЯ НА КЛИЕНТЕ *******
////////////////////////////////////////////////////////////////////////////////
// ОПЕРАТОРЫ ОСНОВНОЙ ПРОГРАММЫ
Связанные вопросы
В заключение обозначим несколько направлений, о которых полезно подумать при программировании клиент-серверного взаимодействия.
- Варианты реализации интерфейса удаленного доступа. Асинхронность, степень детализации…
- Кэширование. В 1С приняли неудачное архитектурное решение, введя кэширование только на уровне вызова методов общих модулей и не предоставив возможности управления (время актуальности, сброс по требованию).
- Неявные серверные вызовы. Не забывайте о технологических особенностях, многие «безобидные» операции на клиенте провоцируют платформу на обращение к серверу.
- Предварительная/отложенная загрузка данных.
Формы в 1С:Предприятии предназначены для отображения и редактирования информации, содержащейся в базе данных. Формы могут принадлежать конкретным объектам конфигурации или существовать отдельно от них и использоваться всем прикладным решением в целом.
Например, справочник Номенклатура может иметь несколько форм, которые будут использоваться для определенных целей — редактирования элемента справочника, отображения списка и т. д.:
Наряду с этим, могут существовать общие формы, не принадлежащие конкретным объектам конфигурации — общие формы.
Основные формы
Каждый объект конфигурации может использоваться для выполнения некоторых стандартных действий. Например, для любого справочника может потребоваться отображать список его элементов, отображать отдельные элементы справочника, отображать группу справочника, выбирать элементы и группы элементов из справочника. Для любого документа список таких действий будет гораздо меньше: просмотр списка документов, выбор из списка документов и просмотр отдельного документа.
Чтобы обеспечить выполнение таких стандартных действий с данными объектов прикладного решения, для каждого из них существует набор основных форм, которые будут использоваться при выполнении соответствующих действий. Основной может быть назначена любая из форм, подчиненных этому объекту. Например, у справочника Номенклатура могут существовать следующие основные формы:
А у документа Поступление товаров и услуг состав основных форм будет уже другим:
Таким образом, если пользователь захочет посмотреть список справочника Номенклатура или список документов Поступление товаров и услуг, система откроет соответствующую форму, назначенную в качестве формы списка для этих объектов.
Автогенерируемые формы
Важной особенностью системы 1С:Предприятие 8 является механизм автогенерируемых форм. Этот механизм освобождает разработчика от необходимости создания всех возможных форм для каждого из объектов конфигурации. Разработчику достаточно добавить новый объект конфигурации, а система сама сгенерирует в нужные моменты работы пользователя необходимые формы для отображения информации, содержащейся в этом объекте.
Таким образом, разработчику нужно создавать собственные формы объектов прикладного решения лишь в том случае, если они должны иметь отличия (другой дизайн или специфическое поведение) от форм, автоматически генерируемых системой.
Связь формы с данными
Принадлежность формы тому или иному объекту конфигурации не определяет состав данных, которые отображаются в форме. То, что форма принадлежит, например, справочнику Номенклатура, позволяет назначить ее одной из основных форм для этого справочника, но никак не определяет, какие же именно данные будет отображать эта форма, и каково будет ее поведение.
Для того чтобы связать форму с данными, используются реквизиты формы, в которых указывается перечень данных, отображаемых формой. Все формы, сами по себе, имеют одинаковое поведение, независимо от того, какие данные они отображают. Однако один из реквизитов формы может быть назначен для нее основным (он выделяется жирным шрифтом), и в этом случае стандартное поведение формы и ее свойства будут дополнены в зависимости от того, какой тип имеет основной реквизит формы:
Например, если в качестве основного реквизита формы будет назначен документ Поступление товаров и услуг, то при закрытии формы система будет запрашивать подтверждение записи и проведения этого документа. Если же основным реквизитом формы назначить, скажем, справочник Номенклатура, то подобного запроса подтверждения при закрытии формы возникать не будет.
Структура формы
Основная особенность форм заключается в том, что они не нарисованы разработчиком детально, «по пикселям». Форма в конфигурации представляет собой логическое описание состава формы. А конкретное размещение элементов выполняется системой автоматически при отображении формы.
Отображаемая часть формы (видимая пользователю) описывается как дерево, включающее элементы формы.
Элементы могут представлять собой поля ввода, флажки, переключатели, кнопки и т. д. Кроме того, элемент может быть группой, включающей другие элементы. Группа может представляться как панель с рамкой, панель со страницами (закладками), собственно страница, командная панель. Помимо этого элемент может представлять собой таблицу, которая тоже включает элементы (колонки). Структура элементов описывает то, как будет выглядеть форма.
Вся функциональность формы описывается в виде реквизитов и команд. Реквизиты — это данные, с которыми работает форма, а команды — выполняемые действия. Таким образом, разработчик в редакторе формы должен включить в форму необходимые реквизиты и команды, создать отображающие их элементы формы и, если необходимо, скомпоновать элементы в группы.
На основе этого логического описания система автоматически формирует внешний вид формы для отображения пользователю. При этом системой учитываются различные свойства отображаемых данных (например, тип), чтобы максимально удобно для пользователя расположить элементы формы.
Разработчик может влиять на расположение элементов различными установками. Он может определять порядок элементов, указывать желаемую ширину и высоту. Однако это является только некоторой дополнительной информацией, помогающей системе отобразить форму.
В формах разработчик может использовать не только команды самой формы, но и глобальные команды, используемые в командном интерфейсе всей конфигурации. Кроме того, реализована возможность создания параметризуемых команд, которые будут открывать другие формы с учетом конкретных данных текущей формы. Например, это может быть вызов отчета по остаткам на том складе, который выбран сейчас в форме расходной накладной.
Механика работы форм
Функционирование управляемых форм имеет следующие отличительные особенности:
- Форма существует и на клиенте и на сервере
Она осуществляет клиент-серверное взаимодействие (передачу данных и оформительских свойств элементов) - Форма не работает с прикладными объектами
В форме используются специальные универсальные объекты ДанныеФормы… Прикладные объекты работают только на сервере и только во время выполнения некоторых операций
При открытии формы:
- Объект считывается из базы данных
- Объект конвертируется в данные формы
- Объект удаляется из памяти
- Данные формы передаются на клиента
При записи данных из формы:
- Данные формы получаются с клиента
- Данные формы конвертируются в объект
- Объект записывается в базу данных
- Объект удаляется из памяти
Редактор форм
Для создания и изменения форм разработчик может использовать редактор формы, обладающий удобными средствами графического конструирования форм различной сложности. Подробнее…