Другая схема URL для Zend Framework

Question

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

Возможный URL-адрес - www.example.com/our-team/developers/chris/, который в древовидной структуре будет отображаться в узел chris, дочерний элемент разработчиков, который, в свою очередь, является дочерним по отношению к команде.

Все это работает и работает благодаря чудесно реализованному поведению Nested Set в доктрине. Единственное, что я изо всех сил пытаюсь заставить его работать в передней части нашего сайта. По умолчанию объект запроса Zend Framework ожидает URI-схему контроллера / действия / ключа / значения / ключа / значения / ..., но это не совсем соответствует моим потребностям, я хотел бы пропустить весь контроллер, действие и часть ключа и ограничиться ценности. Что-то вроде value1 / value2 / value3 / value4 /...

У кого-нибудь есть идеи, как этого добиться?

Редактировать: Еще немного фона: Вы, наверное, удивляетесь, как я отображаю запрос на контроллер / действие? Хорошо, каждый запрос, который не диспетчеризуется (таким образом, не является существующим контроллером / действием), обрабатывается контроллером ошибок, именно там я сопоставляю URI запроса с путем в древовидной структуре и, таким образом, могу отображать страницу. (если путь совпадает), если он не совпадает, контроллер ошибок просто продолжает работу и выдается ответ 404.

Answer 1

Я выполнил маршрутизацию, расширив класс Zend_Controller_Router_Route_Abstract.

Добавив его в стек маршрутизатора, можно использовать систему «водопада», использующую множество маршрутов.

Я опубликовал код в моем блоге, и он работает как Bittarman .

Answer 2

Этот вариант использования отображает до controller/action/value, что похоже на стандартный шаблон. Используйте что-то вроде :controller/:action/:username при определении собственного маршрута.

См. Использование маршрутизатора в руководстве по ZF.

Answer 3

Во-первых, я бы прекратил использовать контроллер ошибок для обеспечения маршрутизации. Это просто плохое дзю-жу.

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

учитывая информацию, которую вы предоставили здесь, я бы посоветовал вам создать подкласс класса маршрута и выполнить (кэшированный) поиск в вашей базе данных, вернуть оттуда правильный модуль / контроллер / действие и сразу перейти к правильному Действие в первую очередь.

Затем вы также можете передать соответствующие данные в параметрах запроса (содержание страницы, данные о члене команды и т. Д.), Чтобы в вашем действии не требовался дальнейший просмотр БД, а также код действия, если он свободен от поиска.