Создан  demius PM 4 года назад; Обновил  demius PM год и 4 месяца назад

Как оказалось весьма нетривиальная вещь. И так фильтры штуки разные, некоторые (фильтры по справочным полям) зависят от контекста проекта.

Хранить их той же структуре, в котором удобно передавать через query неудобно.

Фильтры явно являются контролами формы, а вот их набор динамический, статический, в виде коллекции или отдельной модели? Сортировка являясь частью модели вряд ли является контролами формы (точнее делать их так сложно) Впрочем не делать их так сложно сохранить все состояний настройки списка задач.

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

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

Как оказалось весьма нетривиальная вещь. И так фильтры штуки разные, некоторые (фильтры по справочным полям) зависят от контекста проекта.

Хранить их той же структуре, в котором удобно передавать через query неудобно.

Фильтры явно являются контролами формы, а вот их набор динамический, статический, в виде коллекции или отдельной модели? Сортировка являясь частью модели вряд ли является контролами формы (точнее делать их так сложно) Впрочем не делать их так сложно сохранить все состояний настройки списка задач.

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

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

  1. Создать модель настроек списка задач.
  2. Заполнить её объектами фильтров, сортировок, пагинации
  3. Создать спецификации и конверт в оные. Методы репозитория переделать на спецификации
  4. Создать сервис перегоняющий объекты в отображения презентации, квери для урла, набор форм и просто контролов. И обратно из форм.
  5. Сохранять в сессию натыканные фильтры
Комментарии могут оставлять только авторизованные пользователи
 demius год и 4 месяца назад

Переделали с нуля вобще без форм.

  • С умным дто query умеющим отдавать данные под ссылку или набор спецификаций,
  • С отдельной вьюхой, хранящей всю необходимую информацию для отображения таблицы
  • с vue-компонентами для фильтров, позволяющей делать нестандартные контролы.

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

 demius 3 года назад

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

  1. Создать модель настроек списка задач.
  2. Заполнить её объектами фильтров, сортировок, пагинации
  3. Создать спецификации и конверт в оные. Методы репозитория перделать на спецификации
  4. Создать сервис перегоняющий объекты в отображения презентации, квери для урла, набор форм и просто контролов. И обратно из форм.
  5. Сохранять в сессию натыканные фильтры
 demius 3 года назад

Так же было бы не плохо собирать из фильтров запрос к бд с помощью спецификации, а не $criteria

 demius 4 года назад

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