Цель статьи – показать применение шаблонов Remote Facade и Data Transfer Object к структуризации кода, управляемой формы в среде 1С 8.2.

Введение

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

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

Управляемое приложение поддерживает следующие типы клиентов:

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

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

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

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

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

&НаКлиенте

&НаСервере

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

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

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

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

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

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

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

Рассмотрим структуру кода (модуль формы) в нескольких формах одной типовой конфигурации и попробуем найти закономерности.

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

Секция обработчиков событий

Метод – наклиенте

Метод – насервере

Метод - наклиенте

Секция служебных процедур и функций

Вспомогательные функции управления вводом

Служебные процедуры и функции

Документы оплаты

Ценности

Обработчики событий

Служебные процедуры на сервере

Служебные процедуры на клиенте

Служебные процедуры на сервере без контекста

Обработчики событий шапки

Обработчики событий команд

Процедуры общего назначения

Обработчики событий формы

Процедуры подсистемы «контактная информация»

По сути, структура кода отсутствует, или мягче говоря, она аналогична тому, что было в формах 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:

// на сервере в контексте формы

ОбработкаОбъект = РеквизитФормыВЗначение("Объект");

ОбработкаОбъект.ЗаполнитьКэшПользователей(ПодразделениеСсылка);

ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");

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

Примитивные типы (строка, число, булево)

Структура

Соответствие

Пример: метод принимает список заказов для изменения статуса и возвращает клиенту описание ошибок.

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

Функция СерверИзменитьСтатусЗаказов(Заказы, НовыйСтатус)

Ошибки = Новый Соответствие(); // [заказ][описание ошибки]

Для Каждого Заказ Из Заказы Цикл

НачатьТранзакцию();

Попытка

ДокОб = Заказ.ПолучитьОбъект();

…. другие действия, возможно не только с заказом…

Исключение

ОтменитьТранзакцию();

Ошибки.Вставить(Заказ, ОписаниеОшибки());

КонецПопытки;

КонецЦикла;

Возврат Ошибки;

КонецФункции // СерверИзменитьСтатусЗаказов()

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

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

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

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

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

// <Описание>

//

//

////////////////////////////////////////////////////////////////////////////////

// ПЕРЕМЕННЫЕ МОДУЛЯ

////////////////////////////////////////////////////////////////////////////////

// НА СЕРВЕРЕ

//******* СОБЫТИЯ НА СЕРВЕРЕ *******

&НаСервере

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

//Вставить содержимое обработчика

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

//******* ИНТЕРФЕЙС УДАЛЕННОГО ДОСТУПА *******

//******* БИЗНЕС-ЛОГИКА НА СЕРВЕРЕ *******

////////////////////////////////////////////////////////////////////////////////

// ОБЩИЕ МЕТОДЫ КЛИЕНТА И СЕРВЕРА

////////////////////////////////////////////////////////////////////////////////

// НА КЛИЕНТЕ

//******* БИЗНЕС-ЛОГИКА НА КЛИЕНТЕ *******

//******* КОМАНДЫ *******

//******* СОБЫТИЯ НА КЛИЕНТЕ *******

////////////////////////////////////////////////////////////////////////////////

// ОПЕРАТОРЫ ОСНОВНОЙ ПРОГРАММЫ

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

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

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

Главная проблема что за 10-15 лет уже наколбашено очень много кода под обычные формы. Переписывать это все на клиент-сервер никто не хочет + обучено работе с интерфейсом очень много народу. Обязательный переход на БП 3.0 со следующего года рождает панику в умах разработчиков и бухгалтеров. Фидбек будет очень нелицеприятный. К тому же повышается планка входа в профессию, программировать сложнее, типовые еще сложнее стали. Чего стоит новый алгоритм проведения в типовых документах. УФ отлично смотрятся когда у вас 2-3 кнопочки на документах, УФ супер для работы на мобильных устройствах, но пользуются этим 0.01% компаний. Переходить придется, если 1С не придумает чего-то нового, но будет это долго и мучительно для всех. А деньги платить придется самим компаниям.

Я тоже пока только негатив испытываю от управляемых форм, вот еще минусы нововведения:

• ничего? ну я пару раз столкнулся, например написать и прицепить к конфе ЗУП внеш.печ.форму, обработку там целая эпопея, полно инструкций в инете и страницы кода должны.
  на толстом клиенте одна процедура с параметрами т.е. разработка минутное дело.
  и тормоза в тонком невооруженным видно
