После выпуска первой публичной (третьей) версии платформы мы получили огромное количество фидбэка, большая часть работы над которым нашла отражение в недавно вышедшей четвертой версии платформы. Впрочем, значительная часть этого фидбэка осталась “за бортом”, но не была забыта, и соответственно сформировала план развития платформы на ближайшее будущее. Именно об этом плане и пойдет речь в этой статье.
Большая часть планируемого функционала в той или иной степени касается пользовательского интерфейса — его эргономики, модульности и гибкости.
Одним из основных признаков современного эргономичного интерфейса является его асинхронность. В текущей версии платформы большинство пользовательских операций уже асинхронны (например, события, ввод примитивных данных). Но, как говорится, лучшее ‒ враг хорошего, и в следующих версиях планируется сделать асинхронным практически весь UI.
В текущей версии платформы существует оператор ввода INPUT, позволяющий запросить значение заданного типа у пользователя. При использовании этого оператора в обработке события изменения платформа, в большинстве случаев, выполняет этот оператор асинхронно: сначала запрашивает значение у пользователя (без обращения к серверу), и только по завершении этого запроса выполняет обработку события изменения на сервере (с предопределенным результатом ввода). Такой подход позволяет значительно улучшить эргономику ввода данных пользователем, но его проблема в том, что его можно использовать только для ввода примитивных данных. Для ввода объектных данных используется оператор DIALOG, для которого никакой асинхронный режим в текущей версии платформы не предусмотрен. Соответственно в будущих версиях планируется поддержать следующий функционал:
Опция ASYNC также будет автоматически использоваться при создании обработок события изменений по умолчанию (таким образом в следующих версиях асинхронный ввод большинства свойств “включится” автоматически).
Асинхронный ввод объектных данных по сравнению с обычным вводом дает следующие преимущества:
С другой стороны полноценный диалог предоставляет множество различных «стандартных» возможностей (пользовательские фильтры, упорядочивания, дополнительные объекты на форме и т.д.), поэтому даже при асинхронном вводе все равно будет возможность переключиться обратно на обычный (“синхронный”) ввод данных.
Технически асинхронный ввод значений на форме реализован следующим образом:
Преимущества такого подхода описаны в предыдущем разделе, но естественно, использовать этот подход можно не только для ввода значений, но и, например, для открытия форм. Так платформа может:
Такая “превентивность” позволяет значительно повысить отзывчивость пользовательского интерфейса и тем самым улучшить общий UX при работе с системой.
Текущая реализация платформы построена таким образом, чтобы минимизировать количество обращений между клиентом и сервером, а также между серверами БД, веб и приложений. Такой подход позволяет обеспечить максимальную производительность (а точнее, минимизировать общий оверхед), но при этом ухудшает UX, если, например, вычисление одного из свойств занимает слишком много времени.
В следующих версиях такое поведение планируется изменить и реализовать оптимизацию, аналогичную адаптивному выполнению запросов. Суть этой оптимизации состоит в том, что при вычислении свойств / списков объектов выставляется некоторый таймаут, при превышении которого запрос, выполняющий вычисление, отменяется, а его выполнение переносится на следующий цикл обновления формы (если таковой отсутствует, он создается автоматически). В текущем же цикле обновления считается, что никаких изменений не было, но при этом такие отложенные изменения на клиенте каким-нибудь образом подсвечиваются (например, становятся более прозрачными).
Отметим, что разбиение обновления формы на несколько циклов уже используется в представлении “сводная таблица”. Так, например, при переключении в представление «сводная таблица» из других представлений, сначала приходят изменения списка колонок (без данных, что позволяет сразу отрисовать пользовательский интерфейс), и только в следующем цикле обновления формы приходят реальные данные этой сводной таблицы. Впрочем, это «двухфазное обновление» сводной таблицы работает безусловно (без каких-либо таймаутов), поэтому все же прямого отношения к описанной выше оптимизации не имеет
Агрегация является одной из самых важных концепций в программировании, позволяющей эффективно обеспечить абстрагирование, декомпозицию, повторное использование кода и многие другие важные свойства ИС.
Так как полиморфизм в формах пока не поддерживается (и в принципе не понятно, в каком виде полиморфизм в формах вообще может поддерживаться), наследование можно считать частным случаем агрегации, поэтому рассматривать его как отдельный механизм особого смысла не имеет.
Предполагается, что при агрегации одной формы в другую, агрегируемой форме можно будет задать некоторое пространство имен, которое будет автоматически добавляться к идентификаторам всех элементов агрегируемой формы и которое можно будет использовать для обращения к этим элементам для разрешения неоднозначности выбора (то есть по сути все аналогично работе с обычными пространствами имен).
Также при агрегации форм все создаваемые по умолчанию элементы формы (например контейнеры — OBJECTS, BOX, свойства — formOK, formClose, и т.д.), считаются “общими” и создаются только для результирующей формы. Соответственно, в агрегируемых формах обращения к таким «общим» элементам считаются обращениями к соответствующим элементам результирующей формы.
Агрегация форм может использоваться как для создания сложных форм (состоящих из многих блоков), так и для расширения существующих форм без их изменения. Например:
В текущей версии платформы большинство элементов системы, в том числе формы, расширять можно. Впрочем, на самой форме можно только добавлять новые элементы, изменять атрибуты уже существующих элементов нельзя (за исключением элементов дизайна, но этого часто бывает недостаточно). Соответственно, в следующих версиях этот пробел планируется устранить и поддержать ключевое слово EXTEND (используемое в остальных синтаксических инструкциях расширений) внутри самой инструкции FORM. Например:
Особенно этот функционал может быть удобен при использовании вместе с механизмом агрегации форм, описанным в предыдущем разделе.
Каким эффективным не был бы отдел разработки ИС, все равно часто возникает ситуация, когда непосредственно пользователь (или администратор) может выполнить настройку форму быстрее и эффективнее, чем если в этом процессе будет участвовать разработчик или кто-то еще.
В текущей версии платформы существуют базовые механизмы настройки списков (изменение порядка колонок, скрытие колонок, упорядочивание по значениям колонок и т.п.), однако этих возможностей, особенно в задачах аналитики, часто бывает недостаточно. Соответственно в следующих версиях возможности пользовательской настройки будут значительно расширены.
Одной из самых частых потребностей пользователя по настройке формы является добавление тех или иных дополнительных показателей (колонок / полей) на форму. Также часто бывает необходимо подсветить те или иные ряды / поля в зависимости от некоторого условия.
Все эти настройки требуют задания в том или ином виде свойств, которые будут определять значения отображаемых колонок, условия / цвета, подсветки и т.п. Наиболее логичным и простым в реализации способом задания свойства является указание некоторого выражения (в виде строки), результатом вычисления которого и будет необходимое свойство.
Такой способ используется в Excel, и, также как в Excel, в новой версии платформы в том числе планируется минимальный конструктор таких выражений.
Пример выражения:
Предполагается, что в интерфейсах, где необходимо задавать выражения, будут отображаться также и имена объектов (чтобы было понятно к чему можно обращаться).
И сам конструктор, и интерфейсы добавления / изменения атрибутов свойств скорее всего будут реализованы при помощи встроенных механизмов lsFusion (то есть на языке lsFusion с использованием таких элементов платформы, как свойства и формы).
Сейчас в платформе существует механизм пользовательской фильтрации, но у этого механизма есть ряд недостатков:
Соответственно, все эти проблемы планируется устранить в новой версии, добавив новую опцию USER в конструкцию FILTER, базовый компонент USERFILTERS для каждого списка и т.д.
За исключением весьма редких случаев (например, оперативной “творческой” аналитики) сделанные пользователем настройки необходимо сохранять и восстанавливать при последующих использованиях настроенной формы этим или другими пользователями.
В текущей версии можно сохранять только настройку списков и только один вариант настроек (текущий). В новых версиях планируется добавить возможность сохранять несколько вариантов настроек формы, причем именно всех настроек (в том числе, например, настроек сводной таблицы). Также появится возможность задавать предопределенные варианты настроек при помощи механизма агрегации форм. Так вариантом настройки формы может быть форма, в которую эта настраиваемая форма агрегирована. Например:
В разделе выше речь шла о сохранении глобальных настроек формы. В то же время в процессе работы с формой / ее настройки при каждом пользовательском действии неявно создается некое временное состояние (вариант формы), которое также можно использовать для улучшения эргономики системы. В частности:
Исторически в lsFusion существует большое количество различных типов контейнеров, многие из которых пришли из Java Swing и на самом деле являются избыточными и / или недостаточно гибкими / частными случаями. Плюс эти типы контейнеров плохо отображаются на типы контейнеров HTML (веб-клиента, который в последних версиях lsFusion считается основным видом клиента), что делает их более сложными для понимания, а также в некоторых случаях ухудшает производительность веб-клиента.
В следующих версиях планируется, что будут поддерживаться следующие типы контейнеров:
Соответственно типы контейнеров SPLIT и SCROLL превратятся в опции (true/ false) и скорее всего будут включены по умолчанию (у SPLIT отображение разделителя станет опциональным и будет выключено по умолчанию).
Также в новых версиях появится опция alignCaptions, которая выравнивает заголовки компонент по одной границе и тем самым позволит в результате получать более классический дизайн.
Также планируется реализовать несколько мелких изменений:
В четвертой версии было добавлено большое количество различных представлений списков. В то же время для отображения самих свойств в четвертой версии всегда используют ровно одно представление (которое зависит от типа, и чаще всего является отображением значения свойства в виде обычной строки, пусть и с возможностью настройки фонтов, выравниваний и т.п.).
В следующих версиях планируется добавить альтернативные представления свойств (благо существующих open-source javascript библиотек для этого предостаточно), ну и, также как и для кастомизируемых представлений списков, дать разработчику возможность самому подключать любые javascript функции для отображения значений свойств.
Также, в следующих версиях планируется добавить возможность подменять отображение сразу целой группы свойств, что может быть весьма удобно, когда необходимо эргономично отображать и вводить сразу несколько свойство одновременно (например интервал дат, который по сути состоит сразу из двух свойств). Ну и естественно в платформу скорее всего будут добавлены несколько представлений групп свойств «из коробки» (например тех же интервалов дат).
Соответственно, кастомизация представлений свойств, вместе с кастомизацией представлений списков, позволит разработчику создавать практически любой дизайн интерактивных форм. Функция платформы при этом будет сводится к :
Все описанное в этой статье — это всего лишь предварительный план развития. Что-то, естественно, будет изменяться, что-то добавляться, но в целом, направление развития платформы будет именно такое. Решаться задачи будут, скорее всего, в порядке простоты их реализации, выпуск же версий планируется сделать более частым и цикличным, то есть не факт, что весь описанный функционал попадет именно в пятую и шестую версии. Возможно, версий, покрывающих этот функционал, будет существенно больше. Но в целом, реализовать все описанное в этой статье планируется максимум в течение года.
VK объявляет о приобретении 40% компании Intickets.ru (Интикетс). Это облачный сервис для контроля и управления продажей билетов на мероприятия. Сумма…
OpenAI готовится запустить собственную поисковую систему на базе ChatGPT. Информацию об этом публикуют западные издания. Ожидается, что новый поисковик может…
Центр управления связью общего пользования (ЦМУ ССОП) Роскомнадзора рекомендовал компаниям из реестра провайдеров ограничить доступ поисковых ботов к информации на российских сайтах.…
Apple возобновила переговоры с OpenAI о возможности внедрения ИИ-технологий в iOS 18, на основе данной операционной системы будут работать новые…
Конкурсный управляющий российской «дочки» Google подготовил 23 иска к участникам рекламного рынка. Общая сумма исков составляет 16 млрд рублей –…
Google завершил обновление основного алгоритма March 2024 Core Update. Раскатка обновлений была завершена 19 апреля, но сообщил об этом поисковик…