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

Как обстоят дела со всеми параметрами с префиксным символом подчеркивания и без него ?

Где Drupal решает, как обрабатывать эти параметры?

Эта концепция была представлена ​​Symfony, или она нова для Drupal?

Пример ( node.routing.yml ):

node.overview_types:
  path: '/admin/structure/types'
  defaults:
    _controller: '\Drupal\Core\Entity\Controller\EntityListController::listing'
    entity_type: 'node_type'
    _title: 'Content types'
  requirements:
    _permission: 'administer content types'

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

Общий обзор

Компоненты 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 решил просто разрешить использовать недопустимый ключ «path» в своем файле маршрутизации.

Ключевой концепцией является контроллер, который получает некоторые параметры из системы и преобразует их в ответ. В этом примере у вас есть параметр '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 гарантирует, что у пользователя есть определенная роль (вы можете указать несколько из них, для OR и + для логики AND). _entity_access спрашивает систему сущностей, есть ли у вас доступ для просмотра сущности пользователя. По умолчанию drupal гарантирует, что добавление контролеров доступа позволит вам продолжить, но вы можете переключить его в настройках через _access_mode.

Приведение к базовому типу

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

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

Как написано ранее, контроллер отвечает за генерацию объекта ответа. Это было бы ужасно в Drupal, так как страница состоит из гораздо большего, как все блоки, появляющиеся в ее регионах, 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; DR

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