Typo3 9.5 - Помогите понять новые средства улучшения маршрутизации - PullRequest
0 голосов
/ 07 ноября 2018

Я погружаюсь в конфигурацию маршрутов в довольно сложном проекте, и я изо всех сил пытаюсь обдумать один аспект этого. В примерах здесь https://docs.typo3.org/typo3cms/extensions/core/latest/Changelog/9.5/Feature-86365-RoutingEnhancersAndAspects.html параметр limitToPages представляется весьма важным. Но как мне получить маршрут для всех страниц, на которые установлен плагин, без возникновение конфликта с другими плагинами или расширениями? Один пример: у меня есть плагин для событий и событий. Оба имеют вид списка с нумерацией страниц. Моя конфигурация до сих пор:

PoiPlugin:
  type: Extbase
  extension: supervendor
  plugin: pois
  routes:
  - { routePath: '/{page}', _controller: 'POI::list', _arguments: {'page': '@widget_0/currentPage'} }
  - { routePath: '/{poi_title}', _controller: 'POI::show', _arguments: {'poi_title': 'item'} }
  defaultController: 'POI::list'
  defaults:
    page: '0'
  requirements:
    page: '\d+'
    poi_title: '^[a-zA-Z0-9]'
  aspects:
    page:
      type: StaticRangeMapper
      start: '1'
      end: '100'
    poi_title:
      type: PersistedAliasMapper
      tableName: 'tx_supervendor_domain_model_poi'
      routeFieldName: 'path_segment'
EventPlugin:
  type: Extbase
  extension: supervendor
  plugin: events
  routes:
  - { routePath: '/{page}', _controller: 'Event::list', _arguments: {'page': '@widget_0/currentPage'} }
  - { routePath: '/{event_title}', _controller: 'Event::show', _arguments: {'event_title': 'item'} }
  defaultController: 'Event::list'
  defaults:
    page: '0'
  requirements:
    page: '\d+'
    event_title: '^[a-zA-Z0-9]'
  aspects:
    page:
      type: StaticRangeMapper
      start: '1'
      end: '100'
    event_title:
      type: PersistedAliasMapper
      tableName: 'tx_supervendor_domain_model_event'
      routeFieldName: 'path_segment'

Проблема сейчас в том, что даже если я размещу эти плагины на разных страницах, они, похоже, конфликтуют. Поскольку ссылки нумерации страниц всегда занимают пространство имен первого плагина, который будет упомянут в config.yaml. Так что, если PoiPlugin упоминается первым, разбиение на страницы pois работает с параметром "page", а события - нет. Если я изменю порядок, события сработают, а яд не сработает. Мое предположение было, что база маршрутизации всегда страница, на которую вставляется плагин. Надеюсь, вы, ребята, понимаете, о чем я. Единственная конфигурация, которая работает сейчас, это когда я изменяю routePaths на

- { routePath: '/pois/{page}', _controller: 'POI::list', _arguments: {'page': '@widget_0/currentPage'} }

и

- { routePath: '/events/{page}', _controller: 'Event::list', _arguments: {'page': '@widget_0/currentPage'} }

И я понимаю, почему маршрутизатор должен иметь какую-то привязку для распознавания маршрута, который нужно выбрать. Но я не хочу сообщать авторам, что каждая страница, на которой размещен PoiPlugin, должна называться «Pois». Я не хочу ограничивать авторов тем, где и как использовать плагины, поэтому я не хочу использовать атрибут limitToPages или предопределенные префиксы маршрута. Так есть ли еще какая-нибудь возможность решить это?

ОБНОВЛЕНО: решение На данный момент я решил эту проблему, добавив префикс перед аргументом {page} в routePath. Кажется, что только виджет пагинации имел проблемы с моей конфигурацией, все остальное работает довольно хорошо. Например, список маршрутов теперь выглядит так:

- { routePath: '/e_{page}', _controller: 'Event::list', _arguments: {'page': '@widget_0/currentPage'} }
- { routePath: '/p_{page}', _controller: 'POI::list', _arguments: {'page': '@widget_0/currentPage'} }

1 Ответ

0 голосов
/ 09 ноября 2018

Возможно, добавьте дополнительное поле в плагин, который генерирует уникальный слаг (сегмент URL), например, на основе имени элемента контента плагина (требуется тогда), а затем поместите слаг перед маршрутом маршрута (например, перед страницей) , Я сам сейчас пытаюсь заставить маршрут виджета страницы работать правильно в routeEnhancer ..

Поскольку я разрешаю создание записей во внешнем интерфейсе, сгенерировать код (может быть, лучше), который я сейчас использую, выглядит как

protected function createUniqueTopicSlug(\Bla\Blacommunity\Domain\Model\Topic $topic)
{
    // Generate slug (URL segment)
    $subject = (string)$topic->getSubject();
    $trySlug = $this->slugHelper->sanitize(str_replace('/', '', $subject));

    // Make slug unique
    $existingSlugs = $this->topicRepository->countBySlug($trySlug);
    $slugCounter = 1;
    $slug = $trySlug;

    while ($existingSlugs > 0) {
        $slug = $trySlug . '-' . $slugCounter;
        $existingSlugs = $this->topicRepository->countBySlug($slug);
        $slugCounter++;
    }

    return $slug;
}

slugHelper происходит от TYPO3\CMS\Core\DataHandling\SlugHelper Вам нужно будет настроить его, чтобы проверить уникального слизняка. Я думаю, что для него тоже есть основная функция, но я не совсем понимаю, как использовать ее для пользовательского плагина, поэтому я написал свою собственную функцию, но, по крайней мере, я использую базовую функцию sanetize. Но это (я думаю) необходимо только при создании записей во внешнем интерфейсе, поскольку новый тип слагаемых TCA также может генерировать слагов.

...