Управление интерфейсом 1с. Рабочий стол: Ссылки на данные

Здравствуйте.

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

Обычный интерфейс

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

1. «1С:Управление производственным предприятием 8», редакция 1.3
2. «1С:Управление торговлей 8», редакция 10.3
3. «1С:Бухгалтерия 8», редакция 2.0
4. «1С:Зарплата и Управление персоналом 8», редакция 2.5

Основные особенности обычного интерфейса это:
1. Наличие главного меню.
2. Неизменность главного меню для всех пользователей независимо от их прав доступа и каких-либо настроек.
3. Для разных пользователей можно создавать разные интерфейсы.

Обычный интерфейс «Бухгалтерия предприятия, редакция 2.0»

Как запустить обычный интерфейс если по умолчанию запускается тонкий клиент? Смотри в:

Обычная форма

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

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

Управляемый интерфейс

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

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

Управляемый интерфейс «Управление торговлей, редакция 11.0»

Главное преимущество управляемого интерфейса – возможность работы в веб-клиенте (веб-браузере). Нет необходимости ставить платформу 1С на компьютер. Для пользователей на операционной системе Linux, для доступа к информационной базе 1С используется веб-браузер Mozilla Firefox.

Управляемая форма

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

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

В Управляемом интерфейсе «1С:Предприятия 8.2».

Пожалуйста оставляйте комментарий мне важно Ваше мнение.

P.S. Большая разница серебро мама люба

И Data Transfer Object к структуризации кода, управляемой формы в среде 1С 8.2.

Введение

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

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

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

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

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

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

Рассмотрим структуру кода (модуль формы) в нескольких формах одной типовой конфигурации и попробуем найти закономерности.
Под структурой будем понимать секции кода (чаще всего это блоки комментариев) выделенные разработчиком для группировки методов и директивы компиляции этих методов.
Пример 1:
Секция обработчиков событий Метод – наклиенте Метод – насервере Метод - наклиенте Секция служебных процедур и функций Вспомогательные функции управления вводом
Пример 2:
Служебные процедуры и функции Документы оплаты Ценности Обработчики событий
Пример 3:
Служебные процедуры на сервере Служебные процедуры на клиенте Служебные процедуры на сервере без контекста Обработчики событий шапки Обработчики событий команд
Пример 4:
Процедуры общего назначения Обработчики событий формы Процедуры подсистемы «контактная информация»
По сути, структура кода отсутствует, или мягче говоря, она аналогична тому, что было в формах 8.1:

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

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

Клиент-серверное взаимодействие используется в различных программных технологиях не один десяток лет. Ответ на обозначенные в предыдущем разделе вопросы давно известен и суммирован в двух базовых принципах.
  • Remote Facade (далее Интерфейс удаленного доступа)
  • Data Transfer Object (далее Объект переноса данных)
Слово Мартину Фаулеру , его описание данных принципов:
  • каждый объект, потенциально предназначенный для удаленного доступа, должен иметь интерфейс с низкой степенью детализации , что позволит максимально уменьшить количество вызовов, необходимых для выполнения определенной процедуры. … Вместо того, чтобы запрашивать счёт и все его пункты отдельно, надо считать и обновить все пункты счёта за одно обращение. Это влияет на всю структуру объекта.…Запомните: интерфейс удаленного доступа не содержит логики домена .
  • …если бы я был заботливой мамой, то обязательно сказал бы своему ребенку: «Никогда не пиши объекты переноса данных!» В большинстве случаев объекты переноса данных представляют собой не более чем раздутый набор полей … Ценность этого омерзительного монстра состоит исключительно в возможности передавать по сети несколько элементов информации за один вызов - прием, который имеет большое значение для распределенных систем.
