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


24

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

Где 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'

2
Это соглашение Symfony . Там хорошая статья здесь , найти бит , который говорит Конечное вещь обратить внимание на специальное значение символа подчеркивания в именах параметров. Параметры, начинающиеся с этого символа, имеют особое значение
Клайв

1
Спасибо, Клайв. Эта статья упоминает «особое значение», но не объясняет это вообще. Почему не подчеркивающие параметры тоже не могут быть особенными?
Даниил

1
lol, Почему не подчеркивающие параметры тоже не могут быть особенными? Это звучит как глубоко экзистенциальный вопрос! Обычно (просто обычно) префиксные переменные делаются либо для обозначения «приватной» переменной (вряд ли здесь), либо для того, чтобы избежать именования коллизий с другими классами / методами / чем-то еще в системе. Было бы хорошо, чтобы увидеть официальные документы, да
Клайв

Ответы:


41

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

Общий обзор

Компоненты 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.

Вау. Впечатляющий ответ. Почему у определенных параметров есть периоды в противоположность использованию подчеркивания? Например user.pass(в примере выше) против user_pass. Это также соглашение Symfony?
Chrisjlee

2
Существует какое-то соглашение об использовании $ module. $ Name в качестве машинного имени маршрута. Ничто, однако, не предполагает это внутренне.
Даниэль Венер

Что касается проблемы ниже, _content больше не используется, а _controller используется. Так что пример в части « Ответ страницы» не актуален. drupal.org/node/2378809 Если мы хотим отобразить данные в области содержимого нашей страницы, то контроллер определит массив визуализации, аналогично тому, как это делается в Drupal 7. Если мы хотим обойти это и создать нашу страницу с нуля, тогда мы можем вернуть объект Response.
Бенелори

Ну, конечно, вы не можете ожидать, что 1,5 года не случится
Даниэль Венер
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.