В настройках компонента «Ссылка на реестр» добавлены новые флаги:

Пример использования новых настроек

На форму добавлен компонент «Ссылка на реестр»:

Рисунок 3.29.

В настройках компонента включены мультивыбор, возможность создания, редактирования записей, просмотр выбранных записей в диалоговом окне:

Рисунок 3.30.

В результате ниже поля выбора записей реестра отображен лейбл «+ Создать», видимый как в режиме конструктора форм, так и в режиме редактирования:

Рисунок 3.31.

Перейдем в режим редактирования формы и выберем несколько записей реестра «Сервисы»:

Рисунок 3.32.

Выбранные записи отображены в виде тэгов. Выбранную запись можно удалить из поля, нажав на , или выбрать дополнительно другие записи реестра.

В режиме просмотра формы выбранные записи реестра отображаются по одной в строке:

Рисунок 3.33.

Если, находясь в режиме редактирования формы, дважды кликнуть по тэгу выбранной записи, откроется диалоговое окно, в котором можно отредактировать эту запись:

Рисунок 3.34. Диалоговое окно «Редактирование»

Для создания новой записи выбранного реестра нужно кликнуть по лейблу «Создать». Откроется диалоговое окно создания записи:

Рисунок 3.35. Диалоговое окно «Создание»

Поведение после нажатия на кнопку «Создать» - оставлять ли созданную запись в статусе «Подготовка» или запускать для нее маршрут активации - регулируется флагом «Отправлять созданную запись на активацию». В нашем случае этот флаг отключен, и созданная запись не будет активирована.

Если, находясь в режиме просмотра формы, нажать на строку с выбранной записью реестра, то эта запись откроется в режиме просмотра. Настройки компонента регулируют, будет ли она открыта в диалоговом окне или в новом. В нашем случае включен флаг «Открывать в диалоге», поэтому запись открывается в диалоговом окне:

Рисунок 3.36. Диалоговое окно «Просмотр»

Помимо возможности мультивыбора, создания и редактирования записей «на лету», мы существенно доработали возможности сопоставлений данных из записей, выбранных в реестре.

В настройках компонента «Ссылка на реестр» была добавлена новая вкладка «Сопоставления», которая позволяет настроить один из двух видов сопоставлений:

Рисунок 3.37. Вкладка «Сопоставления»

Обратите внимание: сопоставление возможно только в том случае, если у компонента отключен мультивыбор.

Во-первых, мы изменили вид таблицы сопоставлений: теперь вместо поиска идентификатора нужного компонента в выпадающем списке можно пользоваться текстовым поиском:

Рисунок 3.38. Возможность текстового поиска и фильтрации id компонентов в таблице сопоставлений

Во-вторых, отменено ограничение на сопоставление нескольких полей источника в одно поле приемника. Теперь контроль таких ситуаций остается на стороне пользователя, настраивающего сопоставления.

В-третьих, мы реализовали возможность вложенных сопоставлений. Теперь в качестве источника можно указывать не только поле, непосредственно находящееся на форме реестра, но и поля формы, ссылки на реестры которых используются на форме выбранного реестра.

Рассмотрим пример использования вложенных компонентов.

Предположим, что в приложении есть такие формы:

Рисунок 3.39. Форма “Физическое лицо

Рисунок 3.40. Форма «Адресный регистр»

Рисунок 3.41. Форма «Заявление», где в качестве заявителя указывается запись реестра «Физические лица»

Необходимо из формы заявления формировать отказ в регистрации. Причем на форме отказа должно быть достаточно выбрать только заявление-основание, остальные сведения должны быть заполнены автоматически:

Рисунок 3.42.

Видно, что напрямую из формы «Заявление» невозможно взять такие сведения, как ФИО заявителя, его ИИН и дату рождения. А для того, чтобы найти сведения об адресе проживания человека, необходимо использовать форму «Адресный регистр».

До версии 4.0 одним из способов решения этой задачи был такой:

Теперь можно достигнуть того же результата, используя всего одно сопоставление.

Сначала настроим форму отказа:

Рисунок 3.43.

Здесь:

Теперь добавим на форму «Заявление» ссылку на реестр «Отказы», включим в настройках возможности создания новой записи, отправку этой записи на активацию и заполнение в новой записи ссылки на текущую запись:

Рисунок 3.44. Настройки ссылки на реестр «Отказы», свойства

Обратите внимание, что в текстовом поле для флага «Добавлять в создаваемой записи ссылку на текущую запись» также доступен поиск и фильтрация id компонентов формы того реестра, который выбран в настройках. Укажем в этом поле reglink-z - ссылка на реестр заявлений, расположенная на форме отказа.

