Как построить цепочку асинхронных вызовов
Разработка - Механизмы платформы 1С
Файлы
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний
Оформите подписку на компанию для решения рабочих задач
Оформить подписку и скачать решение со скидкойВы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Постановка задачи
Требуется выполнить несколько проверок одну за другой. Если некоторые из проверок не проходят, то необходимо вывести пользователю диалог, для принятия решения.
В зависимости от выбранного пользователем варианта, выполняются некоторые действия, а также может выполняться следующая проверка, либо сценарий может прерваться.
Использование модальности в конфигурации отключено.
Вложенная схема выполнения асинхронных вызовов (Классический способ)
Стандартный подход к решению данной задачи можно прочитать тут и тут
Схематично его можно изобразить так
Данный подход очень неудобен.
Во-первых, непонятно количество проверок. Чтобы его узнать, необходимо в коде переходить из одной процедуры в другую.
Во-вторых, приходится создавать по две процедуры на каждую проверку.
В-третьих, Проверка2 не имеет отношения к Проверка1 с точки зрения логики. Однако в Проверка1Завершение явно прописан ее вызов. Это нехорошо.
Линейная схема выполнения синхронных вызовов
Если бы по условию задачи можно было бы использовать модальные вызовы, то схема выглядела бы так.
Этот способ удобнее для использования. Все проверки вызываются из общей процедуры. Никакая проверка "ничего не знает" о других проверках. Мы можем менять их местами, отключать, ветвить и т.д.
При этом риск потери работоспособности кода - значительно ниже.
Линейная схема выполнения асинхронных методов
Оказывается, возможно организовать вызов асинхронных действий по аналогии с синхронной цепочкой.
Для этого можно использовать метод, который умеет, образно говоря, выполняться с того места, на котором остановился в предыдущий раз.
Сценарий
&НаКлиенте
Процедура ВыполнитьСценарийСДиалогами(Результат = Неопределено, ПараметрыСценария = Неопределено) Экспорт
НачатьОтсчетШагов(ПараметрыСценария);
Оповещение = Новый ОписаниеОповещения("ВыполнитьСценарийСДиалогами", ЭтаФорма, ПараметрыСценария);
// проверка 1
Если ЭтотШагЕщеНеВыполнялся(ПараметрыСценария) Тогда
ТекстВопроса = "Это вопрос 1. Продолжить?";
ПоказатьВопрос(Оповещение, ТекстВопроса, РежимДиалогаВопрос.ДаНет);
Возврат;
ИначеЕсли ЭтоРезультатВыполненногоШага(ПараметрыСценария) И Результат <> КодВозвратаДиалога.Да Тогда
// сюда попадаем если пользователь не ответил Да на первый вопрос
// выход из процедуры без открытия асинхронного метода - прервет выполнение сценария
Возврат;
КонецЕсли;
// проверка 2
Если ЭтотШагЕщеНеВыполнялся(ПараметрыСценария) Тогда
Если ЧастьТоваровОтсутствуетНаСкладе() Тогда
ТекстВопроса = "Это вопрос 2. Хотите заменить отсутствующие товары?";
ПоказатьВопрос(Оповещение, ТекстВопроса, РежимДиалогаВопрос.ДаНетОтмена);
Возврат;
КонецЕсли;
ИначеЕсли ЭтоРезультатВыполненногоШага(ПараметрыСценария) Тогда
Если Результат = КодВозвратаДиалога.Отмена Тогда
Возврат;
ИначеЕсли Результат = КодВозвратаДиалога.Нет Тогда
// переходим к следующему шагу сценария
ИначеЕсли Результат = КодВозвратаДиалога.Да Тогда
ОткрытьФормуПодбораАналогов = Истина;
КонецЕсли;
КонецЕсли;
// продолжение проверки 2. Открываем форму подбора аналогов асинхронно и обрабатываем результат
Если ЭтотШагЕщеНеВыполнялся(ПараметрыСценария) Тогда
Если ОткрытьФормуПодбораАналогов = Истина Тогда
ОткрытьФорму("Обработка.ПодборАналоговНоменклатуры.Форма",
ПараметрыСценария.ДополнительныеПараметры,
ЭтаФорма, , , ,
Оповещение,
РежимОткрытияОкнаФормы.БлокироватьОкноВладельца;)
);
Возврат;
КонецЕсли;
ИначеЕсли ЭтоРезультатВыполненногоШага(ПараметрыСценария) Тогда
ВыполнитьДействияСАналогами(Результат);
КонецЕсли;
// проверка 3. вопрос в цикле
Если ЭтотШагЕщеНеВыполнялся(ПараметрыСценария)
ИЛИ (ЭтоРезультатВыполненногоШага(ПараметрыСценария)
И Результат = КодВозвратаДиалога.Да) // повторяем вопрос, пока пользователь отвечает Да
Тогда
ТекстВопроса = "Это вопрос 3. Задать его еще раз?";
ПоказатьВопрос(Оповещение, ТекстВопроса, РежимДиалогаВопрос.ДаНет);
Возврат;
КонецЕсли;
// действия после проверок
ВыполнитьОсновныеДействия();
КонецПроцедуры
Служебные методы
&НаКлиенте
Процедура НачатьОтсчетШагов(ПараметрыСценария)
Если ПараметрыСценария = Неопределено Тогда
ПараметрыСценария = Новый Структура;
КонецЕсли;
Если НЕ ПараметрыСценария.Свойство("ПредыдущийШаг") Тогда
// при первом запуске основной процедуры это свойство отстуствует
ПараметрыСценария.Вставить("ПредыдущийШаг", 0);
КонецЕсли;
ПараметрыСценария.Вставить("ТекущийШаг", 0);
КонецПроцедуры
&НаКлиенте
Функция ЭтотШагЕщеНеВыполнялся(ПараметрыСценария)
ПараметрыСценария.ТекущийШаг = ПараметрыСценария.ТекущийШаг + 1;
Если ПараметрыСценария.ПредыдущийШаг >= ПараметрыСценария.ТекущийШаг Тогда
Возврат Ложь;
КонецЕсли;
ПараметрыСценария.ПредыдущийШаг = ПараметрыСценария.ТекущийШаг;
Возврат Истина;
КонецФункции
&НаКлиенте
Функция ЭтоРезультатВыполненногоШага(ПараметрыСценария)
Возврат ПараметрыСценария.ПредыдущийШаг = ПараметрыСценария.ТекущийШаг;
КонецФункции
Данный подход очень похож на синхронную цепочку и лишен описанных выше недостатков классического способа.
Файлы
Для иллюстрации прикладываю микроконфигурацию с единственным документом, который выполняет действие Провести и закрыть с несколькими проверками. Это переделанная конфигурация из этой статьи.
Также в качестве примера прикладываю обработку, которая задает два вопроса и одно предупреждение по описанной методике, для тех кому лень разворачивать конфигурацию. Она открывается в управляемом режиме в любой конфигурации на платформе 8.3
Послесловие
Данная схема была разработана при решении производственной задачи. Источником идеи послужило вот это видео
Вступайте в нашу телеграмм-группу Инфостарт
См. также
Механизмы платформы 1С Разработчик Бесплатно (free)
Разберем 15 мифов о работе платформы «1С:Предприятие 8» – как распространенных, так и малоизвестных. Начнем с классики: «Код, написанный в одну строку, работает быстрее, чем многострочный». Так ли это на самом деле?
16.07.2025 45588 TitanLuchs 109
Работа с интерфейсом WEB-интеграция Механизмы платформы 1С Бесплатно (free)
Веб-интерфейсы повышают качество внешнего вида приложений 1С, предсказуемы с точки зрения верстки, позволяют организовать удобные и высокопроизводительные рабочие места для пользователей. Расскажем об особенностях разработки веб-интерфейсов на React внутри 1С, двустороннем взаимодействии 1С и JavaScript, а также сборке веб-приложения в одностраничный файл.
19.06.2025 18621 zeegin 15
Механизмы платформы 1С Работа с интерфейсом Разработчик Стажер 1С:Предприятие 8 Бесплатно (free)
Про ООП в 1С и о том, как сделать свой код более кратким и выразительным при помощи использования текучего интерфейса (fluent interface).
03.02.2025 25982 bayselonarrend 127
Механизмы платформы 1С Разработчик 1С:Предприятие 8 Бесплатно (free)
В этой статье подробно рассматривается работа с JSON в XDTO в 1С:Предприятие. Вы узнаете, как сериализовать и десериализовать объекты XDTO в JSON, интегрировать 1С с веб-сервисами и API, а также корректно обрабатывать данные при обмене. Разбираются особенности работы с коллекциями, использование функций восстановления и частые ошибки при работе с JSON и XDTO.
30.01.2025 33211 user2122906 10
Механизмы платформы 1С Файловый обмен (TXT, XML, DBF), FTP Разработчик 1С:Предприятие 8 Бесплатно (free)
Этот материал познакомит вас с механизмом XDTO (XML Data Transfer Objects) в 1С и научит эффективно использовать его возможности. Мы разберёмся, как работать с XML-схемами, создавать модели данных, манипулировать объектами XDTO, а также сериализовать и десериализовать их в XML. Вы узнаете, как использовать XDTO для интеграции с внешними системами, избегать типичных ошибок и оптимизировать код. К концу вы будете уверенно применять XDTO для решения сложных задач обмена данными и автоматизации процессов.
17.01.2025 55614 user2122906 13
Механизмы платформы 1С WEB-интеграция Разработчик 1С:Предприятие 8 Бесплатно (free)
В платформе 8.3.27 появилась возможность использовать WebSocket-клиент. Давайте посмотрим, как это все устроено и чем оно нам полезно.
14.01.2025 46728 dsdred 110
Механизмы платформы 1С Разработчик 1С:Предприятие 8 Бесплатно (free)
Особенности "Знач" и разбор документации к нему.
10.01.2025 26409 VAAngelov 60
Механизмы платформы 1С Разработчик Стажер 1С:Предприятие 8 1C:Бухгалтерия Бесплатно (free)
Эта небольшая статья - некоторого рода шпаргалка по файловым потокам: как и зачем с ними работать, какие преимущества это дает.
23.06.2024 40404 bayselonarrend 24
Если ПараметрыСценария = Неопределено Тогда
// первый вход в процедуру выполняется без параметров
ПараметрыСценария = Новый Структура;
ПараметрыСценария.Вставить("ТекущийШаг", 0);
Иначе
Если Результат <> КодВозвратаДиалога.Да Тогда
Возврат;
КонецЕсли;
ПараметрыСценария.ТекущийШаг = ПараметрыСценария.ТекущийШаг + 1;
КонецЕсли;
Если СписокЗначений.Количество() = ПараметрыСценария.ТекущийШаг Тогда
ВыполнитьОсновныеДействия();
Возврат;
КонецЕсли;
ТекстВопроса = СписокЗначений[ПараметрыСценария.ТекущийШаг];
//ТекстВопроса = ПолучитьТекстВопроса(ПараметрыСценария.ТекущийШаг);
//Если ТекстВопроса = Неопределено Тогда
// ВыполнитьОсновныеДействия();
// Возврат;
//КонецЕсли;
Оповещение = Новый ОписаниеОповещения("ВыполнитьСценарийСДиалогами", ЭтаФорма, ПараметрыСценария);
ПоказатьВопрос(Оповещение, ТекстВопроса, РежимДиалогаВопрос.ДаНет);
ПоказатьПо поводу того, что вариант со списком проще - не готов согласиться, но тут каждый может реализовать так, как считает правильным.
А вообще буквально недавно надо было на стороне клиента сделать НачатьПроверкуСуществования(..) и потом если нет каталога, создать его НачатьСозданиеКаталога().
Но бывает еще сложнее задача когда надо через цикл сделать несколько вызовов НачатьХХХ, потом после оповещения еще вызвать НачатьХХХ и при этом у процедур оповещений разное количество параметров. Например у НачатьУдалениеФайлов процедура оповещения имеет только 1 параметр.
Вы скорее всего имели не таблицу значений, а массив структур, т.к. действия выполняются на клиенте
Но даже если мы будем использовать такую коллекцию, то нам придется выбирать между двумя невыгодными вариантами:
1. Либо писать процедуру обхода такой коллекции для каждого сценария. Тогда каждый такой обход будет содержать специфические для данного сценария действия. В чем же тогда простота?
2. Либо нужно написать очень универсальный метод, в котором каждый элемент коллекции шагов должен содержать множество ключей, типа "СоответствиеДействийИОтветов", "ОтветДляПрерыванияСценария" и т.п. в таком духе. Похожий подход с массивом структур уже реализован в БСП, правда он используется для другого. Если интересно, можете посмотреть в демо БСП (2.3.2) внешнюю обработку ЗагрузкаНоменклатурыИзПрайсЛистаСоСценарием.epf, а в ней функцию СформироватьСценарий(). Я предполагаю, что если попытаться написать универсально, то получится что-то подобное. Там довольно большой объем служебного кода, трудно быстро понять, какие параметры за что отвечают. Хотя этот механизм и рабочий, но порог вхождения в работу с ним - довольно высокий.
В моем примере (я его чуть усложнил) всего три универсальные обслуживающие процедуры и одна основная. При этом читаемость (описания шагов) не страдает, по сравнению с описанием сценария, а универсальность намного выше
Остается надежда на 8.4/9.0...
Следующий такой ошибкой стала "защита от опасных действий", но она не столь сильно влияет (просто "защита" не защищает, а немного усложняет жизнь программистам).
Типа так:
Вопрос
1 - Ответ 1
2 -- Вопрос 2
3 --- Ответ Х
4 --- Ответ У
5 - Ответ 2
6 -- Вопрос 3
7 --- Ответ Z
8 ---- --- ИД = 2 (переход к ветке вопросов с ИД 2)
Чем не метод?
Меня всегда удивляли подобные комментаторы, которые бросают вот такие фразы. Ведь толку от них ноль.
Ну не нравится тебе статья, пройди дальше, не читай. Ведь никто же не заставляет. Возможно другим она будет полезна.
Бывает, что не согласен с точкой зрения автора - значит аргументируй. Может действительно у человека есть здравая мысль. Пусть не скрывает ее.
А какой смысл от пустых обвинений?
Модальность не нужна. Попытки ее вернуть, применяя указанные обходные решения, ни к чему хорошему не приведут. Много вы видите в интернетах "цепочек модальных диалогов" на сайтах? А пользоваться удобно, как ни странно.
Текущие диалоги, вызываемые через ПокахатьXyz() - модальные. И ничего не мешало сделать эту модальность "асинхронной", т.е. не блокирующей основной поток на клиенте и с использованием старого синтаксиса.
Описание "правильного" костыля в видеоуроках (буэээ..).
И да, под "модальностью" в предыдущем сообщении я понимал именно блокирующую текущий поток модальность, а не сам концепт "модального окна".
а если не надо сохранять? а если надо перевыбрать файл/изменить имя вместо перезаписи? То, что в данном случае этот модальный диалог в цикле - системный, глобально ничего не меняет.
Вот примеры из жизни (было несколько месяцев назад при доработке ерпи)
Требуется добавить проверки в заказ поставщику перед действием Провести и закрыть
1. Проверить, что сумма заказа соответствует бюджету. Вывести вопрос
2. Проверить, что остаток после заказа плюс остаток на складе - не превысит норму. Если превысит - вывести вопрос.
3. Проверить ограничения, накладываемые поставщиком (что количество товара больше или равно минимальной партии). Вывести вопрос
При проведении поступления
1. Проверить соответствие цен в поступлении ценам в заказе. Если различаются - вывести сумму отклонения и вопрос.
2. Проверить соответствие количества в поступлении количеству в заказе. Если некоторый товар не пришел, то предложить: ничего не делать, перенести в новый заказ (открыть мастер создания заказа поставщику), удалить из текущего, вернуться к редактированию.
Эти проверки были добавлены поверх существующих типовых. Нетрудно догадаться, что это все будет развиваться и усложняться со временем. Через некоторое время у заказчика появятся новые хотелки.
2. Проверить, что остаток после заказа плюс остаток на складе - не превысит норму. Если превысит - вывести вопрос.
3. Проверить ограничения, накладываемые поставщиком (что количество товара больше или равно минимальной партии). Вывести вопрос
Зачем три вопроса вместо одного окна с перечнем проблем? Вы, пожалуй, невнимательно прочитали мое первое сообщение. Потребность в цепочках вопросов возникает при некачественно спроектированном взаимодействии с пользователем. Три вопроса вместо одного - это некачественное взаимодействие. Вырождающееся впоследствии в необходимость разработки "цепочек вопросов в асинхронном режиме".
вторая ветка - при отстутсвии - создать (асинх), скопировать файлы (асинх), отрапортовать пользователю.
Согласен, что некачественное и что лучше сделать одну форму.
Но тут возникают противоречия.
Во-первых, если уже есть решение, которое построено через вопросы. Что делать? Часть вопросов будет в одной форме, а часть в отдельных окнах. Переделывать?
Во-вторых, бюджет на то, чтобы нарисовать интерфейс - больше, чем на более простое решение.
В-третьих, что делать, если нужно в одной из проверок открыть другую уже существующую форму (например, мастер создания Заказа поставщику)?
В-четвертых, был еще такой случай, что сначала нужна была одна проверка. Сделали через вопрос. Потом понадобилась еще одна. И никто уже написанное другим разработчиком не переделывает и в бюджет не закладывает.
Но мне подход без цепочки тоже нравится больше, в том случае есть возможность его использовать
Сможете предложить решение без цепочки вопросов?
И так поток действий...
1. Проверка наличия файла
2. Проверка свойств файла (для получения расширения)
3. Если архив распаковка
4. Если архив проверка существования файла в распакованном каталоге
5. Загрузка данных файла
Большинство этих действий асинхронны, получится целый набор описаний оповещений которые должны сработать последовательно (ну или в обход). Вот в таких случаях конечно удобно, если бы был менеджер асинхронных действий.
Хотя в тех же js promise у меня был бы очень простой код:
getFile() // обещаем что сообщим когда получим файл
.then(getFileAttr) // обещаем что сообщим когда получим свойства файла
.then(unzipFile) // обещаем что сообщим когда распакуем, а если не архив то вернем resolve
.then(loadFileData) // загружаем данные
.catch(errorHandler) // перехватим ошибкуЯ не люблю несколько вопросов, предупреждений и прочих всплывающих окон подряд. Тут я согласен, что надо пересматривать алгоритмы, выводить одно сообщение с набором нестыковок. Но вот что касается не диалоговых асинхронных вызовов, тут пока не очень удобно работать.
Но развитых средств асинхронного программирования в языке 1С вряд ли приходится ожидать. Во-первых, все эти асинхронные заморочки возникают только для веб-клиента - а этот вариант работы пользователя все же не преобладающий, хотя спектр его применения и растет. А во-вторых, компилятор - самая консервативная и трудно поддающаяся развитию часть платформы. Заметили, наверное: возможности платформы, начиная с 8.2, расширяются только за счет увеличения числа классов объектов платформы, а не развития языковых средств и конструкций.
Сейчас все языки двигаются в сторону асинхронности, многопоточности, функциональности. Лямбда-функции и рекурсивные механизмы активно внедряются даже в С++, который раньше не был таким функциональным. И сделано это, полагаю, для лучшей распараллеливаемости, ибо функциональная парадигма весьма способствует этому.
в js уходят от этого в сторону промисов, до этого - были замыкания и люмбды, которые помогали писать в болееменее синхронном стиле (по крайней мере строки визуально шли в одном месте и по порядку), в дотнете - в сторону async/await. и на момент появления "асинхронности" в 1с - эти механизмы уже были.
Ценность 1с как раз в том, что она скрывает от прикладного программиста все эти низкоуровневые дела. Вы просто не пытались сделать обновление на новую версию программы, скажем, с изменением структуры данных, причем так, чтобы это прошло безопасно, не на 1с.
В 1С кое-что, конечно, с ног на голову, но асинхронность как раз позволяет отделить механизм отображения от механизма обработки результата, выделив код обработки отдельно. При том никто не мешает выделить функции оповещения в отдельный модуль и поддерживать оные там. Мне, например, стало куда комфортнее обрабатывать множество реакций на события в одной асинхронной функции, определяемой в описании оповещения.
По поводу асинхронности, то в том же js даже для генерации кадра используют асинхронную функцию requestAnimationFrame, до этого использовали таймаут. Промисы - это супер, может быть и в 1С это реализуют, но тут, конечно, не все так просто.
Я не говорю, что 1С - штука идеальная. Она прежде всего очень медленная - это основное. При этом она позволяет сделать какой-нибудь интерфейсный прототип с хранимыми в СУБД данными достаточно быстро (не быстрее, конечно, чем Tcl/Tk, но тоже вполне сопоставимо по времени).
Ну, причина, в общем, извинительная - делалось на скорую руку, под ограничения браузеров.
Есть и еще одна причина глобального характера: 1С продает не платформу, а готовые решения. Поэтому им нафиг не вперлось ни ООП, ни вообще какое-либо развитие языка: команду своих 30-40 штатных разработчиков легко построить, чтобы писали на том, что дают, и хотелки-помечтовки свои при себе держали. А проблемы сторонних разработчиков, пишущих с нуля, при таком целевом раскладе никого не волнуют.
А мелкософтовский MSDN по сцылке говорит, что это для 8-й венды, а кто на 10-ке творит - нажмите другую сцылку. Но асинхронность - это не дань моде, а попытка утилизировать дополнительные процессорные ядра.
Просто, как мне кажется, некоторых студентов в ВУЗах переучивают излишне, а потом они, видя nginx или redis, которые позиционируются как безблокировочные однопоточные приложения, начинают всем говорит о том, что вот, мол, асинхронность - зло, многопоточность - медленная. Ну это дань нашему отставшему образованию - не более. На сайте Интела для разработчиков прямо с порога про многопоточность втирают, что без этого ни один уважающий себя программист жить не может в мире современном.
Я просто предупредил, чтобы не ждали некоторые от встроенного языка платформы 1С:Предприятие чудес вроде ООП и разных прочих async'ов/await'ов - и сказал, почему я так считаю.
Сам почти 2 года назад озаботился этим. Применил сущность типа "стек" для организации очередности возврата глубоких асинхронных вызовов. Сделал даже видеокурс для УЦ-3:
А ещё забавляют наивные мечтания. 1С это система для бухгалтеров, расчётчиков и кадровиков. Несколько меньше - для торгашей. 1С это периодически забывают и начинают лепить совсем уж маразм, но потом их на конференциях окорачивают. Так вот, нахрен этот веб-интерфейс не нужен. Люди работают через rdp-терминалы. А в терминалах на мощные машины и толстый клиент прекрасно себя чувствует.
Желающие мечтать - спросите у Сергея Нуралиева о сроках появления интерфейса "Такси" в мобильном приложении)))
Они там пишут:
Любой сотрудник будет работать там, где ему удобнее. И я считаю, что именно задача ИТ сделать такую инфраструктуру, чтобы людям было УДОБНО. А единая система, которая позволяет выполнять ВСЕ действия, не переключаясь на другие не интегрированные с ней программы, именно таким решением и является. Именно таким путем идет 1С. И я здесь вместе с ней, потому что мой разум не ограничен мыслями, что 1С - это только бухгалтерия.
Сотрудник будет работать там, где ЕМУ удобнее. А удобнее - это привычнее. А привычнее - это в экселе, ворде, блокноте, на коленке. ИТ тут бессильна. Есть хорошая ковбойская поговорка: "и один человек может привести лошадь на водопой, но даже 10 не заставят её пить". Тут что-то может только адм.ресурс. Ну, вам повезло, но это исключение. Звёзды так сошлись, бывает.
...наивные вы ребята. Вот пообщаетесь с реальными клиентами, вроде крупных госконтор или контор с участием гос.капитала, сра-а-азу всё поймёте. И попробуйте вякнуть, например, гендиру Росгосстраха, что 1С это не только бухгалтерия и что "разум ограничен". Ага. Вам сразу всё очень доходчиво объяснят, где Вы, где место 1С, и где место ИТ как сервисного подразделения)))
Вот тут Вы правильно заметили... В РГС ИТ именно там, где Вы думаете. А вот если взять коммерческих передовых страховщиков, то там совсем все по другому... Это по собственному опыту.
P.S. Повторюсь: я согласен, что типовые конфы - ужасные тормоза, что БСП перегруженный монстр, но не согласен с тем, что 1С не нужно расти как учетной системе за пределами бухгалтерии.
Попробуйте объяснить клиенту, почему УТ 11, пустая и новая, дико тормозит при попытке открыть "Все функции", или любую форму списка, или вообще при нажатии любой кнопки, а его, клиента, огроменная УТ 10.3 за 10 лет всё делает мгновенно) Почему треть экрана в "Такси" занята неотключаемой пустотой, а чтоб смотреть данные, приходится всё время скроллить форму.
Попробуйте объяснить мне, почему на клиенте в 1С нет объекта "Таблица значений", или метаданных, или почему нельзя управлять составом данных формы, передаваемым на сервер, или почему, на самом деле, сделали этот адский костыль под названием обработка оповещения.
Почему так тормозит конфигуратор при разработке управляемой формы, и почему эта якобы "управляемая" в разы менее доступна для настройки дизайна, чем обычная, тормозит сильнее и жрёт больше ресурса.
Короче говоря - я много лет занимался разработкой под тонкий, веб, с управляемыми формами. И мой вывод - это уродство.
Кстати о браузерах: вот сейчас ИС сглючил при отправке этого текста. Вы себе представляете восторг менеджера, который час набивал документ, а потом сеть/браузер/1С глюканули, и всё пропало? А я вот работал по сети с СППР, где это было нормой, и никогда больше не порекомендую своим клиентам использовать веб-клиент 1С. Но, конечно, если ваша задача - впарить "моднявый" продукт в тренде "все в сеть", а дальше трава не расти, то, конечно, флаг в руки.
Медленно работает - это на сколько медленно и что именно? Если взять пустую базу и открыть все действия, то ничего медленного не будет. Тут не проблема толстого/тонкого клиента - тут проблема излишней раздутости конфигурации, которая должна делать простые вещи. Но все же не хотят что-то делать сами, поэтому или копипастят (и этим поддерживают авторов, еще раз рассказывающих об основах), или тащат в свою систему все подряд (БСП - все стопиццот версий, модулей, картинок, макетов, ...). В принципе нет ничего плохого во фреймворках, но то, сколько всяких модулей понапихано в ту же третью бухню - вот это вымораживает. Весь тот функционал можно с командой не слишком умных выпускников какого-либо ВУЗа запилить на PHP за достаточно небольшое время. Вообще, тормоза - это извлечение всех команд формы, связанных с размещенными на ней данными и глобальными командами - вот они там уйму времени получаются.
По поводу немодальности и асинхронности, то тут у нас с Вами совершенно разное понимание. Мне, например, гораздо удобнее напилить управляемую форму любой сложности, чем потом мучиться с привязками обычной формы. Да и сама 1С вечно натворит руками программистов за тарелку супа с обычными формами кучу кривых привязок, скрытых панелей, невидимых страниц - потом замучишься искать, где там и что в каком элементе спрятано. Объединить старую и новую формы нереально, в управляемой же форме все элементы в дереве, БСП позволяет просто и легко привязывать команды и дополнительные реквизиты к форме. В общем для меня преимущество управляемых форм очевидно.
Браузеры давно уже вполне безопасны, ибо HTTPS начиная с TLS 1.1 безопасен. Настроить подобное внутри сети вообще не является проблемой - достаточно самоподписанного сертификата, сгенерированного на веб-сервере. Но в действительности защиту информации дает не шифрование трафика, а ролевое разделение и нескомпрометированные учетные данные. Внутри корпоративной сети как раз доступ к информационной системе из браузера - это вполне здоровая практика.
По поводу глюка с отправкой, то и 1С нередко глючит и вылетает. Но как раз клиент-серверная архитектура позволяет серверу работать с множеством клиентов, а клиентам быть лишь поставщиками данных для сервера. Тут все упирается в архитектуру решений: если программист постоянно гоняет данные на сервер, таким образом обрабатывая их по-частям, то такой программист просто живет еще в мире старых реалий. Или ему нужно обработать данные на клиенте, а потом все целиком передать на сервер для записи, или ему нужно все сразу не сервере обрабатывать. Но пользователя при этом необходимо как-то проинформировать. И вот тут как раз эта "асинхронность" и должна применяться, когда на сервере запущен процесс обработки, а на клиенте запущен обработчик ожидания, функция которого сводится к тому, чтобы опросить серверный процесс на предмет прогресса и отобразить эту информацию пользователю. 1С это пока иначе как через фоновые задания делать не умеет - очень ее жаль по этому поводу. Но примерно так же дело обстоит и в прочих клиент-серверных приложениях, так что не все так плохо. Другое дело, что иногда в 1С программисты за тарелку супа делают эту асинхронность просто везде. И это даже не их проблема - это проблема общей архитектуры, когда просто дана команда повесить все на свете на обработчик длительных операций. И на столько уж они усираются, что даже обработку управления регламентными и фоновыми заданиями перепилили на оный функционал, что привело к тому, что она еще дольше стала работать, но хоть теперь интерфейс не висит - и то радость )))
Ну и, тогда уж, надо учесть, что не у всех асинхронников завершающая процедура имеет два параметра, и что платформа не понимает юмора, как обязательные они объявлены или нет, поэтому одной супер-процедурой всё равно не обойтись. По количеству аргументов, у меня таких "ловчих" обычно 3-4 штуки на разные случаи.
Управляемая форма "любой" сложности сложнее 10-15 групп - начинает вешать конфигуратор. На любом известном мне релизе. Привязки позволяют, хоть и помучившись, сделать то, чего на УФ просто ваще никак не сделать. Лучше плохо ехать, чем хорошо стоять, так считаю. Мог бы сказать насчёт плохого танцора и привязок, которые на самом деле элементарны, да Вы и сами поняли.
Скрытые панели и элементы? Так вот почему невидимый элемент в обычных формах виден, а в управляемых - нет. Это чтоб нам жилось легче! Искать замучились? А дерево объектов формы не пробовали юзать, оно в обычных очень даже есть, а? Или Вы про него не в курсе?
Объединить, говорите, нереально? То-то при копипасте в обычных формах всё куда надо плюхается, а в управляемых либо не копируется, либо криво (команды вяжутся не пойми куда, объекты не вяжутся к командам, пути к данным полей бьются, ряд случаев просто кончается вылетом с дампом).
Про БСП не буду. Во-первых, это уже не о платформе речь, а во-вторых, не хочу об этой дряни вообще разговаривать.
Очень хочется управлять кэшированием на клиенте и отправкой на сервер более гибко. Как в нормальных мобильных приложениях, если девайс вдруг без связи. Хочется уметь рулить временем жизни этих данных. Хочется рулить отправкой на сервер гибче, чем "БезКонтекста" или с контекстом. Да только увы.
client.callApi('messages.getDialogs', {offset_date: 0, offset_id: 0, offset_peer: peer, limit: 0})
.then(result => { // тут оказываемся в конце асинхронного вызова
let chats = result.chats.list;
return chats.reduce((promise, elem) => {
return promise.then((resArray) => {
if (elem.creator) { // если свойство creator установлено, то делаем еще один асинхронный вызов
return client.callApi('messages.getFullChat', {chat_id: elem.id}).then((res) => { // по завершению которого
resArray.push(res); // кладем результат в массив-накопитель
return Promise.resolve(resArray);
});
} else {
return Promise.resolve(resArray); // если ничего не надо делать - вызываем метод-пустышку (типа ВыполнитьОбработкуОповещения)
}
});
}, Promise.resolve([]));
}).then(result => { // обрабатываем результат Показатьон вызывает асинхронный метод messages.getDialogs, результатом является массив. Затем выполняется обход массива с вызовом асинхронного метода для каждого элемента, последовательно (еще есть Promice.all, который запускает всё параллельно, но сервер за такое банит :))
результаты каждого вызова кладутся в массив. Когда все вызовы завершатся, переходим в //обрабатываем результат
Не используется ни одной глобальной переменной.
Как подобное реализовать в 1с (например рекурсивный обход со всякими файловыми функциями начатьполучение и асинхронное чтение из файлов) - плохо представляю.
хотя данный пример кода показывает, что в js все тоже не так гладко, но, по крайней мере, такие асинхронные цепочки получаются локализованными и последовательными. Также пример показывает асинхронное ветвление, которое в 1с превращается в ещё бОльшее спагетти.
p.s. вот мне так наглядно 10 лет объясняли в таких конторах, где место 1С, что энтузиазма - ни на килобайт.
Например там узнал что программа может сама переделать цепочку модальных вызовов в не модальные
А из рефакторинга самые полезные функции - переименование и вынос блока кода в процедуру. Это базовые возможности любых нормальных IDE, без которых жутко неудобно, если привык.
Без легкого переименования у не тру-программера может не подняться рука на смену имени на более подходящее (тру-программеры понимают, как это важно).
А вынос блока кода в процедуру очень хорошо подходит к стилю программирования многих (меня в том числе). Мало кто способен в голове сразу выстроить инфраструктуру будущего кода на микроуровне (понятно, что глобальные блоки продумываешь сразу). Обычно пишешь простыню и структурируешь ее по ходу. И эта возможность заметно упрощает процесс.
Еще несколько интересных советов по настройке конфигуратора я вычитал у Хрусталевой в книжке "101 совет начинающим разработчикам" (настройка подстветки текущего идентификатора, например - нигде до этого не встречал, а ведь реально полезно).
Сделав ставку на УФ, 1С "просела" в части решений, где тонкий клиент не нужен. Толстый клиент жрет меньше серверных ресурсов, более отзывчив, позволяет строить более продвинутые интерфейсные решения, "моноприложение" разрабатывать проще. И далеко не всегда это перебивается плюсами тонкого клиента.
Но выхода особого у 1С не было. Тонкие клиенты - это понятный и устойчивый тренд, а поддерживать параллельно две архитектуры - глупо по многим причинам. Но там, где тонкий клиент не нужен - да, страдает клиент :)
И я больше согласен с Bonov и starik-2005 - вокруг себя я вижу все больше ситуаций, когда тонкий клиент приносит реальный профит. Да, даже в средне-больших организациях может не быть потребности в тонком клиенте. Но все чаще возникает. И да - все чаще 1С используется для сквозной автоматизации предприятия и как интеграционная платформа уровня предприятия (не в последнюю очередь благодаря тонкому клиенту). Но да, я сейчас говорю не про типовые решения...
Да и за один только динамический интерфейс тонкому клиенту можно простить многое.
Разработчика УФ тоже форсит на многие полезные вещи - распределение нагрузки, система доступов, минималистичный интерфейс... Убийство толстого клиента давно пора понять и простить :)
БСП тоже зря тут ругаете. Не взять в самописку подсистемы управления доступом, контактной информацией, печати, РИБ (по необходимости) и еще пару-тройку полезностей - это надо быть ССЗБ.
А вот простить конфигуратору, что управляемая форма, блин, открывается полторы минуты (на хорошем сервере) - лично я не могу. Клиент не понимает, почему время работ так выросло, и платить за тормоза конфигуратора не хочет. И скажите ещё мне, что у меня руки кривые, что я плохой танцор, и что форму документа типовой конфы без изменений в конфигураторе неправильно открываю)))
Рейтинг: 3437
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 574920
Создание 11.01.17 01:33
Обновление 06.02.17 04:35
Просмотры 34311
Загрузки 6
Рейтинг
74
Комментарии 70
Код открыт Не указано
Рубрики Механизмы платформы 1С
Кому Разработчик
Тип файла Внешняя обработка (ert,epf)
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)
