Болт CMS: Добавление маршрутов для страниц в разделе «группировка» таксономию

Question

Моя умственная модель контента для веб-сайта я разрабатываю с Болт, что есть «подстраниц»:

• каждая страница (содержание тип) связан с одним «подстраницей»
• каждой «суб-страница» имеет свое собственное меню и может использовать свой собственный шаблон
• URL-адрес для страницы должна выглядеть/{sub_page_slug}/{page_slug}

В документах я нашел раздел о Taxonomies и это звучит для меня, как «группировка» таксономии - это то, что я хочу.

Поэтому я добавил следующее к моему taxonomy.yml:

pagegroups: 
    slug: pagegroups 
    singular_slug: pagegroup 
    behaves_like: grouping 
    options: { main, work, others } 

это с правильным добавлением в contenttype.yml позволяет мне назначить страницу «подстраницы» ака pagegroup. (Для того, чтобы быть в состоянии иметь дополнительную информацию для группы страниц, у меня также есть «pagegroup» тип содержимого, где пробковый Mathes записи в taxonomy.yml.)

Чтобы разрешить маршруты, как /others/stefan и /work/currently я добавил следующее routing.yml :

work_page_binding: 
    path: '/work/{slug}' 
    defaults: { _controller: 'Bolt\Controllers\Frontend::record', 'contenttypeslug': 'page' } 
    contenttype: pages 

others_page_binding: 
    path: '/others/{slug}' 
    defaults: { _controller: 'Bolt\Controllers\Frontend::record', 'contenttypeslug': 'page' } 
    contenttype: pages 

Но чтобы заставить его работать с шаблонами и меню всех страниц в группе страниц должны использовать правильный шаблон, поэтому получает отображается правильное меню.

Я предполагаю, что должен быть более динамичный способ для маршрутизации:

pagegroups_page_binding: 
    path: '/{pagegroup}/{slug}' 
    defaults: { [???] } 
    contenttype: pages 
    restrictions: 
     pagegroup: [???] 

, который имеет следующие преимущества:

• было бы проверить список настроенных групп страниц, так что единственное, для добавления - это запись в taxonomy.yml вместо новых маршрутов для каждой группы страниц (конечно, настройка элемента элемента содержимого группы страниц и меню для него все равно должно произойти)
• в шаблоне коррекция Элемент т содержания pagegroup установлен, так что я мог бы просто написать menu(pagegroup.slug) вместо того, чтобы дублировать шаблоны для каждой группы страниц

Может кто-нибудь подскажет, как начать работу с ним?
Я рад написать пользовательский контроллер, если это лучший способ. Если это так, где я должен это поставить?

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

Одна важная вещь, также: я хочу, чтобы иметь возможность обновить болт, так что я не хочу, чтобы изменить существующие классы ...

Он чувствует, как задавать более один вопрос, не стесняйтесь ответить на какой-либо части у вас есть идея.

Answer 1

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

Чтобы получить его работу сейчас, вы можете сделать статический метод, который возвращает трубы отделенной строку контентных групп, вот быстрый пример:

Первого в routing.yml:

contentgrouppage: 
    path: '/{contentgroup}/{slug}' 
    defaults: 
     _controller: 'controller.frontend:record' 
     contenttypeslug: page 
     contentgroup: '<put your default value here>' 
    requirements: 
     contentgroup: 'My\Routing::getTaxonomyGroups' 
    contenttype: page 

Как вы можете увидеть, мы задаем класс My \ Routing, и способ getTaxonomyGroups возвращает список допустимых значений, этот метод выглядит следующим образом:

use Bolt\Configuration\ResourceManager; 

    /** 
    * 
    */ 
    class Routing 
    { 

     public function getTaxonomyGroups() 
     { 
      $app = ResourceManager::getApp(); 
      $groups = $app['config']->get('taxonomy/categories'); 

      $urls = []; 
      foreach ($groups['options'] as $slug => $name) { 
       $urls[] = $slug; 
      } 


      return implode('|',$urls); 
     } 
    } 

Как вы можете видеть, Стати c hack, чтобы получить текущий объект приложения, не является идеальным и будет устаревать следующей версией, но проблема в том, что эти требования к маршрутизации в настоящее время должны быть статическими методами, тогда как в следующей версии вы сможете указать службу, например: controller.requirements