• Насчет уметь готовить управляемые формы — это искусство ради искусства, а какой практический смысл, особенно для файловой версии?
• я 3 года ваял в УФ, но теперь перешел обратно на простые формы, и поверьте мне этот переход психологически было сделать довольно сложно, но это мой осознаный выбор ибо то, что 1с предлогает на УФ — это совершенно УГ…. может через пару лет 1с и сделает прорыв, но сейчас она только в поиске того места где этот прорыв делать…
• УФ в конфигураторе открываются намного дольше.
  После этого открытие форм в 8.1 — как на самолет пересесть с грузовика!
• Гемороя стало больше для всех, пользователи в шоке от нового интерфейса(не все признаются, но тупят значительно больше и по меньшим мелочам), половина программистов стало проф не пригодными, найти работу среднему спецу стало тяжелей да и как выдавать качественный продукт. А самая прикольная маркетинговая тема УФ в том везде парят что переход происходит простым обновлением, только что-то все забывают что с начало надо конфу до последних релизов догнать! Но в принципе мне нравится задумка!
• Незнаю моя практика показывает обратное. Там где бухи в стрых формах бьют уже несколько лет на автомате, в новых УФ типовых каждый месяц начинается «пля, куда теперь 1С после обновления дела эту кнопку и почему теперь это не работает», что согласитесь не добавляет скорость.
• — кода стало больше
  — код стал сложнее
  — доработка типовых — сильно сложнее
  — пользователи которым я давал УТ11 никаких достоинств по сравнению с 10.х не нашли
  — зато нашли тормоза и недостаток некоторых функций типа поиска (почему-то хотели именно поиск с вперед-назад а не отбор)
  мое мнение — слишком большие жертвы ради веб-клиента и планшетиков. Причем лично я пока реальную работу с веб-клиентом не встречал вообще, кому надо успешно пользуются удаленным доступом
• Клиент-серверный бедлам должен быть дать прирост производительности и масштабируемость, при этом в затратах — увеличение кодирования.
  Однако прирост выявился не у всех, отсюда и разочарование. А на затраты кодирования нагнули при этом всех.
  P.S. Собственно, мне управляемые нравятся, спокойно на них рисую. Но вот типовые стали извратные.
• На домашнем (нормальный комп) веду свою бухию по ИП.
  8.3, БП3, в шашечках. Основное впечатление — я не работаю, а все время жду. отклик геморройский. ОСВ по счету формируется простая офигеть — такое впечатление что карточка счета за год в мегахолдинге.
• УТ11 — дикий тормоз, ужас и вообще кошмар.
  УТ10 летает по сравнению с УТ11.
  По поводу УФ — баги годами кишат, все кривое, колонки никогда не помещаються на одном экране, растяжение во многих случаях ужасное.
  И еще могу минусов нашлепать дофига, из плюсов наверное ничего не скажу. Их попросту нет.
  Фирмы конкретно попали с этими формами, тк как разработка стоит доролже, спеов как не было так и нет нормальных.

Плюсов мало, но они конечно есть…

Плюсы :

ответ давно есть, чего дали УП:

кросс платформенность клиента

• работа на плохих линиях связи
• возможность работы через браузер (без установки клиента)

Эта статья продолжает цикл статей «Первые шаги в разработке на 1С». Материал предполагает, что вы уже ознакомились с предыдущими нашими статьями, посвященными интерфейсу. В это же статье мы продолжим знакомство с новыми возможностями интерфейса «Такси» и рассмотрим, какие интересные новшества получили управляемые формы в этом интерфейсе.

Применимость

В статье рассматривается интерфейс «Такси» конфигурации, разработанной на платформе 1C 8.3.5.1098. Дополнения к текущим релизам платформы (8.3.11) приведены в заключении. Поэтому вся представленная информация актуальна.

Новое в управляемых формах в «1С:Предприятие 8.3»

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

Ввод по строке

Ранее, в полях ввода, при вводе с клавиатуры начальных символов, система искала подходящие элементы.

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

В конфигураторе у ссылочных объектов метаданных для настройки ввода по строке, была создана отдельная закладка “Поле ввода”:

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

• использование полнотекстового поиска;
• поиск по вхождению подстроки или по началу строки;
• выполнение поиска непосредственно или в фоновом режиме.

В свойстве “Способ поиска строки при вводе по подстроке” можно выбрать – следует ли искать только по первым символам строки или в любой ее части.

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

Причем не только с первых букв названия, но и по вхождению набранной строки:

Естественно, использование поиска по любой части строки может привести к ухудшению производительности системы, особенно при большом объеме данных.

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

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

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

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

Результаты полнотекстового поиска, соответствующего введенной поисковой строке, приведены на рисунке:

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

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

Указанные выше обработчики не влияют на представление значений в списке выбора – в списке отражается основное представление объекта.

Однако после выбора в поле отображается ожидаемое переопределенное представление объекта.

Для увеличения нажмите на изображение.

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

Рассмотренные выше свойства ввода по строке задавались на уровне всего объекта метаданных.

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

Например, при помощи обработчиков событий АвтоПодбор и ОкончаниеВводаТекста конкретного поля ввода или при помощи обработчика события ОбработкаПолученияДанныхВыбора в модуле менеджера объекта.

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

Для увеличения нажмите на изображение.

Выпадающий список для поля ввода

В платформе 8.3 выпадающий список для поля ввода получил дополнительную функциональность для повышения удобства работы с системой.

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

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

Для увеличения нажмите на изображение.

Использование истории можно переопределить для конкретного реквизита объекта или элемента формы.

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

Также в списке поля ввода есть команда “Создать новый объект”. При этом будет открыта форма нового элемента.

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

Типовой шаблон использования команды “Создать новый элемент” выглядит следующим образом. Пользователь вводит название нужного элемента в поле ввода.

Если такого элемента в базе данных система не обнаружит – будет выведено сообщение об этом. После нажатия кнопки в списке, на экране откроется форма нового элемента с заполненным наименованием.

Рассмотренные новшества позволяют увеличить скорость ввода информации в систему.

Сохранение настроек динамических списков

В платформе 8.3 настройки динамического списка можно сохранять автоматически. Для этого в конфигураторе, для нужного реквизита формы, необходимо установить свойство “Автоматическое сохранение пользовательских настроек”. По умолчанию, при создании списка эта настройка включена.

У корневого элемента конфигурации появилось новое свойство – Хранилище пользовательских настроек динамических списков.

Это свойство выбирается из списка хранилищ настроек, определенных в конфигурации.

Для увеличения нажмите на изображение.

Настройка списков в пользовательском режиме вызывается при помощи соответствующего пункта меню:

Внешний вид формы похож на настройку отчетов.

Для увеличения нажмите на изображение.

Условия, по которым выполнен отбор списка, автоматически отображаются в нижней части настроек. Эти настройки будут включены в форму списка.

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

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

При такой настройке форма будет иметь поля в виде “быстрых отборов”.

Для увеличения нажмите на изображение.

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

Режим просмотра динамического списка (список, дерево, иерархический список) сохраняется вместе с настройками элементов формы.

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

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

Для увеличения нажмите на изображение.

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

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

Для увеличения нажмите на изображение.

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

Для увеличения нажмите на изображение.

Т.к. материал в статье описан для платформы 8.3.5, то актуализируем его.

• До версии 8.3.7 ввод по строке работал недостаточно быстро, поэтому в этом релизе была изменена структура данных индекса полнотекстового поиска, что привело к повышению скорости при работе системы в тех местах, где используется данный механизм. Отметим, что новый формат полнотекстового поиска используется в том случае, если режим совместимости установлен в значение «Не использовать». В режиме совместимости с с версией 8.3.6 поведение не изменилось. Также отметим, что в следующем релизе платформы 1С (8.3.8) механизм ввода по строке и при использовании строки поиска динамического списка был также улучшен, и теперь он обеспечивает поиск данных, которые еще не попали в полнотекстовый поиск. Ранее такого поведения не наблюдалось.
• Выпадающий список поля ввода управляемой формы также претерпел некоторые улучшения. В версии 8.3.8 он стал автоматически подстраивать свою ширину под ширину отображаемых в нем данных, плюс клавиши Home и End стали обрабатываться прямо в поле ввода. Благодаря этим улучшениям стало удобнее использовать поле ввода с выпадающим списком.
• Механизм сохранения настроек динамических списков также был улучшен, и в версии 8.3.6 свойства расширения таблицы формы для динамического списка Период и Отображение стали храниться в тех же разрезах, что и другие настройки динамического списка, что сильно упростило работу с ними разработчику. Теперь они стали доступны в обработчике управляемой формы ПриЗагрузкеПользовательскихНастроекНаСервере() , чего ранее не было.