Примеры шаблонов в платформе 1С
Прикладной программный интерфейс доступный разработчику при разработке управляемой формы, содержит много примеров данных принципов.
Например метод ОткрытьФорму(), типичный «огрубленный» интерфейс.
ПараметрыОткрытия = Новый Структура("Параметр1, Параметр2, Параметр3", Значение1, Значение2, Значение3); Форма = ОткрытьФорму(ИмяФормы, ПараметрыОткрытия);
Сравните с принятым в v8.1 стилем.
Форма = ПолучитьФорму(ИмяФормы); Форма.Параметр1 = Значение1; Форма.Параметр2 = Значение2; Форма.Открыть();

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

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

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

  • Примитивные типы (строка, число, булево)
  • Структура
  • Соответствие
  • Массив
  • Ссылки на прикладные объекты (уникальный идентификатор и текстовое представление)
Пример: метод принимает список заказов для изменения статуса и возвращает клиенту описание ошибок.
&НаСервереБезКонтекста Функция СерверИзменитьСтатусЗаказов(Заказы, НовыйСтатус) Ошибки = Новый Соответствие(); // [заказ][описание ошибки] Для Каждого Заказ Из Заказы Цикл НачатьТранзакцию(); Попытка ДокОб = Заказ.ПолучитьОбъект(); …. другие действия, возможно не только с заказом… Исключение ОтменитьТранзакцию(); Ошибки.Вставить(Заказ, ОписаниеОшибки()); КонецПопытки; КонецЦикла; Возврат Ошибки; КонецФункции // СерверИзменитьСтатусЗаказов()

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

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

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="" Дата=""/> // <Описание> // // //////////////////////////////////////////////////////////////////////////////// // ПЕРЕМЕННЫЕ МОДУЛЯ //////////////////////////////////////////////////////////////////////////////// // НА СЕРВЕРЕ //******* СОБЫТИЯ НА СЕРВЕРЕ ******* &НаСервере Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка) //Вставить содержимое обработчика КонецПроцедуры //******* ИНТЕРФЕЙС УДАЛЕННОГО ДОСТУПА ******* //******* БИЗНЕС-ЛОГИКА НА СЕРВЕРЕ ******* //////////////////////////////////////////////////////////////////////////////// // ОБЩИЕ МЕТОДЫ КЛИЕНТА И СЕРВЕРА //////////////////////////////////////////////////////////////////////////////// // НА КЛИЕНТЕ //******* БИЗНЕС-ЛОГИКА НА КЛИЕНТЕ ******* //******* КОМАНДЫ ******* //******* СОБЫТИЯ НА КЛИЕНТЕ ******* //////////////////////////////////////////////////////////////////////////////// // ОПЕРАТОРЫ ОСНОВНОЙ ПРОГРАММЫ

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

Мы все знаем, что у компании "1С" было много разных версий платформы 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С:Бухгалтерия предприятия, редакция 3.0 – первая версия конфигурации, где предусмотрена возможность настройки интерфейса. С одной стороны, такая возможность компенсирует кардинальные отличия во внешнем виде новой версии от предыдущей – 1С 8.2. С другой, дает пользователям гибкие возможности для настройки рабочего пространства, ориентируясь только на имеющиеся потребности, собственное удобство и индивидуальный вкус.

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

  • Стандарт (как в предыдущих версиях 1С:Бухгалтерия 8)
  • Такси

Стандарт

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


При наглядном сравнении редакций 3.0 и 2.0 видно, что структура интерфейса осталась неизменной.


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


Поскольку этот вид интерфейса был первым, именно он остается самым популярным. Изменить его структуру можно, зайдя в «Администрирование-Настройки программы» - пункт «Интерфейс».


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


*Горизонтальные меню:

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

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

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

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


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


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


Такси

В интерфейсе «Такси» панель разделов находится изначально слева.


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


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


*Панели, находящиеся в верхней части окна редактора, в данный момент активны.

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


Окно настройки панели действий позволяет добавлять и удалять разделы, вплоть до полного удаления.


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


*Часто сюда добавляют внешние доработки

Аналогичный интерфейсу редакции 7.7

Структура меню очень похожа на стандартную версию.


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

Понравилась статья? Поделиться с друзьями: