Почему файлы маршрутизации заполнены подчеркиваниями?

Здесь приводится, надеюсь, хорошее объяснение идеи системы маршрутизации , а также конкретных дополнений к ней для drupal.

Общий обзор

Компоненты Symfony имеют здесь две важные концепции. Ядро http - это система, которая получает запрос, каким-то образом запрашивает другие системы, чтобы определить фрагмент кода, который выдает запрошенный вывод (объект ответа), и отправляет ответ обратно клиенту. Этот фрагмент кода называется контроллером, так что это может быть либо чистой функцией, подобной php4, методом для объекта, либо даже анонимной функцией.

Система, которая знает, какой контроллер отвечает за текущий запрос, является системой маршрутизации.

Базовый файл маршрутизации

Как разработчик модуля вы определяете список маршрутов и соответствующих контроллеров.

Вот пример ответа json:

taxonomy.autocomplete_vid:
  path: '/taxonomy/autocomplete_vid/{taxonomy_vocabulary}'
  defaults:
    _controller: '\Drupal\taxonomy\Controller\TermAutocompleteController::autocompletePerVid'
  requirements:
    taxonomy_vocabulary: \d+

В большинстве документации symfony упоминается шаблон, но drupal решил просто разрешить не устаревший ключ "путь" в файле маршрутизации.

Ключевым понятием является контроллер, который получает некоторые параметры из системы и преобразует их в ответ. В этом примере у вас есть параметр "taxonomy_vocabulary". Таким образом, все, что не имеет подчеркивания, считается параметром контроллера. Если вы хотите указать значение по умолчанию, вы помещаете его в массив по умолчанию. В том же массиве yml вы указываете класс и метод, связанные с '::', чтобы указать системе, куда поищи что-нибудь. Любое другое свойство не имеет ничего общего с параметрами контроллера и поэтому считается внутренним и поэтому имеет символ подчеркивания в качестве префикса.

Сама Symfony также позволяет определять регулярные выражения для проверки правильности входящего параметра (используя "требования"). Здесь он будет соответствовать только числам.

Преобразователь контроллера

Как только symfony выяснил, какой контроллер активен в текущем запросе, он запрашивает так называемый распознаватель контроллеров чтобы создать экземпляр контроллера, который может быть выполнен с помощью call_user_func_array. Преобразователь контроллера имеет один метод для вызова контроллера (объект + метод, анонимная функция) и один метод для передачи параметров контроллеру, см. Преобразователь контроллера

Расширения Drupal

Это в основном то, что дает вам symfony.

Хотя Drupal немного сложнее:

• Вы можете проверить доступ к маршруту. Например вызов функции user_access() был очень распространен в Drupal 7 и ниже.
• Вы не хотите преобразовывать taxonomy_vocabulary в его фактический объект сущности
• Вы не хотите генерировать ответ на всю страницу, а только "основное содержимое".

Проверка доступа

Drupal представил систему поверх частей symfony, которая проверяет, имеет ли пользователь доступ к текущему маршруту, и альтернативно выдает исключение 403 (доступ запрещен). Доступ менеджер

В файле маршрутизации вы указываете это в части требований. Наиболее распространенные биты перечислены в примере:

  path: '/user/{user}'
  options:
    _access_mode: 'ANY'
  requirements:
    _permission: 'access user profiles'
    _entity_access: 'user.view'
    _role: 'administrator'

_permission определяет вызов функции user_access(), _role гарантирует, что у пользователя есть определенная роль (вы можете указать несколько ролей с помощью, для ИЛИ и + для И логики). _entity_access запрашивает систему сущностей, есть ли у вас доступ для просмотра сущности пользователя. По умолчанию drupal гарантирует, что вы добавите средства проверки доступа, которые позволят вам продолжить, но вы можете переключить их в настройках через _access_mode.

Трансляция вверх

Как упоминалось в списке, вы не хотите заботиться о загрузке сущности, см. /user/{пользователь} в качестве примера. Для сущностей вы в основном просто используете имя типа сущности, и он выполнит entity_load с идентификатором, переданным в URL. Менеджер конвертеров параметров

Ответ на страницу

Как было написано ранее, контроллер отвечает за создание объекта ответа. Это было бы ужасно в Друпале как страница состоит из гораздо большего, чем все блоки, появляющиеся в ее регионах, html и шаблоны страниц и т.д. Поэтому drupal указал другой ключ для указания контроллера, который возвращает содержимое страницы:

user.page:
  path: '/user'
  defaults:
    _content: '\Drupal\user\Controller\UserController::userPage'
  requirements:
    _access: 'TRUE'

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

Еще одно дополнение - это также способ работы с формами, поскольку возврат страницы с формой немного сложнее, чем просто массив визуализации, поэтому вы можете определить _form с помощью интерфейса FormInterface, отвечающего за текущую форму.

user.pass:
  path: '/user/password'
  defaults:
    _form: '\Drupal\user\Form\UserPasswordForm'
  requirements:
    _access: 'TRUE'

Примечание: Это охватывает наиболее важные моменты с моей точки зрения, хотя наверняка есть еще много моментов, о которых стоит поговорить.

TL;ДР

• Подчеркивания указываются для всего, что не является параметрами контроллера. Это своего рода "стандарт" от symfony.
• Эти параметры передаются с помощью преобразователя параметров и передаются в контроллер, использующий преобразователь контроллера
• В Drupal есть некоторые дополнения, облегчающие людям взаимодействие с системой маршрутизации symfony.