Как настроить управляемую форму

Настройка форм

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

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

Пользователь может изменить расположение полей Номер и Дата и удалить поле N из таблицы.

В режиме 1С:Предприятие вызвать настройку формы можно с помощью команды Еще — Изменить форму…

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

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

Авторы: В.А. Ажеронок, А.В. Островерх, М.Г. Радченко, Е.Ю. Хрусталева

Источник

Редактор формы

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

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

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

В отдельном окне, в нижней части редактора, отображается внешний вид формы в режиме 1С:Предприятие.

Редактирование элементов

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

Страницы, закладки

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

Редактор позволяет добавить в форму несколько элементов Группа — Страницы, каждая из которых может содержать несколько элементов Группа — Страница.

Например, форма документа может содержать один элемент Группа — Страницы, которому подчинены несколько элементов Группа — Страница с заголовками Изображение, Характеристики и Описание:

Тогда в режиме 1С:Предприятие она будет выглядеть следующим образом:

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

Например, закладки можно расположить снизу:

Элементы

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

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

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

Разделители

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

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

Модуль формы

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

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

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

Если у формы существует основной реквизит, определяющий поведение формы, отличное от типового, — он выделяется жирным шрифтом.

Командный интерфейс формы

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

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

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

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

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

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

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

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

Источник

Базовый принцип программирования управляемой формы в 1С

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

По сути, структура кода отсутствует, или мягче говоря, она аналогична тому, что было в формах 8.1:

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

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

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

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

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

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

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

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

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

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

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

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

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

Сравните с принятым в v8.1 стилем.

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник