К управляемым формам, которые появились в 82, я до сих пор относился презрительно. Считал это неудачной попыткой 1С следовать модным тенденциям в разработке интерфейсов и прогибом для возможности работать через браузер.
Я считал, что 1С пожертвовала простотой разработки в угоду веб-доступу.
Но после курсов Арутюнова Сергея по управляемому интерфейсу в июле 2015 года в УЦ1 я поменял ненависть на любовь. Звучит парадоксально, но это так. А теперь подробнее…
После того, как я три дня пощупал на практике управляемые формы, я их полюбил. Не нужно расставлять мышкой поля на форме, мучиться с привязками. Все просто и делается в несколько кликов.
Мне даже стало жалко, что 1С полностью не отказалась от обычных форм из-за
того, что они используются в режиме рабочего стола. Ведь можно было бы дать
возможность в УФ точного пиксельного позиционирования и обычные формы бы
отмерли со временем. А так приходится распылять силы еще и на знание старого
функционала.
А так, конечно, УФ намного быстрее обычных, т.к. работают по трехзвенной схеме между клиентом и сервером.
Кроме того, сам функционал УФ намного богаче и шире, чем у обычных – неудивительно, прошло много времени и в них попали многие интерфейсные находки.
Например, вывод динамической таблицы с группировками, или вытаскивание реквизитов объектов напрямую в динамический список. Или даже радиокнопка не в виде точек, а в виде тумблеров.
На практике их не так страшно использовать, как казалось изначально, я освоился быстро. В свое время я достаточно программировал общих модулей, которые работали только на сервере и сталкивался с преобразованиями мутабельных значений для передачи их на сервер, поэтому управляемые формы были доступны моему пониманию.
Я слышал, что в 83 появился отказ от модальных функций вроде Вопрос, Предупреждение, ОткрытьФормуМодально. Для меня было непонятно, зачем это было сделано.
Каково же было мое удивление, когда в одном из примеров преподаватель вызвал открытие формы с параметром «Заблокировать весь интерфейс», т.е. по сути модально.
Я то был уверен, что от модальности отказались.
Понимание пришло не сразу.
В 1С не отказались от модальных окон. Есть новые функции, чтобы вывести предупреждение, задать вопрос, открыть модально диалог выбора файла.
Нюанс в том, что после вызова этих модальных окон управление не замораживается, как раньше, в ожидании, когда форма закроется, а продолжается. Форма вызывает оповещение, что она закрылась и нужно обработать это оповещение.
Т.е. платформа 1С избавилась от рудимента замораживания выполнения кода и перешла на полностью событийное управление формами.
Конечно же, это никоим образом не связано с тем, что браузеры испытывают сложности с показом модальных окон. Это заблуждение и предрассудок – забудьте его как дурной сон. Все логично. По сути теперь выполнение полностью событийное и асинхронное, от синхронного выполнения удалось избавиться.
В 1С появились мини-конструкторы – рефакторинг. Это упрощает написание обработчиков оповещения для асинхронного режима работы, чтобы не писать их вручную.
В конфигурации есть возможность отключить все синхронные вызовы (они будут вызывать ошибку), в итоге она будет полностью асинхронна и соответствовать последним требованиям организации событийной модели.
Если управляемые формы выглядят вполне логичным и правильным направлением развития, то направление развития системы меню для меня так и осталось непонятым.
Несомненно, меню, где показывается только один уровень, затем нужно заходить в
следующий подуровень и так до выбора нужного пункта уже морально устарело и ему
на смену пришла карта меню, где развернуты сразу несколько пунктов меню. Это
было сделано в типовых еще до выхода новых интерфейсов меню в 82.
В свое время еще на 81 я делал систему меню в виде прикрепленного слева иерархического справочника, где видимость каждого пункта определялась правами доступа пользователя, для которого отображалось меню.
Я так понял, что 1С посчитало неправильным, что прикладной объект Интерфейс не используют и решила выпустить ему новую, продвинутую альтернативу.
Получилось как-то мудрено, на мой взгляд. Опять же все завязано на настраиваемые галочками роли, которые я никогда не любил – лучшая система ролей пишется на уровне программного кода, доказательством этого является система дополнительных прав пользователей, которая позволяет гибко и без лишних проблем настроить права доступа в типовых конфигурациях.
В общем, новые способы организации меню пришли, на мой взгляд они не очень удачные, но альтернативы нет и их применяют в типовых.
Я спросил преподавателя: «Мне понятно насчет управляемых форм, но зачем нужно было развивать интерфейсы, почему было нельзя немного доработать классическое меню»?
Он мне ответил, что система 1С развивается в направлении увеличения комфорта и скорости работы пользователя. На мой взгляд все же, такие грандиозные изменения в системе меню этого не стоят.
Кстати, для производительной работы пользователей важен порядок обхода – многие на автомате уже заучили определенный порядок обхода полей. Так вот, как раз от порядка обхода в 82 отказались. Он строго соответствует порядку размещения элементов. К счастью, есть возможность программного перехвата выхода из поля и передачи фокуса другому полю, иначе было бы совсем плохо с заявленной производительностью.
Рабочая область – всего одна. Поэтому приходится запихивать в неё формы практически всех пользователей и определять их видимость правами. Все это должно приводить в больших конфигурациях к хаосу.
Намного проще было бы создавать её программным кодом или использовать механизм вложенных форм.
Я так и не дождался вложенных форм. Увы, их нет, хотя они использовались еще в древнем Access.
Перетаскивания через буфер обмена нет. Т.е. приходится тащить мышкой, нельзя указать – я тащу отсюда и помещаю здесь, не разрывая жесть мышью, увы. Хотя, возможно, здесь на помощь может прийти сторонний софт, т.к. перетаскивание – это системная вещь в Windows.
В своё время RLS были созданы для того, чтобы показывать пользователям только отдельные записи таблиц.
Дальнейшим развитием видимости стали функциональные опции и настройки отображения полей по ролям. Все вместе это составляет некий разнообразный зоопарк, нет общей стройности и слаженности.
На мой скромный взгляд, видимостью полей все же проще управлять программным путем, чем декларативно, расставляя галочки и делая сложный механизм функциональных опций.
В свое время я доказал, что RLS на изменение уступает программному контролю записи на уровне модуля объекта/подписки. Точно также подозреваю, что любая функциональная опция уступает обычному алгоритмическому описанию контроля видимости элементов – как в простоте использования, так и в универсальности подхода.
Пользователь конфигуратора вынужден очень много думать, как контролировать видимость – ролями или через функциональные опции. Один раз написав универсальный алгоритм определения видимости полей, он мог бы применять его всегда без всяких этих платформенных костылей.
Приговор – функциональные опции и видимость через роли – малоэффективны, но их надо знать, т.к. они используются в типовых конфигурациях.
Интерфейс 82 и интерфейс такси совместимы, т.е. новых объектов не появилось. Конфигурация может работать или в 82 или в Такси, можно позволить пользователю переключаться между этими интерфейсами.
Главное отличие – расположение объектов главного меню. В 82 они занимали много места слева и сверху, в итоге под рабочую область для пользователя оставлялось мало места в правом нижнем углу. В интерфейсе Такси меню автоматически скрывается, оставаясь в виде небольшого меню слева, в итоге под рабочую область отводится практически весь экран.
Непонятно, зачем было идти таким запутанным путем, если в итоге базовая система меню в 81 еще более экономно расходовала рабочее пространство экрана?
Также в Такси изменились принципы отображения окон, в итоге код форм для 82 в некоторых местах не удобен. Но в этом направлении разницы я еще не осознал, хотя преподаватель и пытался рассказать основные принципы Такси. Попробую разобраться на практике, хотя и считаю все эти усовершенствования интерфейса избыточными и ненужными на практике пользователям бизнес-приложений.
Кстати, в 82 нельзя поменять палитру, это как бы визитная карточка платформы 1С. Точно также и система организации меню в виде 82 или Такси приучает пользователей к некоторому стандарту. Однако практика показывает, что на новую систему меню пользователь переучивается практически мгновенно. Вот поменять навыки работы с документами и отчетами намного сложнее.
Поэтому весь этот шум и споры вокруг системы меню мне не очень понятны – это не основной момент в платформе 1С, оставим его на совести архитекторов платформы и указывающих им направление развития руководителей.
Преподаватель правильно заметил, хотя это понятно и так, что разработчики платформы не создали новых сущностей там, где это нужно.
Например, подсистемы используются и для разделения объектов конфигурации на блоки и для организации функциональных меню (новая альтернатива привычному меню приложения). Хотя логично было бы создать отдельный прикладной объект, который назывался бы «Функциональное меню».
Также приходится организовывать пустые роли (интерфейсные роли), которые нужны только для того, чтобы указать, какие объекты будут отображаться в той или иной форме. Хотя логичным было бы развить в этом направлении прикладной объект «Интерфейс».
Некоторые подходы 1С к usability вызывают сомнения.
Например, много внимания на курсах было уделено, чтобы печатная форма документа показывалась в отдельной подчиненной форме документа и когда документ менялся, чтобы она очищалась. Смысла в этом не очень много, иногда нужно напечатать несколько экземпляров – например до правки и после. Запутаться в паре документов и нескольких печатных формах невозможно с практикой, поэтому распыление энергии в этом направлении мне показалось сомнительным.
Также, например, в платформе невозможно сделать поле ввода в ячейке динамического списка, если источником является не базовая таблица. Не потому что это технически сложно, а из соображений usability.
Настройки формы сохраняются напрямую в базу, а не в сеансе. При аварийном завершении они не теряются. Соответственно, появился новый механизм работы с этими настройками, где можно сохранять и свои данные. Альтернатива СохранитьЗначение/ВосстановитьЗначение.
Теперь все сохраненные настройки при необходимости можно программно перебрать, а значит, выгрузить другому пользователю, в файл и т.п.
В управляемых формах код выполняется на клиенте и на сервере.
Под клиентом подразумевается слабая машина, им может быть даже обычный браузер.
А сервер находится в непосредственном и быстром соединении с базой данных.
Клиент не может работать с базой данных, он может выполнять мелкие математические операции и управлять элементами своих форм. Если требуется получить что-то из базы данных или отправить туда данные – клиент обращается к серверу.
Именно так работают управляемые формы. При должной сноровке постоянное обращение к серверу не является сложностью.
Подобная организация эффективнее, чем подключение к серверу через удаленный доступ, кроме того, работа возможна непосредственно через браузер, т.е. на любой платформе – Windows, Linux, Android, Mac OS.
Здесь приведу заметки, которые писал для себя, они содержат ценные знания:
Преподаватель утверждал:
Выражаю благодарность преподавателю.
Посещение этого курса избавило меня от предубеждения относительно управляемых форм, я четко уяснил для себя нюансы модальности, различия между интерфейсами 82 и Такси.
Теперь управляемые формы не пугают меня, а, наоборот, влекут познать их.
Надеюсь и вы, читающие эту статью, по достоинству оцените управляемые формы.