Эта статья продолжает цикл статей «Первые шаги в разработке на 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.

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

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

• Самостоятельное формирование структуры формы и размещение полей платформой. Если раньше разработчики описывали положение поля, указывая пиксели, то теперь есть возможность лишь указать вид группировки;
• Форма состоит из реквизитов, представляющих данные формы, и команд – выполняемых процедур и функций;
• Код формы выполняется на стороне и сервера, и клиента. Ведь сама по себе форма – это объект конфигурации, создаваемый на сервере и отображаемый на клиенте. Значит, объединяет в себе клиентскую и серверную часть;
• На клиентской стороне стали недоступны многие типы данных и теперь отсутствует возможность изменить данные в информационной базе;
• Для каждой процедуры или функции должна быть указана специальная настройка – директива компиляции. Она отвечает за место выполнения кода и может принимать следующие значения:
  • Наклиенте;
  • НаСервере;
  • НаСервереБезКонтекста;
  • НаКлиентеНаСервере;
  • НаКлиентеНаСервереБезКонтекста.

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

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

1. Элементы интерфейса формы. Слева вверху расположено окно, где перечислены все поля, отраженные на выбранной форме, обеспечивающие взаимодействие программы с пользователем;
2. Реквизиты формы. Справа вверху расположены все данные, с которыми работает форма. Именно в них хранится информация на клиентской стороне;
3. Отображение управляемой формы. Снизу мы видим предварительный внешний вид на основе элементов интерфейса;
4. Модуль формы. Раздел, содержащий процедуры и функции, используемые данной формой. Здесь можно найти код алгоритмов взаимодействия программы и с пользователем, и с базой данных.

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

Принципы разработки управляемых форм

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

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

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

&НаСервере Процедура ПолучитьПлатежноРасчетныеДокументыИзХранилища(НовыйАдресВХранилище) &НаСервереБезКонтекста Функция ЕстьРасчетыСКлиентом(ДокументОснование) &НаСервереБезКонтекста Процедура ЗаполнитьСписокВыбораКПП(СписокВыбора, Контрагент, ДатаСведений) &НаКлиенте Процедура ЗаполнитьГоловногоКонтрагентаЗавершение(ВыбранноеЗначение, ДополнительныеПараметры) &НаСервере Процедура УстановитьТекстПлатежноРасчетныхДокументов() &НаСервере Функция ЕстьЗаполненныеИсходныеДокументы()

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

1. Простота сопровождения конфигурации и повышенная читаемость кода. Отсюда можно сделать вывод, что алгоритм, написанный одним разработчиком, всегда сможет поправить другой сотрудник, не тратя много времени;
2. Разделение кода, выполняемого на клиенте и сервере. Учитывая, насколько отличается функционал, доступный на каждой из этих сторон, разделить их было бы правильным шагом;
3. Более глубокое понимание разработчиками логики платформы, взаимодействия клиента и сервера и алгоритмов, которые они пишут. В версиях 8.0 и ранее очень часто можно было встретить формы документов или справочников, разработанные без понимания клиент-серверной части;
4. Повышение быстродействия конфигураций и снижение нагрузки на клиентские компьютеры;
5. Снижение затрат на закупку компьютеров для рабочих мест ввиду отсутствия необходимости приобретения мощных ПК.

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

В прошлом уроке мы с Вами рассмотрели для обычного (толстого) клиента. В версии платформы 1С 8.2 . В них используются новые экранные формы 1С 8.2. Их называют управляемые формы 1С 8.2.

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

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

Управляемые формы 1С 8.2

Если Вы занимались разработкой конфигураций 1С ранее – при открытии редактора управляемой формы 1С 8.2 Вас сразу поставит в тупик то, что мышкой невозможно повлиять на форму 1С 8.2 вообще.

Нельзя изменить форму 1С 8.2, нельзя передвинуть элемент, нельзя даже посмотреть свойства поля как раньше – кликнув два раза мышкой поле на форме 1С 8.2.

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

Настройки состоят из списка элементов формы 1С 8.2, расположенных в редакторе в верхнем левом углу. В элементы формы 1С 8.2 входят:

• Реквизиты
• Команды (новое понятие 1С 8.2, могут выглядеть как кнопки или пункты меню)
• Группы (для объединения реквизитов и команд).

Соответственно настройки этих элементов находятся не в свойствах полей, а в свойствах этих элементов настройки (меню по правой кнопке мыши, пункт Свойства).

Как работают управляемые формы 1С 8.2

Работа с управляемыми формами 1С 8.2 отличается для пользователя. Они имеют больше возможностей, но непривычны для тех, кто работает с 1С уже давно.

В первую очередь отличается расположение привычных элементов на форме 1С 8.2. Командная панель всегда находится вверху.

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

Правая часть командной панели – новое стандартное меню формы 1С Все действия. Это меню позволяет управлять формой 1С 8.2 по своему желанию, наподобии, как в отчете СКД настройки позволяют значительно изменить вид отчета.

Произвольные пункты меню 1С Все действия

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

Пункт Настроить список меню 1С Все действия

Если на форме 1С 8.2 есть список, то в меню есть команда Настроить список и Вывести список.
Если команда Вывести список Вам уже знакома – она позволяет любой список в 1С сохранить в Excel/вывести на печать, то вторая команда – новая.

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

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

Пункт Изменить форму меню 1С Все действия

Пункт Изменить форму позволяет подобным образом изменить не только список на форме 1С 8.2, но и саму форму 1С 8.2.

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

Использование управляемых форм 1С 8.2 и обычных форм 1С

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

Для этого необходимо и войти в свойства конфигурации (верхний элемент в окне конфигурации).

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

Создание управляемых форм 8.2

Добавление новой формы 1С 8.2 производится также, как и раньше – с помощью кнопки Ins на клавиатуре или кнопки Добавить. Чтобы войти в существующую – нажмите на нее два раза мышкой.

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

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

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

Редактор формы состоит из трех разделов.

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

Доступные реквизиты Вы можете перетащить влево и он станет элементом формы (полем на форме).

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

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

В список элементов формы (полей) можно не только перетащить реквизит объекта/формы, но и просто добавить (кнопка Добавить или Ins). В частности можно новый объект формы – Группу.

Группа может быть командной панелью (курсор должен стоять на строке Форма). Тогда Вы перетаскиваете в нее команды и они становятся кнопками.

Группа может быть «обычной». Тогда это способ группировки полей как вертикально, так и горизонтально. Наименование группы можно убрать в свойствах.

Группа может быть панелью (страницы). Верхняя добавленная группа является панелью, а вложенные группы этого типа являются страницами. На страницы перетаскиваются уже поля.

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

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

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

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

И 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С приняли неудачное архитектурное решение, введя кэширование только на уровне вызова методов общих модулей и не предоставив возможности управления (время актуальности, сброс по требованию).
• Неявные серверные вызовы . Не забывайте о технологических особенностях, многие «безобидные» операции на клиенте провоцируют платформу на обращение к серверу.

И 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С приняли неудачное архитектурное решение, введя кэширование только на уровне вызова методов общих модулей и не предоставив возможности управления (время актуальности, сброс по требованию).
• Неявные серверные вызовы . Не забывайте о технологических особенностях, многие «безобидные» операции на клиенте провоцируют платформу на обращение к серверу.