Comments 6
На версию 2.0 вам несколько советов:
- Разберитесь, как работает DI, и что можно передавать в аргументах в конструктор сервиса. Например, непонятно, зачем передавать имя EntityManager, когда можно передать сам сервис. А если вы будете базировать свое решение на сервисном слое, а не на наследовании контроллеров, будет вообще прекрасно.
- Попробуйте разделить ответственность между компонентами. Типичный симфонийский подход — тонкий контроллер, толстый сервисный слой. Сейчас у вас очень толстый контроллер, и из-за этого вообще сложно воспринимать код.
- Билдер фильтра нужно очеловечивать очень тщательно. Сейчас туда передается слишком уж много параметров — или уж тогда инкапсулируйте эту логику в конфигурационные объекты, или вообще пересмотрите этот API (а лучше и то, и то)
+2
Несколько идей. Посмотрите на реализацию Symfony Forms в качестве источника вдохновения. Вместо того что бы заставлять пользователя наследоваться от ваших контроллеров (это вообще очень неудобный подход) лучше реализовать что-то вроде GridBuilder по аналогии с FormBuilder (с автоопределением типов на основе мэппинга доктрины и все такое).
Сейчас же ваш вариант выглядит даже хуже SonataAdminBundle который я дико не люблю.
Сейчас же ваш вариант выглядит даже хуже SonataAdminBundle который я дико не люблю.
0
Для любителей Symfony и не любителей SonataAdminBundle есть еще такая альтернатива github.com/javiereguiluz/EasyAdminBundle от небезызвестного Javier Eguiluz
0
Спасибо за комментарии.
Я согласен, что для формирования списка пользователей или списка контента обычного сайта готовить такие контроллеры будет утомительно (хотя я, наверное, по привычке, пользуюсь этим контроллером и в обычных админках).
Наверное мне надо было аргументировать, почему выбран вариант наследования.
Главная причина — возможность переопределить нужный метод. Где-то в 5% случаях мне это требуется. Например: форма фильтров обычная, а «накладывать» значения полей формы на запрос надо с дополнительными условиями (или проверками). Этот бандл писался для CRM системы — отчёты там иногда приходится реализовывать очень нестандартные.
Я согласен, что для формирования списка пользователей или списка контента обычного сайта готовить такие контроллеры будет утомительно (хотя я, наверное, по привычке, пользуюсь этим контроллером и в обычных админках).
Наверное мне надо было аргументировать, почему выбран вариант наследования.
Главная причина — возможность переопределить нужный метод. Где-то в 5% случаях мне это требуется. Например: форма фильтров обычная, а «накладывать» значения полей формы на запрос надо с дополнительными условиями (или проверками). Этот бандл писался для CRM системы — отчёты там иногда приходится реализовывать очень нестандартные.
0
Sign up to leave a comment.
Symfony2. Универсальный инструмент для быстрого приготовления табличных списков в административной панели