Neurons to bytes

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

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

Внимание! Читаем новую версию: Блоки в Zend Framework, версия 2

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

В общем, я сделал вот такой ini-файл blocks.ini, где разместил определение интересующих меня блоков:

; Отдельные блоки на сайте, которые маппятся на контроллеры

; Блок: меню администратора
[toolbar]
  module=application
  controller=toolbar
  action=index
  supportXhr=false

; Блок: еще один блок
 [someblock]
   module=something
   controller=something
   action=something
   supportXhr=false

Дальше я создал плагин фронт-контроллера, где подключил конфиг blocks.ini и совершил особую уличную магию (ничего сложного):

/**
 * Плагин для распределения блоков.
 *
 * Этот плагин позволяет загрузить различные контроллеры,
 * ответ которых потом можно вставить в layout в виде блоков.
 *
 * Конфиг блоков лежит в: config/blocks.ini
 */
class Tanraya_Controller_Plugin_Blocks extends Zend_Controller_Plugin_Abstract
{
    public function dispatchLoopStartup(Zend_Controller_Request_Abstract $request)
    {
        $actionStack = Zend_Controller_Front::getInstance()
        	->getPlugin('Zend_Controller_Plugin_ActionStack');

        // Получаем конфиги
        $path_to_app = Zend_Registry::get('path_to_app');
        $config      = Zend_Registry::get('config');

        // Получаем конфиг блоков
        $blocksConfig = new Zend_Config_Ini("{$path_to_app}/{$config->paths->blocks_config}");

        // Пробегаемся по всем перечисленным в конфиге блокам
        // и создаем новые объекты запроса для каждого блока, затем кладем
        // объекты запроса в стек
    	foreach ($blocksConfig->toArray() as $blockName=>$blockOptions)
    	{
    		// Поддерживать Xhr запросы для данного блока?
    		// Если supportXhr == false, то контроллер для блока не будет запущен
    		if ($blockOptions['supportXhr'] === true && $request->isXmlHttpRequest() === false)
    		{
    			continue;
    		}

            $r = clone $request;
            $r->setModuleName($blockOptions['module'])
              ->setControllerName($blockOptions['controller'])
              ->setActionName($blockOptions['action']);

            $actionStack->pushStack($r);
    	}
    }
}

Из кода должно быть все понятно, тем более тем, кто следил за серией постов. Параметр supportXhr нужен для того, чтобы не показывать блок, если происходит AJAX-запрос.

И, как обычно, подключаем наш плагин к фронт-контроллеру:

$this->front->registerPlugin(new Project_Controller_Plugin_Blocks());

Как работает, надеюсь понятно - в конфиге мы просто указываем, какой контроллер и действие из какого модуля загружать. Принцип действия такой же, как и в заметке Меню администратора, или блоки в Zend Framework. Кто еще не читал - резко читаем.

Засим откланяюсь, господа.

Also interesting

• Блоки в Zend Framework. Финальная версия.
• Меню администратора, или блоки в Zend Framework.
• How to work comfortably with layout blocks in Zend Framework
• Обновление кода к статье “Блоки в Zend Framework”
• Блоки в Zend Framework, версия 2

Tags: plugins, zend framework, zf front controller plugin, Блоки в ZF

This entry was posted on Понедельник, Июль 20th, 2009 at 16:09 and is filed under программерское. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.