Разработка веб-модулей стала еще проще
Корректная предсказуемая работа событий и вычислений
Детальные разделы
События детальных разделов при добавлении и удалении строк теперь срабатывают в нужный момент – когда пользователь добавил или удалил строку, а не 2 раза (при добавлении и сохранении), как было раньше. При выполнении событий на ISBL изменения значений реквизитов строки, карточки или других детальных разделов сразу отображаются пользователю в браузере.
Корректный порядок событий ТМ
Некоторые события срабатывали чаще, чем должны, некоторые – не тогда, когда надо. Например, если создать ТМ с запросом параметров и сравнить, как он ведет себя в deskop-клиенте и веб-доступе, то можно обнаружить следующее:
- Событие «Начало выбора» срабатывает дважды при создании задачи.
- Событие «До запроса параметров» в веб-доступе срабатывает при открытии задания, отправленного по ТМ, и потом оно еще раз сработает после нажатия на кнопку Выполнить.
Со стороны прикладной части многократное срабатывание событий приходилось как-то обходить. Теперь события срабатывают только 1 раз и в нужный момент:
- Событие «Начало выбора» срабатывает только при выборе ТМ. После нажатия на кнопку ОК в диалоге запрашиваемых параметров срабатывает только «Завершение выбора».
- Событие «До запроса параметров» в веб-доступе срабатывает только при выборе варианта выполнения или нажатии на кнопку Выполнить. После нажатия на кнопку ОК в диалоге запрашиваемых параметров срабатывает только «После запроса параметров».
Помимо этого, были исправлены другие замечания по работе с ТМ.
Вычисления на реквизитах
Вычисления на реквизитах теперь выполняются сразу, как только пользователь отредактирует значение реквизита (уберет фокус с поля), а не при сохранении, как раньше. Если в вычислениях была ошибка или изменились какие-то реквизиты, то они сразу же отобразятся пользователю.
Вычисления поддерживаются в:
- Карточках записей справочника
- Карточках документа
- Прикладных диалогах
В детальных разделах могут поменяться не только значения реквизитов, а добавиться и удалиться какие-то строки – это тоже поддерживается.
При необходимости вычисления можно выключать с помощью клиентской ОМ, используя соответствующие методы конкретных реквизитов для снижения нагрузки на веб-сервер и SQL-сервер. Как правило, это вычисления для валидации значения и для сохранения логики работы. Отключенные вычисления нужно будет написать заново в JavaScript-файле веб-модуля.
Выполнение событий при открытии карточки на чтение
Чтобы карточка открывалась на чтение быстро, вычисления были отключены, но не для всех карточек это подходит. У некоторых из них есть вычисляемые реквизиты, значения которых определяются динамически в событии «Набор данных.Открытие», поэтому мы добавили возможность настроить веб-модуль так, чтобы это событие сработало даже в режиме чтения. Вам не нужно думать, включать его или нет: если оно есть – оно сработает.
При необходимости такое поведение можно изменить в настройках веб-модуля, указав events=edit, если события нужно выполнять только в режиме редактирования. Если же вообще события не должны выполняться, то нужно указать events=false.
Развитие клиентской объектной модели
КОМ в мастерах действий
В мастерах действий работать с полями и кнопками стало также удобно, как с реквизитами карточки записи справочника.
WA.current.form.requisites["Имя параметра"].getValue() // получить значения параметра
WA.current.form.controls.buttons.Next.disable() // сделать неактивной кнопку «Далее»
Также стало возможным получить информацию как о самом мастере, так и о текущем этапе. Например,
WA.current.Code // код мастера
WA.current.CurrentStepTitle // название текущего этапа
О дополнительных возможностях читайте в справке.
Работа с прикладными диалогами
Диалог можно указать для запроса параметров отчета, фильтрации справочника, сценария или действия.
Для показа диалога код прикладной части на ISBL будет выглядеть так:
Dialog = Dialogs.DialogName.CreateNew
ShowDialog(Dialog)
... // дальнейшая работа с диалогом
Как видите, достаточно будет вызвать только функцию ShowDialog(IDialog), причем неважно, где она будет вызвана: в веб-доступе или desktop-клиенте. Для веб-доступа она заполнит реквизиты диалога значениями из параметров, а для desktop-клиента – покажет диалог пользователю.
Для показа диалога в отчетах нужно указать в веб-модуле имя диалога, и тогда в быстром запуске он будет запрашиваться автоматически. Пример:
Настройка названия диалога в xml позволит показывать его, даже если отчет запускается по ссылке из Word или другого места (например, кнопке на ленте).
Помимо этого, запустить отчет, предварительно показав диалог, можно через клиентскую объектную модель:
WebAccess.factories.reports("ReportName").showDialogAndExecute('DialogName').done(function(report) {
report.open();
});
Для фильтрации справочников в веб-модуле теперь можно указать javascript-функцию, которая сработает перед открытием справочника. В ней и можно будет показать диалог, после чего открыть справочник.
// Где-то в JS веб-модуля
function doWhatIWant(data) {
WA.FC.dialogs.getDialogByName('DialogName').done(function (dialog) {
dialog.show();
dialog.bind(dialog['class'].EVENT.AFTER_ACTION, function () {
data.filter = '[Состояние]="' + dialog.form.requisites["State"].getValue() +'"';
data.continueDefaultAction();
});
});
return false;
}
Для действий нужно вызвать специальную функцию у текущего объекта.
WebAccess.current.showDialogAndExecuteAction('ActionName','DialogName')
Для сценариев все аналогично действиям.
WebAcces.factories.scripts("ScriptName").showDialogAndExecute('DialogName').done(function(data) {
console.log(data);
});
Таблица записей справочника как компонента (грид)
В связи с обновлением представления списка записей справочника и детального раздела, в клиентскую объектную модель добавлены классы для построения таблиц (гридов) в любом другом месте, а плагинный механизм наделит ваши гриды нужным функционалом. Подробнее о списке плагинов и их функционале смотрите в справке.
Прочие упрощения разработки
Возможность добавить кнопку ленты для блока ТМ
Раньше можно было добавить кнопку на ленту только сразу для карточек всех заданий. Теперь в веб-модуле можно добавить кнопку на ленту карточки задания для конкретного блока типового маршрута.
Также можно добавить кнопку для всех заданий конкретного типового маршрута.
Делается это так:
Поддержка SourceMap
SourceMap нужен для отладки минифицированного JS-кода. Минификация – процесс объединения и модификации JS-файлов для уменьшения трафика и количества запросов к серверу.
В веб-доступе минификация выполняется при старте приложения при включенной настройке в web.config – debug=false (релизная версия). При изменении js/css-файлов в релизной версии сайта потребуется перезапуск для применения изменений.
Заключение:
В связи с такими улучшениями, теперь все объекты desktop-клиента доступны в веб-доступе по умолчанию, в том числе создание документов с любым видом и типом карточки. Таким образом, разработчик прописывает компоненты в xml-файле настройки веб-модуля, только если нужно ограничить к ним доступ или дополнительно настроить. К тому же, по умолчанию все эти объекты будут выполнять события.
Работы в этом направлении продолжатся в следующих версиях. Что бы вы хотели еще упростить?
Вы, наверное, единственная компания на рынке ПО России которая уже какой год, банально, не в состоянии сделать полноценный тонкий клиент тождественный по функционалу ее основному приложению. Просто удивляет ваше стремление любым способом сказать "как у нас все хорошо", "а сколько мы все такого симпатичного сделали", при этом не меняя сути системы.
Цитатка: "Как видите, достаточно будет вызвать только функцию ShowDialog(IDialog), причем неважно, где она будет вызвана: в веб-доступе или desktop-клиенте. Для веб-доступа она заполнит реквизиты диалога значениями из параметров, а для desktop-клиента – покажет диалог пользователю." Что это, Карл!? Диалог, он очевидно... для ДИАЛОГА человека с ПК... Вы в принципе не в состоянии решить вопрос с работой интерактива в вебе или вам просто не попадаются квалифицированные люди?
Даже интересно, на сколько лет это затянется. А может вы боитесь, что ваша презентация будет из одного предложения... вроде как - оно работает, сами выбирайте, чем пользоваться. Так не бойтесь, краткость - сестра таланта.
Диалог отобразится в веб-доступе для пользователя, пользователь заполнит в нем всё что хочет, а потом то, что он заполнит передастся в отчет/сценарий/действие и это обработает ShowDialog(IDialog). Ошибки "Показ форм в неинтерактивном режиме невозможен" не будет. Для прикладного разработчика код будет выглядеть так, как будто он его только что показал пользователю.
Хорошо... давайте так. Есть событие "После запроса параметров" в блоке типа задание. Как я смогу отобразить диалог в WEB в вычислениях данного блока? Причем диалог должен быть отображен по результатам вычисления при соблюдении неких условий, иначе его не следует отображать.
Пока что наш подрядчик смог это сделать только при помощи копания в XMLках и JSках, что сделает сам переход на WEB полноценным перевнедрением за неприемлемую сумму, да и последующая модификация станет просто Адом для разработчика, так как там указываются коды маршрут и ИД конкретного блока на котором надо вызвать диалог.
В дополнение к устному разговору... несколько выводов:
1. Порок вашего "веб" чего-то там (это не есть полноценное приложение) в невозможности нормально обрабатывать события на стороне клиента не исправлен. Наверное, вопрос только в найме квалифицированного программиста и выделения средств. Вам, один раз, а не вашим клиентам и постоянно.
2. Наверное не стоит писать о поддержке веб, да еще и употреблять слова "полная" на ваших мероприятиях не имея такого по факту. "Зацепить" это слово сможет, но не более, а далее первичный анализ, разочарование и отказ от продукта. Да еще и осадочек - в очередной раз обманули.
Дмитрий, по поводу "не полноценности" веба, вы правы, НО, есть для этого объективные причины. Web доступ не будет работать так же, как клиент. Он не может работать так же без диких костылей, которые всё равно будут неудобны либо пользователям, либо разработчикам. И, что важно, никакой "квалифицированный программист" это волшебным образом не исправит...
Можно приближать функциональность Web'a к descktop клиенту и постепенно это делается. С другой стороны, это приближение чревато усложнением разработки, что осложняет понимание работы Web'a и может даже ещё больше усложнить разработку для Web'a, что приведет к ещё большему её удорожанию...
Согласен с Михаилом. От себя добавлю, что пока в качестве платформы используется IS-Builder, ни о каком полноценном вебе не может быть и речи и всегда придется этот веб допиливать, увешивая костылями, причем с каждой новой версией делать это все сложнее...
Михаил, Дмитрий, как вы наверное понимаете у каждого продукта есть стоимость... и не последнюю роль в ней играет так называемая "стоимость владения". А вот теперь, давайте представим себе, как поменяется эта стоимость при полноценном вэбе?
Она радикально снизится... Например, нам не будут нужны такие каналы связи - вэб приложения куда демократичнее тут своих десктопных собратьев. Часть пользователей вообще смогут работать дома без каких-либо дополнительных финансовых затрат. Вопрос удаленного доступа при коммандировках, так же ушел в историю. Обновление... обновил сервер и все с утра заработали по-новому.
Я уже не говорю про любимые "рюшечки" от директума. Уж насколько разнообразнее инструментарий оформления современных вэб решений... И этот сайт можно будет сделать дорабатываемым... причем самим заказчиком.
А что мы уже долгие годы получаем вместо этого? Да банальный обман. На всяких мероприятиях они рисуют картину "победившего социализма" а по сути просто обвешивают "рюшечками" все то же нежизнеспособное ПО. "У нас полная поддержка ТОГО, мы полностью поддерживаем СЁ", получаешь в руки - "вот те бубен и прыгай". Ну просто уже надоело, вроде как большая компания, а не может решить вопрос с фундаментальными модификациями системы.
Не смогли на версии 5, так анонсируй версию 6 и .NET тебе в помощь! Вообще выпустили бы 2 версии - одна текущая а вторая чисто вэбовская, вот интересно кто-нибудь потом купит первый вариант?
Дмитрий, по поводу "Как бы было хорошо", в чем то вы правы, но лишь отчасти. Web хорош. Многие платформы к нему приходят, всё это мы прекрасно понимаем. И те плюсы ,что дает Web, тоже понимаем. Но он не настолько хорош для системы эл. документооборота. У веба свои ограничения. Без дополнительных костылей, он не может работать с файловой системой, не может работать со многими устройствами, не может работать со многими другими приложениями так, как это делает desktop. Дополнительные костыли, в нашем случае это агент веб доступа, тоже не панацея...
Тем более, неподъемная задача сделать приложение, которое одинаково бы работало и через Web и через desktop на всех распространенных платформах, при условии, что у нас есть багаж старого кода, совместимость с которым следует сохранять. Иначе, вы получите цену "перевнедрения" не у одного заказчика, а у всех сразу...
Если же отказаться от сопровождения старого кода, то да, можно что-то придумать, но это будет уже совсем другое приложение. И стоимость его разработки - это стоимость разработки такого приложения с 0. То есть, картинка будет выглядеть так: внедрить старый Directum за 100 условных тугриков, или новый за 1000? Утрированно, но уходить от старого на что-то принципиально новое всегда очень сложно...
Ну а про то, что нам поют маркетологи? Ну работа у них такая. Маркетологи они, вот и всё...
Спасибо за ваши комментарии и интерес к веб-клиенту. Добавлю пару слов от себя, где-то возможно повторю уже сказанное...
По поводу полноценности веб-клиента. Думаю, не совсем правильно употреблять этот термин, т.к. в этом случае за основу мы берем десктоп-клиента и ожидаем, что веб-клиент будет один в один похож на него, в противном случае он обречен быть неполноценным всегда. Должны ли они быть похожи один в один как интерфейсно, так и функционально? Я считаю, что нет. Основная причина - это разные парадигмы приложений, разное окружение в которых они функционируют, а отсюда и множество ограничений, разный пользовательский опыт в конце концов. И если мы все это будем игнорировать, то в результате сделаем универсального монстра в котором будет не удобно работать ни в веб-клиенте, ни в десктоп-клиенте. Должна ли быть преемственность и похожесть? Наверно да. Именно поэтому мы во многом все еще догоняем функциональные возможности десктоп-клиента, при этом оставляя интерфейс "вебовским", чтобы не разрушать пользовательские привычки.
По поводу 100% совместимости кода десктоп и веба - это на мой взгляд тоже утопия. Основная причина тут, как и писал Михаил, ограниченные (от слова никакие) возможности взаимодействия с клиентской ОС. Т.е. мы не можем легально обратиться к файлам, реестру, сканерам, не говоря уж о запуске программы и т.д. И уже поэтому 100% совместимости не будет. Часть кейсов мы закрываем агентом, часть в планах на реализацию, а часть так и останется не закрытой. В любом случае разработчик должен понимать возможности и ограничения как среды в которой будет исполняться код, так и возможности\ограничения инструмента на котором он пишет. Другой вариант - жестко резать возможности инструмента до пересечения возможностей всех сред в которых будет работать код, чтобы разработчику не заморачиваться. К сожалению, чудес не бывает. Возьмите к примеру тот же кроссплатформенный xamarin, который на поверку оказывается также не может реализовать все задумки разработчика одинаково эффективно в разных ОС и тоже приходится выкручиваться.
По сложности\трудоемкости разработки. Тут два момента:
- новое внедрение, которое сразу на веб и только на веб. В 5.2 для большинства кейсов должно быть минимум дополнительной веб-разработки. Из того, что сейчас все еще придется писать - это открытие справочников с фильтром, управление видимостью элементов формы, добавить кнопки в XML. При этом зная, что работает в веб-клиенте, а что нет мы можем сразу написать "правильно" без использования inputdialog (и ему подобных) и без кода в неподдерживаемых событиях. Использование только одного клиента веб или десктоп упростит\удешевит как стоимость разработки, так и тестирование. Поэтому лучше на старте проекта выбрать какой клиент больше подходит и под него и затачиваться.
- переход с десктопа на веб. На текущий момент - без переделок кода тут точно не обойтись и надо проводить аудит кода. Будет ли это сравнимо с перевнедрением - сложно сказать, нужно смотреть на конкретные вещи.
Еще немного о разработке ISBL под веб. За долгие годы мы привыкли писать код так, что из одного куска кода (сценарий, событие и т.д) мы можем сделать все что угодно: обратиться к БД, отобразить пользователю диалог, тут же что-то поменять на форме, что-то обработать, еще раз что-нибудь спросить у пользователя и наконец завершить вычисление. Когда клиент и бизнес логика находятся фактически в одном приложении - это нормально. Если же говорить вообще, то клиента отделяют от логики, писать становится отчасти сложнее, но в итоге понятнее и проще в поддержке\развитии. Аналогично можно сделать и в ISBL, запрашивая у пользователя все необходимые параметры перед вызовом действия с помощью прикладного диалога или formbuilder, а затем уже вызывать сценарий\действие, фактически как функцию с параметрами. И это еще можно упростить...
По поводу автоматического выполнения всего кода, в первую очередь работы с формой и inputdaialog, мы изначально так и хотели сделать как писал Дмитрий, остановка потока, отображение диалога\формы на веб-клиенте, заполнение параметров, возврат к потоку и продолжение работы. Даже был прототип рабочий, но довести это до релизного качества с нормальной стабильностью и быстродействием, по нашим оценкам оказалась очень трудоемкой задачей, поэтому до сих пор и не сделали. Кроме того, что мы реализуем сейчас, вообщем-то поступательно движение в ту же сторону.
Чтобы помочь нам сделать веб-клиента лучше\проще и дешевле в поддержке и разработке просьба к вам написать максимально конкретные кейсы, в которых стало хуже (сложнее) разрабатывать, которые все еще не закрыты, но по вашим оценкам они встречаются на каждом проекте, да еще и по несколько раз. Тогда у нас будет детальное понимание чего не хватает, а где-то мы подскажем как можно решить проблему сейчас.Хотя бы на уровне, который описал Дмитрий, с отображением диалога после запроса параметров, но и то это лишь кусочек какого-то большого процесса...
Ну сначала хотелось бы оценить "пару слов"... Честное слово, товарищ, а сколько там этих пар? Я сбился на втором абзаце...
Остальное завтра, как дочитаю... эту "пару слов".
Всем привет. Устал читать комменты, много букаф, а тема
сисекдиалогов в параметрах ТМа так и не раскрыта. Скажите удалось ли кому-то вызвать showdialog(dialog) при выполнении задания без всяких условий (тупо показать вместо параметров) или это в принципе не возможно? Пробовал втыкать диалог и до и после запроса параметров. При выполнении задания идет обновление страницы и больше ничего не происходит. Кто что может посоветовать?Вариант с вынесением на ленту задачи отдельной кнопки с последующим написанием JS для каждой кнопки не предлагать, т.к. маршрутов будет минимум 6-7, в каждом по несколько различных блоков заданий со своими вариантами выполнения и хитромудрыми заморочками
В текущей версии веб-доступа таким образом отобразить диалог не получится. Нужно создавать веб-модуль и вызывать этот диалог с помощью клиентской ОМ веб-доступа. А чтобы отобразить этот диалог еще и вместо параметров ТМ, придется лепить костыли и переопределять стандартные функции. Более того, события ТМ, как работали криво в предыдущих версиях, так и ничего и не изменилось.
Уже недели три ковыряюсь с веб-доступом 5.2, пока только один негатив. То тут что-то не работает, то там что-то работает совсем не так как надо. Заголовок статьи однозначно не соответствует действительности.
Дмитрий, сможете поделиться результатами исследований? Было бы крайне интересно услышать от Вас об обнаруженных проблемах. Спасибо!
1. После внесения модификаций в веб-модуль, чтобы изменения вступили в силу, приходилось каждый раз рестартовать IIS. В моем случае даже рестарт IIS не помогал и все модификации просто игнорировались. Подробнее о проблеме и как ее решить тут: Почему пропадают скрипты веб-модуля после обновления страницы? и тут: Как можно избежать необходимости рестарта IIS после редактирования js-файлов в вебе 5,2?
2. Непонятно как работать с событиями ТМ. Проблему удалось решить только после копания в скриптах веб-доступа. В документации тоже ничего на эту тему не сказано. Подробнее тут: Как работать с событиями ТМ с помощью клиентской ОМ веб-доступа в DIRECTUM 5.2?
3. Присутствуют проблемы при работе с таблицами в веб-доступе. Этот дефект устраняется запросом у службы поддержки исправленной версии веб-доступа, но при этом вы должны еще и объяснить, кто вам посоветовал обновиться на эту версию и зачем. Подробнее тут: Почему наличие вычислений на реквизите приводит к тому, что строка не сохраняется в веб-доступе 5,2?
4. Нет возможности работать с параметрами ТМ. Для меня до сих пор остается загадкой, почему такой востребованный функционал остался за бортом стандартных возможностей веб-доступа. Проблему можно решить доработкой серверной части веб-доступа: Как правильно получать параметры ТМ в вебе? Кому данный способ не подошел, выкручиваются, либо с помощью сценариев, либо с помощью запрашиваемых параметров.
5. События ТМ "Начало выбора" и "Завершение выбора" отрабатывают только, если вы выбираете ТМ по кнопке "Типовой маршрут" в карточке задачи. Если вы запускаете задачу по ТМ не по этой кнопке, а например, программно, то вы сами должны озаботиться о том, чтобы эти события отработали. Такое поведение событий ТМ наблюдается во всех версиях веб-доступа 5.х и тут спасают только самописные костыли с переопределением стандартных функций веб-доступа.
6. Неправильно отображаются диалоги в веб-доступе, хоть их поддержка в вебе и заявлена как основная "фича" версии 5.2. Подробнее тут: Почему неправильно отображается диалог в веб-доступе?
7. Проблема с событиями ТМ, они либо не отрабатывают, либо отрабатывают совсем не в тот момент, в какой надо. Лечится опять самописными костылями, с переопределением стандартных функций веб-доступа и добавлением своих собственных событий, которые отрабатываются в нужный момент.
Из крупных проблем, с которыми я столкнулся, пока вроде все. На самом деле этих проблем полно и поток вопросов, связанных с разработкой веб-модулей, после выхода версии 5.2, значительно возрос. Отчасти, это связано с довольно скудной документацией и отсутствием нормальных примеров разработки веб-модулей с помощью клиентской ОМ веб-доступа.
Дмитрий, большое спасибо! А можно ли поподробнее о том, что подразумевается под "самописными костылями, с переопределением стандартных функций веб-доступа"?
Копипаст функции в веб-модуль с последующей ее модификацией под свои конкретные нужды. Можно и стандартную функцию подправить прямо в скрипте веб-доступа, но я предпочитаю стандартные функции не трогать, чтобы при обновлении ничего не пропало и костыль не влиял на другие веб-модули.
Авторизуйтесь, чтобы написать комментарий