На этом знакомство с управляемыми формами в интерфейсе «Такси» мы завершим, но в следующей статье познакомимся с новыми возможностями, которые представила платформа «1С:Предприятие» редакции 8.3.

Мы все знаем, что у компании "1С" было много разных версий платформы 1С, нас сейчас будут интересовать одни из последних версий на момент написания этой статьи, это версии 1С 8.2 и 1С 8.3. Если Вам приходилось работать в обеих этих версиях то Вы, скорее всего, заметили различия в интерфейсах данных версий , для пользователей они отличаются только внешне. По сути, выбор обычного или управляемого приложения говорит системе, какие формы для отображения нужно запускать, обычные или управляемые , а также какой клиент приложения будет использоваться по умолчанию, толстый или тонкий. Более подробную информацию по клиентам читайте в статье «Что такое толстый и тонкий клиент в 1С, а также их различия».

Обычное приложение 1С (обычные формы, обычный интерфейс, версия 1С 8.2)

В 1С 8.2 возможна работа только с обычными формами, в режиме обычного приложения . На изображении ниже показана база в режиме работы "обычное приложение 1С" (обычные формы).

Управляемое приложение 1С (управляемые формы, управляемый интерфейс, версия 1С 8.3)

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

Чем отличаются обычное и управляемое приложение 1С?

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

Управляемые формы уже давно и плотно вошли в жизнь 1С-разработчика. Однако, многие до сих пор мало знакомы с ними. Предлагаю разобраться с тем, что же это такое.

Введение

Данная статья ориентирована на разработчиков, которые волею судеб не успели плотно поработать с управляемыми формами. Если вы уже хорошо знаете, как работают УФ и вообще управляемый интерфейс приложения, то можете статью не читать, поскольку, вряд ли узнаете много нового.

Немного истории

Исторически сложилось, что клиентское приложение 1С всегда было реализовано в виде так называемого «толстого» клиента – программы, которая сама все делает в плане обработки данных. Это создавало заметную нагрузку на сеть, а кроме того, требовало наличия мощных клиентских машин.

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

Версия 8.0 принесла нам трехзвенную архитектуру, в которой появился «сервер 1С:Предприятия» – отдельный программный компонент, который мог выполнять код бизнес-логики на специально выделенной мощной машине (сервере), тем самым, снизив объем данных, гуляющих по сети и требования к аппаратной части клиентских машин.

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

В основном, все оставалось по-старому, и клиентское приложение так и оставалось «толстым» клиентом, гоняющим сотни мегабайт по сети.

Версия 8.2 кардинально сломала устоявшийся подход к работе приложения и заставила по-новому взглянуть на архитектуру приложения. Об этом новом подходе и пойдет речь в данной статье.

Волшебный зверь Клиент-сервер

С выходом версии 8.0 все учебные курсы, книжки, статьи на ИТС и прочее, и прочее, все в один голос твердили нам – «обработка данных должна идти на сервере», «все нужно выполнять на сервере». Волшебное заклинание «на сервере» плотно забило мозг, так сильно, что на него уже никто внимания не обращал, как на информационный шум.

Опыт показывает, что рядовой программист практически никогда не знал, как нужно перенести код на сервер и что это вообще значит – «на сервер». Удивительно часто встречался код, который переносился «на сервер», но был написан с явным непониманием того, что это в итоге принесет.

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

Однако многие уже опытные разработчики запросто писали такой код:

• Выбирается локальный файл
• Его путь передается на сервер
• Там по этому пути файл пытается открыться и падает с ошибкой «Файл не найден» (еще бы, он же остался на клиенте).

Переход на сервер

До версии 8.2 перенести исполнение кода на сервер можно было только одним способом – а именно, вызовом общего модуля с флагом «Сервер». Причем, только с этим флагом. Если помимо флага «сервер» поставить «клиент», то перехода не произойдет.

Суть всех флагов модуля сводится к простым правилам:

1. Флаг показывает, где будет скомпилирован код модуля (на клиенте, на сервере, во внешнем соединении)
2. Если модуль скомпилирован в нескольких местах, то он будет виден только в соответствии с флагами. Клиентский – на клиенте, серверный на сервере. Переноса исполнения с машины на машину не будет.
3. Перенос исполнения кода возможен только если в текущем контексте исполнения нет вызываемого модуля, но он есть в другом месте (если – модуль есть только на сервере, а на клиенте его нет, то будет сделан вызов сервера)

Флаг «Вызов сервера»

В версии 8.2 добавился флаг «вызов сервера», который помогает разрулить условия перехода на другую машину. Если модулю назначить этот флаг, то модуль будет виден с клиента, если нет – то попытка вызова с клиента приведет к ошибке. Код модуля виден не будет, как будто его нет совсем.

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

1. Установлен флажок «Сервер»
2. Установлен флажок «Вызов сервера»
3. Сняты все «клиентские» флажки

Особенности перехода на сервер

Платформа заботится о том, чтобы переход исполнения кода на другую машину был как можно более незаметным. Мы вызываем функции серверного кода, передаем туда параметры, получаем возвращаемые значения, получаем изменения параметров, передаваемых по ссылке. Все выглядит так, как будто никакого сервера нет. Однако, это не так.

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

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

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

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

Отсутствие контекста (состояния) на сервере

Существует такая модель серверных приложений, когда сервер только отвечает на запросы, но ничего не сохраняет у себя в промежутке между двумя запросами. Эта модель называется моделью «без состояния» (англ. state-less).

Все HTTP-серверы современного интернета работают именно так. Клиенты посылают запросы, сервер выдает ответ и забывает все, что получал от клиента. Разумеется, есть вариации, но общая модель именно такая: сервер отрабатывает запрос и очищает все данные.

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

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

Управляемое приложение

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

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

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

Тонкий клиент

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

Такое облегчение не далось бесплатно. Очень многие привычные операции стали выполняться сложнее. Упомянутая выше сериализация никуда, разумеется, не делась, а данные, которые нельзя было передавать на сервер, так и нельзя туда передавать.

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

Чтение данных из ИБ в форму и запись из формы в ИБ выполняется практически явно, этот момент можно отловить в событиях формы.

Тонкий клиент стал поистине «клиентом». Он больше не обрабатывает данные, он их показывает и позволяет редактировать. Всю обработку мы теперь явно переносим на сервер.

Устройство управляемой формы

Давайте рассмотрим, из каких частей состоит управляемая форма.

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

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

Данные формы

Есть старая уже хохма про ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокументИмениНуралиеваБорисаГеоргиевича.

Управляемая форма добавляет очередного претендента на звание длинного и непонятного идентификатора: ДанныеФормыСтруктураСКоллекцией и еще ряд новых классов с именами вида «ДанныеФормы….что-то там». Давайте попробуем выяснить, что это за новые объекты.

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

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

Здесь стоит немного вспомнить обычные формы. Ведь как мы привыкли – В форме справочника достаточно присвоить переменной «Наименование» какой-то текст и этот текст попадет в СправочникОбъект, а оттуда – в информационную базу.

У управляемой форме все почти так, за исключением того, что все совсем не так (IMG:) .Платформа предпринимает массу усилий, чтобы в повседневной работе программиста ему не приходилось с этим заморачиваться. Как правило, мы, как и раньше, присваиваем свойства реквизитам формы, а они попадают в СправочникОбъект, а оттуда – в ИБ.

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

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

Адресация данных формы

Данные формы доступны непосредственно в коде по тем именам, как они расположены в дереве реквизитов формы (в окне редактора)

Реквизиты верхнего уровня доступны сразу. Вложенные реквизиты доступны через точку. Раньше в обычной форме мы обращались к данным объекта напрямую. Мы писали «Наименование = «АААААА» и данные попадали в объект. Теперь надо писать «Объект.Наименование = «ААААА», потому, что реквизит «Наименование» вложен внутрь реквизита «Объект».

Обмен формы с сервером

Основным «двигателем» всех аспектов управляемой формы является то, что у нас state-less сервер. На нем не сохраняется ничего, никаких промежуточных данных. Всё состояние формы (текст в полях ввода, строки табличных частей и т.п.) хранится на клиенте. Вся совокупность данных формы называется контекстом формы.

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

Жизненный цикл формы объекта

Давайте рассмотрим, что происходит, когда мы открываем форму существующего элемента справочника.

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

Обратите внимание, что СправочникОбъект, к которому мы так привыкли в обычном приложении, уничтожился. Если в модуле объекта были какие-либо глобальные переменные, экспортные или не экспортные, все они стали потеряны.

Теперь, давайте рассмотрим процесс записи данных справочника:

1. Пользователь нажимает кнопку «Записать»
2. Выполняется обработчик формы «ПередЗаписью» (на клиенте)
3. Происходит серверный вызов
4. В памяти сервера создается новый СправочникОбъект, он наполняется данными на основании данных текущей формы (что-то вроде ЗаполнитьЗначенияСвойств, но в обратном направлении – пишется из формы в объект)
5. Вызывается обработчик события формы «ПередЗаписьюНаСервере», куда передается свежесозданный СправочникОбъект. С этого момента, если мы хотим что-то записать в базу данных, то менять нужно именно СправочникОбъект. Изменения данных формы не отразятся в записываемом объекте.
6. Вызывается обработчик «ПередЗаписью» самого СправочникОбъект (в модуле объекта)
7. Вызывается обработчик «ПриЗаписи» самого СправочникОбъект (в модуле объекта)
8. Вызывается обработчик события формы «ПриЗаписиНаСервере», транзакция записи еще не завершена и можно отменить запись
9. Вызывается обработчик события формы «ПослеЗаписиНаСервере», транзакция записи уже завершена
10. СправочникОбъект уничтожается
11. Выполняется возврат на клиента, где вызывается обработчик события формы «ПослеЗаписи»

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

Конвертация данных формы

Для упрощения жизни существуют простые способы преобразования универсальных объектов «ДанныеФормы….» в привычные прикладные объекты и наоборот.

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

Обратное преобразование выполняется методом «ЗначениеВРеквизитФормы». Если мы произвели какие-то действия с данными СправочникОбъект, например, очистили табличную часть, то мы должны поместить наши изменения обратно в форму, иначе будет что?

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

Не все так плохо (IMG:)

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

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

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

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

Каждая команда может быть размещена в командной панели, подменю, или на самой форме. Создаются команды на закладке «Команды» в редакторе формы.

Параметры формы

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

Управление открытием формы

Отображение форм на экране в управляемом режиме также претерпело некоторые изменения. Прежде всего, формы получили имена, по которым к ним можно обращаться. Например, форма списка справочника «Контрагенты» будет называться «Справочник.Контрагенты1.ФормаСписка».

Методика открытия формы теперь такова: форма должна открываться одной строчкой кода и одним вызовом сервера. Эту задачу на себя берет глобальный метод «ОткрытьФорму». В данный метод мы должны передать имя формы (см. выше), параметры формы, владельца и ключ уникальности. Все параметры, кроме имени являются необязательными.

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

Для этого и нужны Параметры формы. Это структура, которую можно передать в метод «ОткрытьФорму». Переданные параметры можно проанализировать в серверном коде формы и предпринять какие-то действия на основании переданных параметров.

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

УсловияОтбора = Новый Структура;
УсловияОтбора.Вставить("ТипКонтрагента", "Поставщик");
УсловияОтбора.Вставить("Лояльность", "Надежный");
ОткрытьФорму("Справочник.Контрагенты.ФормаСписка", УсловияОтбора);

Существуют системные параметры, на которые реагирует сама платформа. Упомянутый параметр «Отбор» как раз является системным, если он передан форме списка, то платформа сама установит отбор на список.

Кроме того, параметры можно создавать произвольные, в редакторе формы. Более того, параметры можно передавать даже с теми именами, которые не объявлены в форме, они все равно будут видны в серверном коде формы.

Жизненный цикл параметров

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

Исключение составляют параметры, которые в редакторе формы объявлены с признаком «Ключевой параметр». Такой параметр будет существовать до тех пор, пока существует сама форма.

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

Если Параметры.ЗапуститьЯдерныйРеакторПриОткрытии Тогда
УправлениеРеактором.Запустить();
КонецЕсли;

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

Ключевые параметры определяют уникальность окна. В обычных формах был такой атрибут «Ключ уникальности». Если запрашивалась форма, то она сначала искалась в уже открытых. Ключ уникальности позволял варьировать условия при которых создавалась новая форма или возвращалась существующая. Ту же самую роль играют ключевые параметры. Если метод «ОткрытьФорму» вызван два раза подряд с одним и тем же значением ключевого параметра, то второй вызов не откроет новое окно, а активирует существующее.

Модуль формы

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

Для модуля форм возможны следующие директивы:

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