Этот флаг в нашем случае включен для того, чтобы в созданной записи отказа была автоматически заполнена ссылка на заявление, к которому он относится.

Теперь перейдем к настройке сопоставлений в этом компоненте.

В первую очередь выберем тип сопоставления «Из текущей записи в новую». Появится пустая таблица сопоставлений.

Теперь начинаем добавлять сопоставления. В общем случае формат вложенных сопоставлений можно описать так:

%id_компонента_ссылки_на_реестр1_с_формой1%/%id_компонента_ссылки_на_реестр2_содержащегося_на_форме1%/.../
%id_компонента_ссылки_на_реестрN_содержащегося_на_форме(N-1)%/%id_компонента_значение_которого_нужно_вставить%`

В нашем случае нам нужно обратиться к форме записи, выбранной в компоненте текущей формы reglink_fl (ссылке на реестр «Физические лица») и найти на этой форме компонент с кодом fio (поле с ФИО физического лица). В поле «Источник» вводим значение reglink_fl/fio.

В поле «Приемник» указываем id компонента формы «Отказ», куда должна быть сопоставлена фамилия заявителя - у нас это fio.

Рисунок 3.45. Результат

Таким же образом настроим сопоставления ИИН и даты рождения:

Рисунок 3.46. Настроенные сопоставления

Для того, чтобы получить адрес проживания заявителя, нужно обратиться к записи реестра «Адресный регистр», ссылка на которую есть в записи формы «Физическое лицо». В этом случае можно использовать второй уровень вложенности сопоставлений:

Рисунок 3.47. Указание источника сопоставления для адреса

В качестве источника указана конструкция reglink_fl/reglink-addr/address: то есть на форме записи, выбранной в компоненте reglink_fl, найти компонент reglink-addr, и на форме записи, выбранной в этом компоненте, взять значение поля address.

Таким образом может быть настроено сопоставление любого уровня вложенности.

Рассмотрим ситуацию, когда на форме есть некоторое поле с категорией. Выбранная категория влияет на состав полей на форме. В нашем случае это будет некоторый инцидент, который может быть трех типов:

Для решения такой задачи нужно в первую очередь создать форму «Инцидент» и расположить на ней все поля, которые потребуются при выборе разных категорий. Для удобства настройки условий рекомендуем компоненты, которые должны быть скрыты/отображены одновременно, располагать в статических таблицах, чтобы можно было скрывать/отображать таблицу целиком.

Создадим такую форму:

Рисунок 3.51. Форма «Инцидент» в режиме конструктора

Видно, что все компоненты, которые нужно показывать/отображать опционально, расположены в отдельных таблицах. В нашем случае эти таблицы такие:

Понятно, что в реальных условиях расположить все опциональные поля в одной таблице невозможно, однако мы рекомендуем стремиться к максимально возможной группировке элементов, чтобы упростить процесс настройки и отладки действий.

Поле «Категория» у нас типа «Выпадающий список», у него задан идентификатор type и настроены элементы:

Рисунок 3.52. Элементы компонента «Категория»

Настроим начальное состояние компонентов: поскольку у нас в поле «Категория» по умолчанию выбрано значение «Техподдержка», то и отображенной оставим только таблицу table-support, а в настройках таблиц table-license и table-sert включим флаг «Скрытое поле». В режиме редактирования формы результат будет выглядеть так:

Рисунок 3.53. Начальное состояние формы «Инцидент»

Теперь перейдем к настройке условий. В навигаторе выделим папку «Условные действия», которая расположена в нашей форме, и выберем пункт «Добавить группу действий». В появившемся диалоге введем название case_category - здесь будут расположены условия, реагирующие на состояние поля «Категория»:

Рисунок 3.54. Новая группа условий

Название группы действий служит исключительно для удобства, поэтому мы рекомендуем давать группам значимые названия, отражающие, что именно в ней настраивается.

Добавим первое условие. В нем укажем, что в случае, когда в поле «Категория» выбрано значение «Техподдержка», нужно отобразить таблицу со сведениями об инциденте:

Рисунок 3.55. Действие 1: отобразить таблицу support

Здесь в качестве левого операнда выбран компонент type, который сравнивается с текстовым значением 01 - кодом элемента «Техподдержка» в списке элементов компонента. Если это сравнение истинно, то нужно включить видимость компонента table-support.

Кроме отображения нужной таблицы с описанием инцидента нужно еще и скрыть таблицы, относящиеся к другим категориям. Добавим эти действия:

Рисунок 3.56. Действие 1: отобразить таблицу support, скрыть таблицы sert и license

Теперь в эту же группу добавим действия для случаев, когда в качестве категории выбраны другие значения:

Рисунок 3.57. Настроенные действия

Здесь для каждого элемента выпадающего списка «Категория» указано, что одна из таблиц должна быть отображена, остальные таблицы - скрыты.

Размещение плашек действий в одной группе, как в примере, или в разных - это лишь вопрос удобства настройки и последующей отладки формы. Мы рекомендуем группировать однотипные условия, а также размещать в одной группе обратные друг другу действия, например, включение и отключение доступности одного компонента.

Теперь вернемся в режим конструктора формы. В таблице table-license есть поле ввода даты окончания действия лицензии date-end и флаг check, который означает, что у лицензии неограниченный срок действия:

Рисунок 3.58. Сведения о лицензии на форме

В этом случае логично как минимум не требовать заполнения даты date-end, а еще лучше - блокировать поле ввода даты при включении флага. Такое поведение тоже можно реализовать с помощью условий и действий.

Во-первых, проверим элементы компонента «Выбор вариантов» - нам понадобится код элемента «Не ограничен»:

Рисунок 3.59. Элементы компонента check

Во-вторых, создадим новую группу условий is_limited, в которой будут действия, зависящие от состояния флага. Добавим в эту группу два условия - для включенного флага и для отключенного:

Рисунок 3.60. Группа действий для даты окончания действия

Здесь мы в качестве оператора использовали текстовое сравнение «Содержит», поскольку в ключе компонента «Выбор вариантов» хранятся коды всех выбранных элементов (см. описание формата компонентов форм). Правый операнд - код элемента «Не ограничен» not_limited.

Первое условие расшифровывается так: если key компонента check содержит элемент not_limited, то необходимо снять обязательность заполнения компонента date-end и заблокировать его от изменений.

Второе условие - обратное к первому: если key компонента check не содержит элемент not_limited, то необходимо разблокировать компонент date-end и сделать его обязательным для заполнения.

Снова вернемся на вкладку с конструктором формы, сохраним форму. После сохранения формы настроенные условия можно проверить, перейдя в режим заполнения формы:

Рисунок 3.61. Режим заполнения формы, указана категория «Сертификация»

Для категории «Сертификация» отображен только выбор типа сертификата, остальные сведения скрыты.

Рисунок 3.62. Режим заполнения формы, указана категория «Генерация лицензий», флаг отключен

Для категории «Генерация лицензий» при отключенном флаге поле выбора даты доступно. После клика в этом поле оно подсвечено красным, как обязательное.

Рисунок 3.63. Режим заполнения формы, указана категория «Генерация лицензий», флаг включен

В том же случае после включения флага поле ввода даты блокируется.

В этом примере рассмотрим работу с компонентами, расположенными в динамических таблицах. В качестве иллюстрации будем использовать некоторую форму заказа, где указывается список товаров с указанием для каждого из них цены за единицу, количества и, при необходимости, обоснования.

Предположим, что обоснование необходимо писать только для товаров, количество или цена которых превышает максимально допустимые.

Создадим форму для этого заказа:

Рисунок 3.64. Форма «Заказ»

На форме есть два компонента, содержащие максимальную цену за единицу товара (max_price) и максимальное количество единиц (max_count), доступные без обоснования. В нашем примере эти поля имеют значение по умолчанию и не скрываются.

Создадим в папке «Условные действия» новую группу действий max_control, в которой настроим нужную нам логику:

Рисунок 3.65. Настроенные действия для заказа

Первое условие: если в таблице цена за единицу (значение поля price в таблице) больше, чем максимально допустимая max_price, или указанное количество (поле count в таблице) больше максимально допустимого max_count, то поле обоснования reason в этой же строке сделать обязательным.

Второе условие: если оба поля (и цена за единицу, и количество) не превышают допустимых значений, то сделать ввод обоснования не обязательным.

Вернемся на вкладку с конструктором формы, сохраним ее и проверим настроенные действия:

Рисунок 3.66. Пример заполнения формы «Заказ»

Видно, что как только либо цена за единицу, либо количество, указанные в одной строке формы, превышают заданный максимум, соответствующее поле «Обоснование» становится обязательным. Важно заметить, что в этом случае действие применяется только к компоненту в том же блоке динамической таблицы, где было выполнено условие: для строк, в которых оба значения не превышают максимума, обоснование осталось не обязательным.

Таким же образом можно настраивать действия, сравнивая компоненты динамической таблицы только между собой или с эталонными значениями. Например, в динамической таблице для каждого мероприятия указан либо срок его завершения, либо признак «На постоянной основе»:

Рисунок 3.67. Форма мероприятий

У компонента type, регулирующего длительность, есть два элемента:

Так же, как и в первом примере, настроим условные действия для этой формы:

Рисунок 3.68. Условия для компонентов в динамических таблицах

Поскольку здесь сравниваются только компоненты в динамической таблице и эталонные значения, указанное действие будет выполнено только в том же блоке (строке) таблицы, где условие истинно:

Рисунок 3.69. Пример работы действий

Простое сравнение

Простой вариант сравнения строки с шаблоном - сравнение введенного символа с некоторой константой. Иначе говоря, сравнение символа с самим собой. Для этого достаточно в выражение добавить нужный символ, например, @. В этом случае сравнение будет успешным в том случае, если в введенной строке нашелся указанный символ (или последовательность символов).

Специальные символы и экранирование

Синтаксис RegExp поддерживает большое количество специальных символов, в частности: . ^ $ * + ? { } [ ] | ( ) Для поиска этих символов в введенной строке следует экранировать их в шаблоне с помощью символа /, например:

Поиск и сравнение строк

Поскольку маска поля настраивается только для однострочного поля, при подготовке маски RegExp имеет смысл указать, в каком случае введенная строка будет считаться корректной:

Наборы символов и диапазоны

В приведенных выше примерах рассматривался поиск ровно подстроки abc. Но часто возникает ситуация, когда существует множество разрешенных или, наоборот, запрещенных символов: строка должна содержать только буквы латинского алфавита, или только буквы кириллического алфавита, или, например, строка не должна содержать цифр. В этом случае полезно использовать сравнение с набором символов. Если в строке на указанном месте будет стоять любой символ из перечисленных в наборе, строка будет считаться корректной.

Наборы заключаются в квадратные скобки [ ]. В качестве примера можно привести набор [ABC] - ему соответствут любой из символов A, B или C (но не a, b или c), расположенный в произвольной подстроке.

В случае, если множество символов, которые должны быть включены в набор, достаточно велико, удобно пользоваться механизмом диапазонов. Для этого достаточно в наборе указать граничные символы, добавив между ними дефис, например:

Наборы можно комбинировать произвольным образом:

Если первым символом в наборе (сразу после [) указан символ ^, то он служит маркером отрицания: соответствовать набору будут строки, содержащие любые символы, кроме перечисленных в наборе:

Квантификаторы (повторения)

В рассмотренных примерах с наборами символов есть один важный нюанс: при указании набора в шаблоне совпадением будет считаться хотя бы один найденный символ из набора. В случае, когда необходимо регулировать количество повторений, к набору может быть применен специальный квантификатор.

Количество повторений символов из набора указывается после этого набора в фигурных скобках { }.

Для часто используемых вариантов квантификаторов применяются специальные обозначения:

Некоторые Escape-последовательности

Наборы символов - универсальный инструмент для записи выражения, однако при работе со строками множество допустимых символов может быть настолько велико, что соответствующий набор становится крайне сложным для понимания. Для упрощения записи выражений применяются специальные escape-последовательности. Приведем некоторые из них:

Перечисления

Чтобы проверить, удовлетворяет ли строка одному из шаблонов, можно воспользоваться аналогом оператора OR, который в регулярных выражениях записывается с помощью символа |. Например, шаблону /d{16}|[A_Za-z]{2}[A-Za-z0-9]{18} будет соответствовать как 16-значный номер платежной карточки, так и 20-значный номер счета (если они введены без пробелов и дефисов).

В настройках компонента «Однострочное поле» добавлен новый флаг «Регулярные выражения»:

Рисунок 3.70. Настройки компонента «Однострочное поле»

Когда этот флаг включен, маска, указанная в настройках, интерпретируется как регулярное выражение. Соответствующим образом при включенном флаге меняется и текст подсказок, отображаемых по нажатию на :

Рисунок 3.71. Подсказки при использовании регулярных выражений

Вы можете вставить выражение из подсказки, просто кликнув по нему.

Вид и поведение поля с настроенной таким образом маской:

Если значение поля не соответствует указанному регулярному выражению, оно считается некорректно заполненным, и данные формы с таким значением не сохраняются.

Мы рекомендуем прибегать к регулярным выражениям только в том случае, когда невозможно настроить правила валидации поля с использованием простой маски.

Для упрощения разработки RegExp можно использовать специальные сайты, позволяющие проверить настроенный шаблон, например:

До версии Synergy 4.0 поле с настроенной маской было всегда обязательным, вне зависимости от состояния флага «Обязательное поле» в настройках этого компонента. Так происходило потому, что пустое поле не соответствовало маске, следовательно, считалось заполненным некорректно. Из-за этого невозможно было настроить поведение вида «поле с номером телефона должно соответствовать маске, но не обязательно для заполнения».

В новой версии мы изменили подход к проверке обязательности компонента. Теперь для значения компонента проверяется его соответствие маске только в том случае, если это значение не пусто. Это правило применяется как для масок старого формата, так и для регулярных выражений.