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

Инфа про управляемые формы 2018 год

https://wiseadvice-it.ru/o-kompanii/blog/articles/upravlyaemye-formy-1s-8-3/

Кухня работы с управляемым формами ("Под капотом управляемых форм")

https://infostart.ru/public/198766/

Пишут:

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

Смотри

https://school38vrn.ru/programmno-sozdat-upravlyaemuyu-formu-1s-osnovnoi-rekvizit-formy.html

Про управляемые формы в 2011 году

https://habr.com/ru/post/134151/ (РСА - много не понял)

Про объекты переноса данных теория

https://martinfowler.com/eaaCatalog/dataTransferObject.html

Data Transfer Object

An object that carries data between processes in order to reduce the number of method calls.

For a full description see P of EAA page 401

When you're working with a remote interface, such as Remote Facade (388), each call to it is expensive. As a result you need to reduce the number of calls, and that means that you need to transfer more data with each call. One way to do this is to use lots of parameters. However, this is often awkward to program - indeed, it's often impossible with languages such as Java that return only a single value.

The solution is to create a Data Transfer Object that can hold all the data for the call. It needs to be serializable to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects.

Many people in the Sun community use the term "Value Object" for this pattern. I use it to mean something else. See the discussion on page 487.

Although the main reason for using a Data Transfer Object is to batch up what would be multiple remote calls into a single call, it's worth mentioning that another advantage is to encapsulate the serialization mechanism for transferring data over the wire. By encapsulating the serialization like this, the DTOs keep this logic out of the rest of the code and also provide a clear point to change serialization should you wish.

The Sun/Java community's use of terminology has changed since the book was published. They switched to using "Transfer Object" as the name for this pattern. Consequently "Value Object" became regularly used in the way that I describe in this book.

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

См про автора https://martinfowler.com/aboutMe.html

I am Martin Fowler: an author, speaker… essentially a loud-mouthed pundit on the topic of software development, primarily for Enterprise Applications. I work for Thoughtworks, a software delivery company, where I have the exceedingly inappropriate title of "Chief Scientist". I have written half-a-dozen books on software development, including Refactoring, and Patterns of Enterprise Application Architecture. I write for and edit the website martinfowler.com.

"an intellectual jackal with good taste in carrion".

Про RemoteFacade ("Парадный вход")

https://martinfowler.com/eaaCatalog/remoteFacade.html

Макрокоманды или запросы, которые выполняют многие команды (мелкие запросы), чтобы получить все нужные данные объекта ОДНОЙ КОМАНДОЙ (запросом)

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

http://design-pattern.ru/patterns/remote-facade.html

Remote Facade

Provides a coarse-grained facade on fine-grained objects to improve efficiency over a network.

For a full description see P of EAA page 388

Remote Facade In an object-oriented model, you do best with small objects that have small methods. This gives you lots of opportunity for control and substitution of behavior, and to use good intention revealing naming to make an application easier to understand. One of the consequences of such fine-grained behavior is that there's usually a great deal of interaction between objects, and that interac-tion usually requires lots of method invocations.

Within a single address space fine-grained interaction works well, but this happy state does not exist when you make calls between processes. Remote calls are much more expensive because there's a lot more to do: Data may have to be marshaled, security may need to be checked, packets may need to be routed through switches. If the two processes are running on machines on opposite sides of the globe, the speed of light may be a factor. The brutal truth is that any inter-process call is orders of magnitude more expensive than an in-process call - even if both processes are on the same machine. Such a perfor-mance effect cannot be ignored, even for believers in lazy optimization.

As a result any object that's intended to be used as a remote objects needs a coarse-grained interface that minimizes the number of calls needed to get some-thing done. Not only does this affect your method calls, it also affects your objects. Rather than ask for an order and its order lines individually, you need to access and update the order and order lines in a single call. This affects your entire object structure. You give up the clear intention and fine-grained control you get with small objects and small methods. Programming becomes more dif-ficult and your productivity slows.

A Remote Facade is a coarse-grained facade [Gang of Four] over a web of fine-grained objects. None of the fine-grained objects have a remote interface, and the Remote Facade contains no domain logic. All the Remote Facade does is translate coarse-grained methods onto the underlying fine-grained objects.

По-русски

Описание Remote Facade

Предоставляет общий объединяющий интерфейс для набора методов объекта для улучшения эффективности сетевого взаимодействия.

Паттерн Remote Facade в объектно-ориентированной модели улучшает работу с маленькими объектами, у которых маленькие методы. Маленькие методы открывают большие возможности для контроля и изменения поведения, а также для улучшения понимания клиентом работы приложения. Одно из последствий такого "мелко-молотого" поведения в том, что обычно происходит много взаимодействий между объектами с вызовом множества методов.

В одном адресном пространстве "мелко-молотые" взаимодействия работаю хорошо, но всё меняется, когда происходит взаимодействие между процессами. Удалённые вызовы более затратны, потому что многое надо сделать: иногда данные нужно упорядочить, проверить на безопасность, пакеты должны быть маршрутизированы на свичах. Если два процесса работают на разных краях света, даже скорость света может играть роль. Тяжелая правда в том, что любые межпроцессные взаимодействия на порядок более расточительны, чем внутрипроцессные вызовы. Даже, если оба процесса работают на одной машине. Такое влияние на производительность не может быть упущено из вида, даже приверженцами ленивой оптимизации.

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

Паттерн Remote Facade представляет собой общий "Фасад" (по GoF) поверх структуры более "мелко-молотых" объектов. Ни один из этих объектов не имеет удалённого интерфейса, а Remote Facade не включает в себя никакой бизнес-логики. Всё, что делает Remote Facade - это транслирует общие запросы в набор небольших запросов к подчинённым объектам.

Использована иллюстрация с сайта Мартина Фаулера.

Источник

Не понял. Где первоисточник? Что значит "не пишите объекты переноса"?

https://habr.com/ru/post/134151/

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

Вот тут такого нет, хотя он пишет, что в локальном контексте нет смысла использовать "ОбъектыПереносаДанных" (DTO).  https://martinfowler.com/bliki/LocalDTO.html

Смотри:

Service Layer https://martinfowler.com/eaaCatalog/serviceLayer.html

Domain Model https://martinfowler.com/eaaCatalog/domainModel.html

Объекты переноса данных в 1С

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

1) системные (объекты переноса)

2) определяемые разработчиком (объекты переноса).

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

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

РСА Зачем  используются следующие команды? Смотри в синтакс-помощнике описание

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

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

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

Пример 1С v8.1:

// на клиенте в контексте формы
ЗаполнитьКэшПользователей(ПодразделениеСсылка)

Пример 1С v8.2:

// на сервере в контексте формы
ОбработкаОбъект = РеквизитФормыВЗначение("Объект");
ОбработкаОбъект.ЗаполнитьКэшПользователей(ПодразделениеСсылка);
ЗначениеВРеквизитФормы(ОбработкаОбъект, "Объект");

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

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

РСА Пример далее не понял

Далее также не понял

Упоминается:

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

Книга Разработка управляемого интерфейса

Разработка интерфейса прикладных решений на платформе «1С:Предприятие 8»

https://v8.1c.ru/metod/books/71121.htm

Книга https://litmy.ru/knigi/programming/157208-razrabotka-upravlyaemogo-interfeysa.html

Название: Разработка управляемого интерфейса

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

Издательство: 1С-Паблишинг   Год: 2010  ISBN: 978-5-9677-1148-0  Страниц: 724

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

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

Большое количество иллюстраций и практических примеров помогут читателю быстрее освоить новые технологии разработки.

На ИТС книга тут (для чтения нужна подписка)

https://its.1c.ru/db/pubmanagedui

Отборы в обычных и управляемых формах

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

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

Статья на инфостарте, как, какими инструментами переписать обычные формы в управляемые. См — синхронные/асинхронные вызовы, модальные/не модальные открытия окон; интерактивные операции?

https://infostart.ru/1c/articles/1149220/

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

В обычных формах:

- практически всю работу делал клиент (тащил сырые данные с сервера, обрабатывал и отображал результат)

