Создание DRY Symfony2 Controller — список

Моя цель — создать полнофункциональный пользовательский интерфейс администратора CRUD, создав 3 файла (сущность yml, ветку списка и ветку редактирования) и отредактировав еще 3 существующих (services.yml, parameters.yml и routing.yml).

Веточки наследуют базовый шаблон, который обеспечивает контекст (заголовок, боковую панель, нижний колонтитул, стиль начальной загрузки, javascripts и т. Д.), В то время как для сущности yml потребуется команда doctriine: generate: entity, чтобы я мог получить сущность в виде простого php объект.

Пример:

Объекты:

  • Работа, вакансии:

    • заглавие
    • описание
    • от
    • до
    • URL
  • Проект:

    • заглавие:
    • статус:
    • URL:
    • описание
  • Пользователь (наследующий объект FOSUserBundle):

    • ID клиента
    • clientSecret
    • социальная сеть
    • профиль
    • аватар

Так как я хочу, чтобы мой код был СУХИМ, я подумал, что должен использовать служебный контроллер, который получает некоторую инъекцию сеттера для требований. Один из внедренных объектов — это класс для определения конфигурации контроллера (например, какой репозиторий запрашивать, какой метод использовать в этом репозитории, какой шаблон визуализировать и т. Д.), Называемый Configurator.

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

  • Репозиторий
  • Конфигуратор службы
  • Контроллер службы

В services.yml будет пакет из этих трех сервисов выше для каждого объекта, все с разными именами. Пример: admin.job.repository, admin.project.repository. На первый взгляд, это не очень СУХО, но пока вам приходится дублировать только конфигурационные файлы, мне повезло, что я все еще достигаю своей главной цели.

Пример:

Репозиторий
admin.job.repository:
класс: Doctrine \ ORM \ EntityRepository
factory_service: doctrine.orm.default_entity_manager
factory_method: getRepository
аргументы:
- AppBundle \ Entity \ Job

Конфигуратор службы:

admin.job.config.list:
класс: AppBundle \ Configurator \ ListControllerConfigurator
аргументы:
- @ admin.job.repository
- "AdminBundle: Job: list.html.twig" вызывает:
- [setRepoMethod, ["findJobsForTimeline"]]
- [setPerPage, [% knp_paginator.page_range%]]
- [setParameters, [% admin.job.list.parameters%]]

В Конфигураторе я использовал аргументы для обязательных инъекций и сеттеры в качестве необязательных параметров, которые имеют жестко заданные стандартные отступы в PHP. (например, findAll для репо, 10 для perPage и т. д.).

Контроллер сервиса:
admin.job.controller.list:
класс: AdminBundle \ ListController
аргументы:
- @ admin.job.config.list
звонки:
- [setContainer, [@service_container]]

Конфигурация маршрутизации:

admin_Job_list:
путь: / {страница}
значения по умолчанию: {_controller: admin.job.controller.list: listAction, page: 1}
требования:
страница: \ d +

Код является полностью функциональным и отображает страницы списка должным образом.

Мои вопросы:

  • Есть ли другой лучший способ справиться с дублированием кода? При создании этого материала меня вдохновили Sonata, EasyAdmin и другие подобные пакеты; все вышеперечисленное — зрелые, сложные связки, но я хотел получить самодельное колесо, которое имеет дидактическое (понты) назначение
  • почему после любого изменения в services.yml, routing.yml или parameters.yml выполнение любого запроса занимает от 5 до 30 секунд? из того, что я видел, services.yml переводится в обычный PHP в app / cache / dev / appDevDebugProjectContainer.php — это причина?

1

Решение

Вы можете создать свое собственное расширение DI. Это в основном позволяет вам указать свое собственное дерево конфигурации YML и как генерировать сервисы / параметры из него. Вы можете указать только соответствующие элементы в YML, и все службы репозитория / конфигуратора / контроллера генерируют динамически:

my_superior_crud:
Job:
fields:
- Title
- Description
- From
# ...
template: 'AdminBundle:Job:list.html.twig'
route_path: '/{page}'
# ...
# ...

Расширения кратко упоминаются в документах, но вы можете найти несколько приличных статей (как этот, или же этот). Также посмотрите существующие расширения (ветка довольно проста для понимания).

И на ваш второй вопрос, да, это очень вероятно, генерация кэша.

2

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector