Меню
ГлавнаяAndroid

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

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

Теперь в том же Главном меню (оранжевая кнопка с треугольником) мы видим раздел «Все функции»

В котором все то, что мы так привыкли видеть в Бухгалтерии 2.0 в разделе «Операции»:

2) Теперь рассмотрим возможности программы в плане настройки интерфейса ТАКСИ. Например, сейчас у меня программа выглядит вот так:

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

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

Нажимаем кнопку «Применить» или «Ок» и вуа-ля, вот как стала выглядеть наша программа:

Возможно, кому-то так работать будет удобнее.

3) Еще один совет по настройке программы. Как правило, у каждого бухгалтера есть какие-то разделы или отчеты, которыми он пользуется ежедневно. Ну, например, ОСВ или ОСВ по счету. И было бы очень удобно, если они будут всегда рядом, всегда под рукой. Этого можно добиться весьма простым приемом, поместив необходимые отчеты в раздел «Избранное». Найдем в разделе «Отчеты» оборотно-сальдовую ведомость. Наведя на нее указать мыши, мы видим рядом серую звездочку.

Кликнув по ней, мы отметим выбранный отчет как «Избранное»

Раздел «Избранное» с помощью уже известного нам редактора панелей поместим, например, внизу рабочего окна программы.

4) И еще один «секрет» по настройке интерфейса программы. В различных разделах программы есть документы, которыми некоторые не пользуются никогда. Ну, просто в силу специфики деятельности организации. Например, в разделе «Покупки» документы, связанные с ЕГАИС.

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

В появившемся окне мы видим две колонки. Слева-команды которые можно добавить на наш рабочий стол. А справа, те команды которые есть на нашем рабочем столе. Находим с правой колонке раздел ЕГАИС и нажимаем на кнопку «Удалить»

Соответственно, документы которые находятся в правой колонке можно добавить на рабочий стол по кнопке «Добавить»

5) Ну и напоследок, для тех, кто никак не хочет привыкать к интерфейсу «Такси». Можно изменить интерфейс на тот, который был в первых версиях бухгалтерии 3.0.

В разделе «Администрирование» находим пункт «Интерфейс»

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

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

Для интереса посмотрим, что же такое интерфейс, аналогичный Бухгалтерии 7.7.

Ну не знаю, не знаю. Я пожалуй вернусь к привычному для меня «Такси».

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

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

Хотя управляемый командный интерфейс в 1с появился уже довольно давно, и информации о нем в интернете предостаточно я возьму на себя смелость еще раз написать про него. 1с в концепции управляемого интерфейса постаралась отойти от того что программист визуально рисует экранные формы документов, справочников и отчетов. Теперь это делается декларативно: описываете что, в каком порядке, в скольких колонках должно отображаться на экране, а система сама решает, как нарисовать ту или иную форму. Нужно заметить, что это относиться не только к формам, а ко всему интерфейсу вцелом. Такая декларативность интерфейса призвана облегчить переносимость системы, действительно конфигурация, написанная на управляемых формах, может запускаться как в тонком клиенте, так и в веб браузере - веб клиенте, таким чином у нас получается кросплатформенная среда, где с одной базой могут работать клиенты на разных операционных системах виндовс, линукс, макос.… Кроме того данный подход используется в версии 8.3 где к десктопным системам добавились еще и мобильные системы на базе андроида от Гугла и iOS от Еппла. Не смотря на некоторые ограничения по обэктам доступным при програмировании для мобильных клиентов концепция отсается тойже. Таким чином програмируя для мобильной платформы мы етот же код можем использовать и для десктопных систем. Внешний вид программы следующий:

Как видно интерфейс сейчас состоит из 4 основных частей:

  1. список разделов учета
  2. команды доступные к выполнению в выбранном разделе
  3. Навигация по разделу, который вы выбрали
  4. текущая форма (например, список документов, или список элементов справочника)

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

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

Подсистемы 1с

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