Как я могу изменить схему маршрутизации Zend Framework, чтобы не использовать пары ключ / значение?

Question

Вместо того, чтобы использовать controller/action/key1/value1/key2/value2 в качестве моего URL, я бы хотел использовать controller/action/value1/value2. Я думаю, что я мог бы сделать это, определив собственный маршрут в своем классе Bootstrap, но я хочу, чтобы все мое приложение работало таким образом, поэтому о добавлении пользовательского маршрута для каждого действия не может быть и речи.

Возможно ли это? Если да, то как мне тогда получить доступ к valueN? Я хотел бы иметь возможность определить параметры в сигнатуре моего метода действия. e.x.:

 // PostsController.php

 public function view($postID) {
      echo 'post ID: ' . $postID;
 }

Я использую Zend Framework 1.9.3

Спасибо!

Answer 1

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

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

/controller/action/id/title/colour

или что они почти анонимны

/controller/action/value1/value2/value3

С кодом типа

$this->getRequest()->getParam('value2'); //fairly meaningless

Answer 2

Это должно быть N или вы можете сказать какое-то конечное значение? Например, можете ли вы представить, что вам никогда не понадобится больше, чем, скажем, 5 параметров? Если это так, вы можете настроить маршрут:

 /:controller/:action/:param0/:param1/:param2/:param3/:param4

Что будет работать, даже если вы не укажете все 5 параметров для каждого действия. Если вам когда-нибудь понадобится 6, вы можете просто добавить еще один /: paramN на маршрут.

Другое решение, с которым я работал ранее, - это написать плагин, который анализирует REQUEST_URI и помещает все дополнительные параметры в объект запроса в метод dispatchLoopStartup (). Мне больше нравится первый метод, так как он делает более очевидным, откуда поступают параметры.