- в любой момент в клиенте можно было делать синхронные, модальные и интерактивные вызовы/операции

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

В управляемых формах (толстый клиент не рассматриваем как атавизм):

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

- синхронные и модальные вызовы запрещены даже на клиенте

- работа с данными из СУБД возможна только на сервере

- код должен быть разделен на методы по контексту выполнения (клиент, сервер), а также в местах обратных вызовов (callbacks), т.к. код должен быть асинхронным

Вот про синхронные и асинхронные вызовы

https://1c-programmer-blog.ru/programmirovanie/sinhronnye-i-asinhronnye-vyzovy-v-1s.html

В чем разница?

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

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

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

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

• блокирующими окнами;
• файлами;
• расширением криптографии;
• внешними компонентами.

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

Соответствие синхронных методов асинхронным аналогам (на момент написания статьи) можно посмотреть тут.

Асинхронные методы

Рассмотрим на примере асинхронного метода глобального контекста — НачатьПоискФайлов.

&НаКлиенте
Процедура АсинхронныеМетоды()

ОбратныйВызов = Новый ОписаниеОповещения("ОбработкаЗавершения", ЭтотОбъект, "доп. параметры", "ОбработкаОшибки", ЭтотОбъект);

//поищем файлы в папке tmp

НачатьПоискФайлов(ОбратныйВызов, "D:\tmp", "*.*");

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

 
&НаКлиенте

Процедура ОбработкаЗавершения(НайденныеФайлы, ДополнительныеПараметры) Экспорт

//выводим список найденых файлов
Для Каждого Файл Из НайденныеФайлы Цикл
Сообщить(Файл.ПолноеИмя);
КонецЦикла;


//дополнительный параметр указанный в описании оповещения
Сообщить(ДополнительныеПараметры);
КонецПроцедуры

 

&НаКлиенте

Процедура ОбработкаОшибки(ИнформацияОбОшибке, СтандартнаяОбработка, ДополнительныеПараметры) Экспорт

Сообщить("Ошибка поиска файлов: " + КраткоеПредставлениеОшибки(ИнформацияОбОшибке));

Сообщить(ДополнительныеПараметры);

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

Отдельно отмечу конструктор объекта ОписаниеОповещения — в синтаксис-помощнике все параметры этого конструктора указаны как необязательные (на момент написания статьи). Вообще-то так оно и есть — можно создать объект не указывая параметров, но если указано имя процедуры или имя процедуры обработки ошибки (параметры 1 и 4 в примере выше), то обязательно нужно указать модули этих процедур (параметры 2 и 5 в примере выше) иначе Вас ждет ошибка — «Конструктор не найден».

Особенности веб-клиента

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

И, наконец, в коде нужно указать нечто  подобное:

&НаКлиенте

Процедура ОсобенностиВебКлиента()

#Если ВебКлиент Тогда

ОбратныйВызов = Новый ОписаниеОповещения("РасширениеПодключено", ЭтотОбъект);

НачатьПодключениеРасширенияРаботыСКриптографией(ОВ);

//НачатьПодключениеРасширенияРаботыСФайлами(ОВ);

#КонецЕсли

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


&НаКлиенте
Процедура РасширениеПодключено(Подключено, ДополнительныеПараметры) Экспорт
Если НЕ Подключено Тогда
НачатьУстановкуРасширенияРаботыСКриптографией(Неопределено);
//НачатьУстановкуРасширенияРаботыСФайлами(Неопределено);
КонецЕсли;
КонецПроцедуры

Расширение для 1С для браузера Хром

https://chrome.google.com/webstore/detail/1centerprise-extension/pbhelknnhilelbnhfpcjlcabhmfangik

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

Расширение используется приложениями, написанными на базе платформы 1C:Предприятие, при работе в браузере.

Полнофункциональные приложения на базе платформы 1С:Предприятие доступны через облачный сервис https://1cfresh.com/. Предоставляется 30-дневный ознакомительный период.

Учебная версия платформы 1С:Предприятие доступна бесплатно по ссылке http://online.1c.ru/catalog/programs/program/28765768/.

21.01.22