В последних версиях, активно работающих в веб-клиенте и на мобильных приложениях, 1С начала агрессивно продвигать новый подход к модальности, к работе с модальными окнами и диалогами. На эту тему много и убедительно написано в методическом сопровождении, статьях на сайтах и в комментариях специалистов. Но не будем поддаваться, посмотрим критически на предлагаемые нам новшества. Причём рассуждать я хочу как типичный «одинэснег». Обойдусь без пересказа статей, копипаста Синтакс-помощника и раскрытия технических терминов, подразумевая, что читателю оно уже всё известно.
Основные претензии:
Многое, что можно было «спрятать» в платформе и сделать своими силами, просто перевалено на плечи разработчиков 1С. С больной головы на здоровую. То ли в 1С не захотели это сделать, то ли не успели (последнее заметно по целому ряду прецедентов, когда самоочевидные вещи «подтягивали» по ходу выпуска релизов, не успев сделать сразу).
Предложена идеология, резко увеличивающая объём кода, а значит, затрудняющая работу с ним. Обещанный рефакторинг касается лишь простейших случаев, что уже честно признано.
Во-первых, сила и убедительность многих статей в том, что там очень красиво и аккуратно перемешаны совершенно разные понятия – модальность окна и асинхронность выполнения кода. Под модальностью подразумевается невозможность переключения в другие окна, пока это окно держит фокус. Под асинхронностью – ветвление логики и хода выполнения действий, превращение одной цепочки действий как последовательности команд в две и более, выполняемые параллельно, в т.ч. без взаимных привязок, согласований и вообще без внимания друг к другу (аппаратные тонкости оставим вне рассмотрения).
Во-вторых, нам печально повествуют, что всплывающие окна, как нехорошее рекламное нечто, блокируются браузерами (т.е. требуют разрешения на включение) и вообще не поддерживаются мобильными устройствами, а значит, маст дай. Более того, авторы некоторых методических статей ненавязчиво намекают, что в будущем 1С намерена полностью отказаться от модальности, что это «генеральная линия партии», и хотя нам милостиво разрешено пока жить по-старинке, но будущее уже предрешено и в нём нет места для «Предупреждение(«Hello, World»)». Пугают, стало быть.
Необходимость применения модальных окон является данностью, избежать которой полностью невозможно, причём отнюдь не по техническим, а по идеологическим соображениям. Всегда возможна ситуация, когда пользователя нельзя пускать «дальше», позволить ему продвижение в его работе, пока не будут выполнены некоторые действия. В этом смысле модальными можно называть и окна пошаговых «мастеров», где кнопка «Далее» недоступна до удовлетворения неких условий. Модальность – не в том, что окно маячит поверх остальных и не даёт переключиться (оно может выглядеть как угодно), а в том, что пользователь локализован в своих действиях более узко, чем в других случаях работы с приложением. Модальность – не реализация, не внутренние глубины, недоступные пользователю хитросплетения, а поведение интерфейса. Задумаемся: разве не так себя ведут все диалоги, инициированные пользователем и ждущие от него необходимых уточнений? Именно так. И браузеры не исключение – диалог загрузки файла, или запрос на разрешение cookies, или вопрос насчёт сертификата – были и остаются модальными окнами. Настроечные аспекты, вопросы всяких FlashPlayer, антиспамы, антивирусные диалоги, принтеры и работа с печатью – модальны. И замечательно себя чувствуют в интернетах. Значит, не собирается мир пока уходить от модальности.
Теперь посмотрим, что нам предлагается – свойство, управляющее блокировкой интерфейса/окна. По сути, для нашего юзверя, то же самое. Нам в плюс, что поведение более управляемое, можно задавать в коде; нам в минус, что головной боли об этом чуть больше. Но пользователю, в общем, плевать, почему он не может, открыв окно «1», щёлкнуть по кнопке в окне «2». Внимание, вопрос – где же пресловутый отказ от модальности?
Всплывающие окна. Pop-up. Всякая бяка из интернета. Да-да, конечно, пусть даже браузер совсем их не понимает и не поддерживает, но как тогда 1С реализует эти «блокируемые» окна? И что мешало тихо и незаметно реализовать функцию «Вопрос» так же, как реализуется рисуемая нами форма, блокирующая весь интерфейс, по аналогичной концепции? Ничего ровным счётом. Как-то ведь фирма 1С планирует отрабатывать эту блокировку, так отрабатывали бы и модальные диалоги.
Невинно пострадала процедура «Предупреждение». Полный аналог команды alert, которая отнюдь не является всплывающим окном, она, тем не менее, попала под запрет. Хорошо хоть, описание оповещения необязательное. Мне могут возразить, что в планах 1С есть вывод туда форматированной строки и вообще неизвестно, может, это тоже маленькая отдельная формочка, а не alert. Но тогда см.выше, что мешает ей быть такой формочкой с блокировкой интерфейса, не делая мне головной боли? И что мешает для вывода форматированной строки применить «ПоказатьОповещениеПользователя» (к которой тоже есть претензия именно ввиду её совершеннейшей немодальности – помигало и исчезло, а юзверь мог и не заметить)?
Тем более ни при чём действия с выпадающим списком, в режиме списка и меню. Если 1С оставила такую штуку, как подменю любой вложенности, и в природе существуют поля ввода с выпадающими списками, то причём тут борьба с модальностью? Где в подменю и выпадающем списке модальность? Нигде, чистая произвольная навигация по предоставленным данным в рамках интерфейса. Есть ли разница между «ВыбратьИзМеню» и статичным подменю? Никакой. Тогда почему надо заставлять всех делать «ПоказатьВыборИзМеню» и перелопачивать ради этого и код, и логику?
Ладно, нам объяснили, что «ВыбратьЭлемент» это теперь очень плохо. Но тогда почему остались диалоговые методы различных объектов? Почему никто не посягнул на «ДиалогВыбораФайла.Выбрать»? Модальность же неимоверная! А это далеко не единственный пример. Почему не отказались от мини-диалогов, возникающих при нажатии на «педальку» поля ввода - например, от календаря или калькулятора, от выбора типа значения? Они ведь интерфейсно ровно то же, что выбор из списка или меню. Загадка!
Вернёмся к асинхронности исполнения. «Тупой одинэснег» внимательно читает методические статьи и видит, что теперь после вызова «Показать…» исполнение кода продолжается, а отдельная ветка уходит на обработку действий согласно описанию оповещения. Супер, можно разделить поток исполнения! Можно выполнить действие «а», в то время как «немодальное» окно будет пройдено пользователем и согласно ему выполнится действие «б». Асинхрон!
Не тут-то было. Простейшая проверка показывает, что асинхронность, заявленная идеологически, на практике отсутствует. Достаточно поставить бесконечный цикл после вызова «Показать…» и – здравствуй, перезапуск приложения. Асинхронностью я бы это не назвал ни в коем случае. Нижеприведённое также привело к зависанию:
Процедура НекаяКоманда(Команда)
опоп=Новый ОписаниеОповещения("ЗавершениеНекойКоманды",ЭтотОбъект,);
ПоказатьПредупреждение(опоп,"Hell, world!");
Пока НекийКлюч Цикл
ОбработкаПрерыванияПользователя();
КонецЦикла;
КонецПроцедуры
Процедура ЗавершениеНекойКоманды(Параметр1)
НекийКлюч=Ложь;
КонецПроцедуры
Более того, авторы статей аккуратно намекают, что после вызова «немодальных» диалогов вообще лучше бы прекратить исполнение кода и вообще выйти из процедуры/функции, т.е. ставить такой вызов последней строкой кода. На красивых картинках нам показывают, как переключается туда-сюда-обратно ход процесса, как передаётся управление, как надо работать со вложенными процедурами и т.д. Но вдумайтесь – где здесь асинхрон? Перед нами просто более запутанное, но всё такое же последовательное, плоское и однопоточное выполнение кода! Пресловутая «асинхронность» не чисто программная, а программно-интерфейсная силами платформы. Здесь нет ожидания успешности или неуспешности, нет их перехвата. Есть приостановка выполнения нашего кода на период «висения» некоего окна. И где разница с тем, что было до сих пор? Почему мы лишены возможности продолжить там же, в той же процедуре? Почему нам, на худой конец, не дали меток наподобие Goto, и обязательно теперь прыгать в другую процедуру? Напомню, второго потока по сути нет и не подразумевается!
Да и зачем нам в интерфейсах асинхронность вместо main flow? Ладно, тяжёлые серверные действия, уходящие фоновыми заданиями в настоящие асинхроны, но на клиенте (а описание оповещения живёт только на клиенте) таких задач пока нет и особо не предвидится. Подчеркну – именно применительно к взаимодействию с интерфейсом, а не к работе с данными, т.к. платформа отрисовывает и показывает всё за нас. Приведите мне пример, позволяющий убедить главбуха, отчего теперь код пишется втрое дольше!
Дочитавшие до этого места могут возразить, что, мол, интернеты-веяния времени, и вообще новомодные геопозиционирования и прочая. Насчёт интернета и веяний времени я комментировать не буду, т.к. версия встроенного в платформу браузера ниже всякой критики, свойство parentWindow не советовали к применению прям даже в СП, а уж какая мешанина вышла из его свойств/методов и свойств/методов Dociment в итоговом «Документ» я вообще молчу. Прогресс беспредельный, ага.
Что касается настоящей «интернетности». Да, хорошо, что объект «ОписаниеОповещения» уже напоминает известную в JavaScript возможность перекинуть процедуру как параметр и выполнить где-то в другом месте. Да, теперь мы можем вызвать процедуру из некоей формы, находясь в совсем другом месте, имея лишь оповещение, а значит, имея саму эту УФ, нужный контекст и тд. Но вот достучаться до команды так пока не получается – известно, что модуль общей команды это «чёрный ящик», и находящийся там код программно вызвать нельзя.
А главное, что нет настоящих Promise, хорошо известных в JS. Следующим логичным шагом было бы сделать нечто вроде:
ОбъектИлиМенеджер.ПроцедураИлиМетод(Параметры).ЕслиУспешно Тогда
ДействияПриУспешности(Параметры);
ЕслиНеуспешно Тогда
ДействияПриНеуспешности(Параметры);
ЕслиУспешностьНеясна Тогда
ДействияПриНеясности(Параметры);
Конец
об1=Новый Обещание(ОписаниеОповщения1,ОписаниеОповещения2);
Но пока "обещаний" нам не обещают.
Логичной представляется также возможность динамического создания подписок на события любого характера (listeners), ну и наконец, господа из 1С, может быть, сделают перехват и обработку нажатия пользовательского прерывания, хотя бы исключительно на клиенте.
Итак, мы пока что имеем однопоточное, не-асинхронное (просто запутанное) выполнение кода, и якобы немодальные диалоги, чьё поведение ничем не отличается от модальных, а в ряде случаев вообще не модально по определению. Просто прибавилось хлопот.
В заключение отмечу, что 1С сама не очень соблюдает собственные рекомендации. Так, в http://its.1c.ru/docs/v8nonmodal/ сказано, цитирую, «Другой сценарий, который является крайне нежелательным - это немодальный диалог в обработчике ПередЗавершениемРаботыСистемы. Во-первых потому, что в условиях веб-клиента браузеры очень негативно относятся к показу каких-либо сообщений при закрытии приложений и блокируют их. Во-вторых потому, что наличие такого диалога не позволит реализовать некоторые сценарии работы.». Вспомним, как себя ведёт БП 3.0 при закрытии? То-то же.
В ряде мест этой замечательной статьи откровенно признано, что 1С и сами ещё не вполне представляют, какое решение будет эффективным, красивым и вообще «правильным» для многих случаев. И случаи эти частые, общеупотребительные, всем нам нужные. Более всего такие места статьи походят на «ну, мы сделали, а вы уж как-нибудь выкрутитесь». При том, что можно было реализовать то же самое, т.е. обойти проблемы работы в браузерах и мобильных устройствах, на уровне платформы, вообще не затрагивая уровень разработки конфигураций. Безо всякой псевдоасинхронности и ненужного умножения и усложнения кода.
