изменение действия zend Framework по умолчанию на основе контроллера

#php #zend-framework

#php #zend-framework

Вопрос:

Итак, я знаю, что вы можете установить пользовательское действие по умолчанию в Zend Framework в application.ini :

 resources.frontController.defaultAction = "something"
 

Но что, если я хочу, чтобы это действие по умолчанию зависело от контроллера? Итак, действие контроллера A по умолчанию будет B , действие контроллера по C умолчанию будет D и т. Д. Как мне настроить контроллеры для выполнения этих параметров действия по умолчанию? Какой фрагмент кода необходим и где я должен их разместить?

Ответ №1:

Вы можете добавить в свой Bootstrap.php что — то вроде этого:

    protected function _initRoutes()
   {
      $Router = Zend_Controller_Front::getInstance()->getRouter();

      $Route = new Zend_Controller_Router_Route(
                      '/controller1',
                      array(
                          'action' => 'customaction1'
                      )
      );
      $Router->addRoute('c1', $Route);

      $Route = new Zend_Controller_Router_Route(
                      '/controller2',
                      array(
                          'action' => 'customaction2'
                      )
      );
      $Router->addRoute('c2', $Route);

      [...]
   }
 

Комментарии:

1. хм, должен ли я поместить это в контроллер?

2. @kamikaze_pilot Нет. Как я уже сказал, вы должны добавить в Boostrap.

3. Ваша функция инициализации не показывает доступ к Zend_Controller_Router_Rewrite , $Router только null здесь . Кроме того, создание маршрутов и их внедрение более уместно во время отправки, например, в плагине FrontController во routeStartup время. В противном случае вам нужно сначала загрузить FrontController и оттуда захватить маршрутизатор.

4. @JurianSluiman Вау, понижающий голос только за небольшую ошибку, в которой, во всяком случае, понятна логика. Спасибо.

5. @AurelioDeRosa это нечто большее: #1 $ Router не был инициализирован #2 Сначала вы зависите от начальной загрузки frontcontroller (что сейчас все еще имеет место и является очень плохой практикой) #3 вы не загружаете сначала frontcontroller (см. Также # 2) и # 4работа с подобными маршрутами действительно должна выполняться в плагине frontcontroller, если вы не можете просто использовать ресурс routes в application.ini.

Ответ №2:

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

 public function indexAction() {
  $this->_forward('mydefault');
}

public function mydefaultAction() {
  $this->view->message = 'I get called on /controller/index';
}
 

Я ПРЕДПОЛАГАЮ, что этот подход быстрее, чем добавление десятков пользовательских маршрутов. Но это всего лишь предположение, здесь ничего не проверялось.

Комментарии:

1. Не быстрее, потому что ваше приложение будет отправлено дважды.

2. Спасибо, что прояснили это! Теперь я знаю, что должен это изменить 🙂

Ответ №3:

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

Существует маршрут по умолчанию, который вы, вероятно, используете в своем приложении прямо сейчас. Вы можете добавить дополнительные маршруты из application.ini или иным образом создать плагин FrontController для ввода маршрутов в маршрутизатор. Первое намного проще, второе дает вам больше возможностей, например, загружать маршруты на основе записей в базе данных.

Маршруты в application.ini хорошо объяснены в руководстве ZF. Это сводится к этим четырем строкам на маршрут:

 resources.router.routes.route_id.route = "/login"
resources.router.routes.route_id.defaults.module = "user"
resources.router.routes.route_id.defaults.controller = "login"
resources.router.routes.route_id.defaults.action = "index"
 

Здесь можно указать действие по умолчанию с помощью defaults.action . Для параметров в маршрутах раздел о типе Zend_Controller_Router_Route объясняет это довольно хорошо.

Другой вариант — плагин FrontController. Этот класс может подключаться к различным частям процесса, и эта система очень мощная, если ее правильно использовать. Вероятно, это не требуется для вашего вопроса, но вы можете захотеть взглянуть на руководство, где есть страница о плагинах и раздел, как загрузить эти плагины в вашем application.ini.

Комментарии:

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

2. Пожалуйста, не принимайте это близко к сердцу и не отклоняйте меня только потому, что вам «не нравится» мой ответ. Это рабочий и приемлемый ответ, и я даю два варианта на выбор. Маршруты в application.ini для большинства простых приложений являются действительно хорошим решением. Если вы не предпочитаете маршруты в application.ini, я предлагаю использовать плагин frontcontroller. Эти два варианта охватывают любой тип варианта использования, обычно используются большинством разработчиков ZF и не вызовут никаких проблем, если вы захотите провести рефакторинг своего кода позже.

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