Директива указывает компилятору, где нужно скомпилировать указанную процедуру. С директивами «НаКлиенте» и «НаСервере» все понятно, а вот с добавкой «БезКонтекста» нужно разобраться подробнее.

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

контекст формы, т.е. ее данные. Когда мы вызываем сервер «с контекстом», то контекст должен быть передан на сервер, поскольку его там в данный момент просто не существует (сервер state-less).

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

Поскольку все происходит настолько для нас прозрачно, что порой кажется: «какая красота, не надо заморачиваться, можно всегда писать «НаСервере» и на сервере все будет доступно». Однако, как видно из предыдущего абзаца, такая прозрачность не бесплатна. Все данные формы должны упаковаться, отправиться на другой континент, там распаковаться, после чего должен быть выполнен серверный код, и потом обратная упаковка и возврат изменений на клиента. Понятно, что накладные расходы на передачу контекста очень высоки.

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

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

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

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

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

Переменные уровня модуля формы

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

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

Временное хранилище – секретное оружие

При работе с управляемыми формами быстро становится ясно, что ограничения клиент-серверного взаимодействия очень сильно сужают возможности разработчика. Поэтому, платформа 1С предоставляет хитрый секретный ход под названием «ВременноеХранилище». Эта сущность позволяет сохранить на сервере некоторое состояние между двумя серверными вызовами. Я слышу возгласы: «А кто сказал, что состояние нельзя хранить!» Справедливое замечание, состояние хранить все-таки можно, но недолго.

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

Для работы со временным хранилищем используются методы ПоместитьВоВременноеХранилище и ПолучитьИзВременногоХранилища.

С методом «Получить» все просто, он по заданному адресу возвращает значение, которое лежит в хранилище.

С методом «Поместить» несколько сложнее. Дело в том, что помещать можно в 2 разных хранилища – простое и хранилище формы. Хранилище формы живет на сервере столько, сколько живет сама форма. Простое хранилище живет ровно 2 серверных вызова. В синтакс-помощнике об этом написано целых несколько умных строк. Я никогда не понимал, что они означают. Опытным путем было установлено, что срок жизни – 2 серверных вызова.

• Первый – мы помещаем что-то в хранилище и возвращаем адрес на клиента.
• Клиент делает второй вызов и по этому адресу может получить данные.
• В третьем вызове по этому адресу уже ничего не будет. Платформа очистит хранилище

С хранилищем формы ситуация более интересная. Если вторым параметром метода «ПоместитьВоВременноеХранилище» передать идентификатор формы (ЭтаФорма.УникальныйИдентификатор), то данные в хранилище будут привязаны к сроку жизни формы и не будут удалятся ни в первых, ни во вторых, ни во всех прочих вызовах сервера.

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

Особенности временного хранилища

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

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

Как примерно работает временное хранилище:

• Данные помещаются в ВХ
• Управление возвращается на клиента
• Клиент делает повторный серверный вызов
• Менеджер кластера переключает вызов на другую машину из кластера (не ту, что помещала данные в хранилище)
• И вот тут, если данные в хранилище были сериализуемые, то все отлично, мы получим их даже на другой машине кластера.
• Если данные не были сериализуемые (СправочникОбъект, COM-объект, что-то еще), то они просто пропадут, ибо нефиг.

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

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

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

Массив = Новый Массив; Массив.Добавить("Привет");

Адрес = ПоместитьВоВременноеХранилище(Массив);

Массив.Добавить("До свидания");

МассивИзХранилища = ПолучитьИзВременногоХранилища(Адрес);

Сообщить(Массив = МассивИзХранилища); // Истина

Сообщить(МассивИзХранилища.Количество()); // 2 элемента

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

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

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

Краткий итог

• Взаимодействие с сервером теперь не спрятано от разработчика. Наоборот, оно каждую минуту напоминает о себе. И это хорошо.
• Сервер 1С не сохраняет данные между обращениями клиента к серверу. Нужно проектировать взаимодействие с учетом этой особенности
• Временное хранилище – мощное средство, которое нивелирует сложности state-less взаимодействия и позволяет строить сложные схемы серверных вызовов.
• У формы есть контекст, который передается с клиента на сервер и обратно при каждом контекстном вызове сервера. Для несложных вызовов, где не требуется вся форма целиком, следует использовать внеконтекстные вызовы.

Заключение

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

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

Литература к прочтению

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

Постскриптум

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

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