Конструктор ограничений

[mar-hab]

Цель

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

Функциональные требования

1. Конструктор предназначен для использования продвинутым пользователем, способным построить логическое выражение, но не владеющим навыком программирования.
2. Конструктор должен позволять задавать ограничения для списка по условиям на атрибуты списка (и связанных объектов, в т.ч. мастеров и детейлов любого уровня) соединенных любой последовательностью И/ИЛИ/НЕ. Список таких условий должен быть доступен для выбора пользователю.
3. Условия могут быть стандартные =, <>, >, < и должна быть возможность расширения (например "содержит", "пусто"). Список таких условий должен быть доступен для выбора пользователю.
4. Должна быть возможность использовать в условиях преобразования и "константы" (Год указанного значения даты, текущие дата-время). Должна быть возможность расширения. Список таких функций должен быть доступен для выбора пользователю.
5. Пользователю должен быть предоставлен перечень атрибутов, которые можно использовать.
6. Должна быть проверка валидности условия по типам операндов, по синтаксису (если использовать вариант, предложенный ниже)
7. Должна быть возможность сохранения ограничения, создания на основе текущего, объединения разных ограничений по И, ИЛИ (м.б. НЕ).
8. Должна быть возможность "миграции" ограничения (сохранения его, чтобы распространить на разных источниках- например разработать на dev, поставить на prod)
9. Желательна возможность использования параметров (не заданных изначально значений, которые можно задать при использовании ограничения)
10. Желательно возможность выбора/подстановки значений для ограничения из источника данных.

Требования к реализации

Предложение, как можно сделать. См макет. Это не дизайн, а про содержание но форме.
Предлагается отказаться от элементов программирования (new SimplePredicate и т.п.) и использовать более человекочитаемую запись. При этом оставить возможность описания в старом формате (по тогглеру "В виде кода" переключаться в разные представления без потери содержания). Чтобы явно разделять атрибуты, значения, операторы, параметры, функции предлагается использовать служебные символы @, #, ?. Возможно, жестко требовать наличие хотя бы одного пробела между элементами. При проверке выражения в т.ч. проверять парность скобок, соответствие типов слева и справа от операнда. Допускаются строковые значения без '. В случае использования в строковом значении спецсимволов - допускается ' (тогда проверять парность).
Перечень атрибутов, условий, функций нужно задавать в коде для конкретного списка. Содержание таких настроек может выглядеть так

• для атрибутов - наименование в модели для создания ограничения, тип, капшн для отображения, списковая форма для выбора значения, атрибут, из которого нужно получить значение для подстановки
• для атрибутов типа ссылок (см @ПропискаТерритория) - еще дополнительно атрибут для отображения в тексте ограничения (т.е. Пермь показываем, но в ограничении реально подставлен guid)
• для логического условия - капшн, его программное соотв-вие ( = это 'eq'), возможно допустимый тип (для #содержит)
• для функций - - капшн, его программное соотв-вие, тип параметра, тип возвращаемого значения
• для атрибутов сложных ограничений (это атрибутика детейлов) - информация для связки объекта детейла с мастером, + то же, что для атрибутов
  В атрибутах (и простых ограничений и сложных) есть кнопка лукапа, которая открывает в диалоге список значении из БД на выбор (м.б. проще чтото можно).
  Доступные действия:
• клик по названию атрибута, условия, функции подставляет ее в место курсора в поле выражения
• клик по лукапу значения атрибута и выбор значения подставляет значения в место курсора в поле выражения
  При применении ограничения, если есть ?параметр - сначала открывается диалог с полями для ввода параметров. Если заданы настройки для лукапа для операнда слева выражения - должна быть возможность лукапа.
  Пояснение к ограничениям на детейлы - в примере перемешана атрибутика из разных объектов для простоты описания условий. Предполагается, что если в одних скобках собраны атрибуты одного класса и другого - превращать это в столько сложных условий, сколько объектов, атрибуты одного объекта собирать в одном условии. М.б. стоит, наоборот, запретить такую запись. Считаем, что сложные условия требуют более продвинутого уровня пользователя и что такие условия будут редко создаваться пользователем.

Полезные ссылки, скриншоты