Zend Framework: дорабатываем Zend_View

Powered By Zend Framework

Что-то давно я не писал о PHP, пора это исправлять. Сегодня буду рассказывать о Zend Framework’е – какой он классный, но не всегда удобный.

Итак первым попадает под раздачу Zend_View – простой шаблонизатор, очень похож на ряд велосипедов включая мой: HSTamplate, Прощай Smarty или простой шаблонизатор, Шаблонизировать за 6 секунд (и 6 строк) .

Перечислю все же его преимущества и недостатки…

Плюсы:

  • родной php, во всей своей силе и красе, и никакого языка шаблонов
  • наличие вспомогательных функций для генерации HTML
  • наличие фильтров вывода
  • легкость изучения (даже для дизайнера)
  • хорошая документация

Минусы:

  • отсутствие функции аналогичной fetch в Smarty (полезная функция все-таки)
  • нельзя предустановить используемый шаблон, т.е. нельзя сказать вначале скрипта – используем шаблон A.tpl, указание какой шаблон использовать должно быть только при вызове метода renderer (вот такой я капризный)
  • нет встроенных функций для кэширования шаблонов, необходимо каждый раз вспоминать о Zend_Cache
  • и всё…

Доработка:

Если кто не знает, я один из инициаторов появления на свет CMF/CMS системы под названием phpXCore, эта система базировалась на PEAR пакетах и использовала Smarty в качестве Template Engine. И вот, так как PHP4 решил почить с миром, я и моя команда решили таки переписать phpXCore под PHP5. И взяли мы за основу Zend Framework, и начали внедрять Zend_View, но перед этим мне пришлось его чутка доработать:

  • Первые два “минуса” довольно легко исправить, у нас появляется метод для установки шаблона, и еще два метода fetch и display
  • C Zend_Cache чутка придется повозиться, но зато насколько удобно стало использование кэша:
    	// проверка попадания в кэш
    	 if (!$View->cache($UNIQUE_ID, 3600)) {
    		// кэш недоступен, и надо заполнить объект Zend_View данными
    		 $View->test = __METHOD__ . '#' . date('H:i:s');
    	 }
    	// указываем шаблон вывода
    	 $View->setTemplate('test.tpl');
    	
  • Еще одна доработка – это реализация патерна композит, насчет данной доработки – я не совсем уверен в её универсальности, т.к. назначение данного улучшения – удовлетворить потребности нашей системы:
    	// создаем потомка
    	 $ViewChild = $View->addChild('Child1');
    	 $ViewChild -> test = __FILE__.'#'.__LINE__;
    	 $ViewChild -> setTemplate('child.tpl'); 
    	
    	// вывод потомка
    	<?=$this->displayChild('Child1'); ?>
    
    	// вывод потомка с передачей параметров
    	<?=$this->displayChild('Child1', array('id'=>$id, 'error'=>$error)); ?>
    	

    Чтобы понять зачем нам понадобился композит необходимо понять организацию вывода в phpXCore:

    • Существует основной шаблон, который может изменяться в зависимости от настроек, это некий index.tpl, он определяет расположение вывода модулей на странице:

      phpXCore view

    • Index.tpl настраивает активный контроллер в системе, т.е. это наш главный экземпляр Zend_View
    • Модули сами настраивают свой вывод, т.е. они оперируют со своим собственным Zend_View (которые являются дочерними относительно главного), они могут устанавливать свои настройки кэширования, что даёт достаточно большую гибкость (в нашем примере вы можете безболезненно выставить кэширование для меню, не затрагивая динамический контент)

Доработанный Zend_View можно посмотреть тут: http://svn.nixsolutions.com/xcore/application/classes/XCore/View.php ( login: anonymous, password: anonymous), узнать больше о разрабатываемой системе можно тут: http://www.phpxcore.org/wiki/index.php/Phpxcore:php5:architecture

10 thoughts on “Zend Framework: дорабатываем Zend_View”

  1. И всё?!!

    А как же layout? А как же выделение в подшаблоны и вызов их с параметрами?

    Посмотрите на View того же CakePHP. Сделайте на нём хотя-бы один проект. Потом без подобного функционала жить будет тяжко.

  2. Антон, а зачем подтягивать кэширование в шаблонизатор?

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

  4. Что то не видно обновления движка? Последнее в декабре, но там нет ZF

  5. @Igor:
    Вы наверное смотрите на старую версию под PHP4, новая версия доступна только в SVN’е – параметры доступа указаны в wiki

  6. предустановить используемый шаблон можно через финт. например из некоего контроллера вызываем

    		//-----------------
    		//отключаем вью рендерер
    		$front = Zend_Controller_Front::getInstance();
    		$front->setParam('noViewRenderer', true);
    		
    //подсовываем новый вью
    		$view = new Zend_View();
    
    		$path = realpath(__FILE__."/../../views/scripts/");
    		$view->setScriptPath($path);
    //генерим вывод		
    		echo $view->render('test/test.tpl');
    		//-----------------
    
  7. нельзя предустановить используемый шаблон, т.е. нельзя сказать вначале скрипта – используем шаблон A.tpl, указание какой шаблон использовать должно быть только при вызове метода renderer (вот такой я капризный)

    )))))))) а можно еще проще, нашел 5 минут назад)))
    в контроллере, где нужно изменить вью скрипт:
    при условии, что скрипт лежит рядом с тем что по умолчанию index.phtml например

    $this->_helper->viewRenderer("test")

    или:
    если лежит в другой директории, но в пути со скриптами видов

    $this->_helper->viewRenderer('some_dir/foo', null, true);

    метод render() как оказалось – просто рендерит и получает скрипт, потом его нужно выводить руками

Comments are closed.