На форуме Русскоязычного Zend Framework сообщества переводят на русский язык сообщения валидаторов. Начиная с версии 1.10 в Zend Framework появился механизм локализованных сообщений валидаторов об ошибках. Лидер команды интернализации Thomas Weidner предложил всем желающим помочь с переводом сообщений на родной язык. На это предложение откликнулись члены сообщества и уже проделали большой объем работы по переводу. Томас уже в курсе проделанной сообществом работы по локализации и, возможно, перевод попадет уже в следующий релиз (версии 1.10.2).

Если вы хорошо знаете русский язык и видите грамматические и прочие ошибки в тексте, Ваша помощь нужна сообществу. Это Ваш шанс поучаствовать в развитии фреймворка!

Вот ссылка на обсуждение перевода: Переводы на русский сообщений валидаторов. В этом топике есть вся необходимая информация.

Похожие записи

• Открыта регистрация на первую Российскую конференцию посвященную Zend Framework (0)
• Вышел ZendFramework 1.7.1 (0)
• Хитрости ZF1.8 (1)
• Создание повторно используемых плагинов ресурсов Zend_Application (0)
• Пользовательские ресурсы для Zend_Application (0)

Источник: Creating Re-Usable Zend_Application Resource Plugins
Автор: Matthew Weier O'Phinney
Перевод: Лобач Олег

В моей последней статье (Быстрый старт с Zend_Application_Bootstrap) я писал о том, как начать работу с Zend_Application, в том числе информацию о том, как писать методы ресурсов, а также список доступных плагинов ресурсов. Что произойдет, когда вам потребуется повторно используемый ресурс, для которого не поставляется готовый плагин? Ответ прост: напишите ваш собственный, конечно!

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

В этой статье давайте предположим, что вы хотите, чтобы ресурс плагина выполнял следующие действия:

• Установил DOCTYPE представления (View)
• Задал заголовок страницы и разделитель по умолчанию

Начало работы

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

Для целей данного упражнения, мы будем использовать префикс класса Phly_Resource, расположенного в Phly/Resource/ нашего include_path.

Назовем наш особый ресурс Layouthelpers, с полным названием класса Phly_Resource_Layouthelpers, и поместим его в Phly/Resource/Layouthelpers.php. Он должен реализовывать Zend_Application_Resource_Resource, но зачастую бывает проще расширить Zend_Application_Resource_ResourceAbstract. В обоих случаях необходимо определить метод init(). Давайте реализуем скелет нашего класса:

<?php
// Phly/Resource/Layouthelpers.php
//
class Phly_Resource_Layouthelpers
    extends Zend_Application_Resource_ResourceAbstract
{
    public function init()
    {
    }
}

Об отслеживании зависимостей

В моей предыдущей статье я показал пример отслеживания зависимостей в Zend_Application. Нам необходимо будет этим воспользоваться, так как обе наши задачи взаимодействуют с объектом представления, который мы будем извлекать с помощью ресурса View.

При создании методов ресурсов непосредственно в вашем загрузке, вы можете просто вызвать $this->getResource($name). Однако, в классе плагина ресурсов, необходимо сначала получить доступ к самому объекту начальной загрузки — с помощью метода getBootstrap().

Давайте убедимся в том, что ресурс представления инициализирован, и извлечем его.

<?php
// Phly/Resource/Layouthelpers.php
//
class Phly_Resource_Layouthelpers
    extends Zend_Application_Resource_ResourceAbstract
{
    public function init()
    {
        $bootstrap = $this->getBootstrap();
        $bootstrap->bootstrap('View');
        $view = $bootstrap->getResource('View');
        // ...
    }
}

Настройка ресурса

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

Во-первых, мы предоставим некоторые параметры по умолчанию через свойство $_options.

<?php
// Phly/Resource/Layouthelpers.php
//
class Phly_Resource_Layouthelpers
    extends Zend_Application_Resource_ResourceAbstract
{
    protected $_options = array(
        'doctype'         => 'XHTML1_STRICT',
        'title'           => 'Site Title',
        'title_separator' => ' :: ',
    );

    public function init()
    {
        $bootstrap = $this->getBootstrap();
        $bootstrap->bootstrap('View');
        $view = $bootstrap->getResource('View');
        // ...
    }
}

Затем мы можем получить параметры воспользовавшись методом getOptions().

<?php
// Phly/Resource/Layouthelpers.php
//
class Phly_Resource_Layouthelpers
    extends Zend_Application_Resource_ResourceAbstract
{
    protected $_options = array(
        'doctype'         => 'XHTML1_STRICT',
        'title'           => 'Site Title',
        'title_separator' => ' :: ',
    );

    public function init()
    {
        $bootstrap = $this->getBootstrap();
        $bootstrap->bootstrap('View');
        $view = $bootstrap->getResource('View');
        $options = $this->getOptions();
        // ...
    }
}

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

[production]
; ...
resources.layouthelpers.doctype = "HTML5"
resources.layouthelpers.title = "My Snazzy New Website"
resources.layouthelpers.title_separator = " &emdash; "

Выполняем некоторую работу

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

<?php
// Phly/Resource/Layouthelpers.php
//
class Phly_Resource_Layouthelpers
    extends Zend_Application_Resource_ResourceAbstract
{
    protected $_options = array(
        'doctype'         => 'XHTML1_STRICT',
        'title'           => 'Site Title',
        'title_separator' => ' :: ',
    );

    public function init()
    {
        $bootstrap = $this->getBootstrap();
        $bootstrap->bootstrap('View');
        $view = $bootstrap->getResource('View');

        $options = $this->getOptions();
        $view->doctype($options['doctype']);
        $view->headTitle()->setSeparator($options['title_separator'])
                          ->append($options['title']);
    }
}

Это все!

Расскажем загрузчику о нас

Ну, это все что нужно сделать для реализации плагина ресурса. Но как мы расскажем нашему классу загрузчика о нем? Через наш конфигурационный файл, используя ключ pluginPaths. Это массив, ключами которого являются префиксы классов плагинов, а значениями — путь, соответствующий префиксу.

[production]
; ...
pluginPaths.Phly_Resource = "Phly/Resource"
resources.layouthelpers.doctype = "HTML5"
resources.layouthelpers.title = "My Snazzy New Website"
resources.layouthelpers.title_separator = " &emdash; "

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

Дальнейшие соображения

Пример из этого поста тривиален. Но один аспект не был обсужден — создание ресурса, который будет использоваться повсюду в вашем приложении. Например, вы можете захотеть создать ресурс, который вы будете использовать в разное время в вашем приложении. Если вы возвращаете значение из вашего метода init(), объект начальной загрузки сохранит его для последующего извлечения. Хороший пример этого мы видели раньше: ресурс View зарегистрировал объект Zend_View в классе начальной загрузки просто возвратив экземпляр из плагина ресурса.

Выводы

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

Если у Вас есть дополнительные вопросы, вы можете найти меня в списке рассылки ZF, на IRC через серверы Freenode, или в Twitter. Удачи!

Похожие записи

• Пользовательские ресурсы для Zend_Application (0)
• Быстрый старт с Zend_Application_Bootstrap (0)
• Включение условных запросов в приложениях на Zend Framework (0)
• Zend_Tool и ZF 1.8 (3)
• Хитрости ZF1.8 (1)

В конце марта 2010 г. в Санкт-Петербурге пройдет первая в России конференция по Zend Framework. Сам я к сожалению поехать не смогу, но по просьбе организаторов конференции публикую анонс предстоящей конференции.

На днях закончился прием тезисов по планируемым докладам. Примечательно, что в состав докладчиков вошли ведущие участники русскоязычного сообщества ZF, опытнейшие специалисты и лично один из создателей фрэймворка!

Участие в конференции планируется сделать бесплатным или за небольшую стоимость. На данный момент уже открыта предварительная регистрация на конференцию! Для решения ряда вопросов организаторам очень важно сейчас понять приблизительное количество человек, которые смогут посетить конференцию или каким-то иным образом принять участие в ней.

Каждый предстоящий доклад возможно обсудить на форуме ZF-сообщества. Ваше мнение очень важно для авторов!

Планируемые доклады:

Жизненный цикл предложений (proposals) в проекте Zend Framework — Александр Веремьев (Zend Technologies, Zend Framework Core команда)

Zend_Search_Lucene в деталях — Александр Веремьев (Zend Technologies, Zend Framework Core команда)

Zend Framework и производительность — Александр Махомет (создатель сообщества ZendFramework.ru)

Zend Framework и MVC, «толстая» модель — Александр Стешенко (Norada Corporation, PHP-разработчик)

ФотоСтрана.ru: Прототипирование с использованием ZF (история боевого применения Zend Framework в highload-проекте) — Леонид Жаворонков (ФотоСтрана.ru, тимлид)

Использование очередей сообщений в повседневных проектах — Денис Баклыков (Обновление, веб-разработчик)

Zend Framework и Doctrine — Степан Танасийчук (руководитель веб-студии stfalcon.com)

Zend Framework и мультиязычность — Степан Танасийчук (руководитель веб-студии stfalcon.com)

История проекта e-Штаб — Анатолий Ларин (e-Легион, веб-программист)

Что нового несет нам Zend Framework 2.0? — Надежда Блинова (Wizartech, веб-программист), Георгий Туревич (Wizartech, ведущий веб-программист)

Интеграция Zend Framework c Javascript-фрэймворками jQuery и Dojo Toolkit — Георгий Туревич (Wizartech, ведущий веб-программист)

Смело обсуждайте доклады и регистрируйтесь!

За последними новостями можно следить здесь:

• RSS-канал: feeds.feedburner.com/zfconf
• Twitter: @zfconf
• Группа Вконтакте: vkontakte.ru/club14951507

К участию также приглашаются информационные и финансовые спонсоры.

Похожие записи

• Хитрости ZF1.8 (1)
• Создание повторно используемых плагинов ресурсов Zend_Application (0)
• Пользовательские ресурсы для Zend_Application (0)
• Перехватчики в помощниках действий (0)
• Комьюнити требуется помощь (1)

Источник: Quick Start to Zend_Application_Bootstrap
Автор: Matthew Weier O'Phinney
Перевод: Лобач Олег

Мы добавили Zend_Application в Zend Framework начиная с версии 1.8.0. Намерением, лежащим в основе компонента, была формализация процесса загрузки приложений, а также обеспечение упрощенного, основанного на файле конфигураций, механизма для него.

Zend_Application работает в связке с Zend_Application_Bootstrap, который, как можно догадаться из названия, является тем, что на самом деле выполняет большую часть работы по загрузке вашего приложения. Это позволяет вам использовать подключаемые ресурсы загрузчика, либо определить локальные ресурсы загрузчика как методы класса. Разработчик получает возможность повторного использования, а в последующем специфическую для приложения инициализацию и конфигурацию.

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

Как это работает

Теперь, когда вы знаете, что он делает, давайте окунемся в основы.

Если вы используете утилиту командной строки zf, предоставляемую Zend Framework для создания своих проектов ("zf create project"), вы получите загрузчик и настройки по умолчанию прямо «из коробки». Это включает в себя следующие файлы в файловой структуре:

Файл Bootstrap.php будет содержать класс Bootstrap, который расширяет Zend_Application_Bootstrap_Bootstrap; этот класс изначально будет пустой. Файл application.ini будет содержать следующее:

[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
appnamespace = "Application"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
resources.frontController.params.displayExceptions = 0

[staging : production]

[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.frontController.params.displayExceptions = 1

Zend_Application проходит в три этапа. Во-первых, оно инициализирует среду PHP, используя INI параметры вашей конфигурации, если они заданы, а также настройку include_path и автозагрузку. Во-вторых, оно инициализирует и выполняет класс начальной загрузки. Наконец, «выполняется» приложение (вызовом метода run () загрузчика).

Параметры конфигурации

Мы видим, что приведенный выше листинг представляет собой набор:

• Параметры инициализации PHP (в данном случае они свидетельствуют о том, следует ли отображать ошибки)
• Настройки include_path
• Настройки, которые указывают название и место нахождения класса начальной загрузки
• Настройки ресурсов приложения

Ключ phpSettings принимает любые ключи из php.ini как подразделы, и эти пары ключ/значение будут переданы ini_set. Это может быть полезно, когда вам нужно быть уверенным в том, что установлены особые INI параметры, особенно если вы хотите, чтобы они зависели от окружения. (В приведенном выше примере, display_errors включен в тестовом окружении и в окружении для разработки, но отключен в остальных)

Когда дело доходит до include_path и автозагрузки, вероятно, наиболее часто задаваемый вопрос: «Как я могу добавить в автозагрузчик префиксы пространств имен для кода, отличного от ZF?». Это можно легко сделать в конфигурационном файле, воспользовавшись ключом autoloaderNamespaces и префиксом пространства имен в качестве его значения:

autoloaderNamespaces[] = "Phly_"

Что касается класса загрузчика и местоположения файла, как правило, вариант по умолчанию будет наилучшим. Однако, если вы хотите задать пользовательское наименование — например, чтобы указать префикс класса — или, возможно, если ваш модуль по умолчанию находится в подкаталоге, вы можете уведомить Zend_Application об этом через настройки bootstrap.class и boostrap.path:

bootstrap.class = "Application_Bootstrap"
bootstrap.path = APPLICATION_PATH "/modules/application/Bootstrap.php"

Начало работы с ресурсами загрузчика

Теперь мы, наконец, займемся самым интересным: непосредственно ресурсами загрузчика.

Да, я знаю, что я умалчиваю о ключе «appnamespace»; я расскажу об этом в другое время.

Ресурсы загрузчика могут быть одной из двух вещей:

• Защищенный метод в классе начальной загрузки с префиксом «_init» (например, protected function _initFoo())
• Класс, реализующий Zend_Application_Resource_Resource_Resource

В первом случае, _init*() методы, каждый из них будет выполняться в каждом запросе. В последнем, будут выполнены только те, которые вы укажете в вашем конфигурационном файле, что позволяет вам выбирать, какие из различных поставляемых плагинов ресурсов (или написанных вами самим!) будут использованы.

В случае с конфигурацией по умолчанию, только плагин ресурса «frontController» будет использоваться, соответствуя Zend_Application_Resource_Frontcontroller. По состоянию на предстоящий релиз 1.10, вы можете выбрать один из следующих дополнительных плагинов ресурсов, таких как:

• Cachemanager
• Db
• Dojo
• Layout
• Locale
• Log
• Mail
• Modules
• Multidb
• Navigation
• Router
• Session
• Translate
• View

Каждый из них имеет собственные параметры конфигурации, описанные в руководстве.

Написание методов ресурсов

Написание ваших собственных методов ресурсов тривиально: вы просто создаете метод, и выполняете какую-то работу. Затем вы имеете возможность вернуть значение. Если вы это сделаете, оно будет храниться в загрузчике и вы сможете получить его позже. К примеру:

class Bootstrap
          extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initRegistry()
    {
        $registry = new Zend_Registry();
        return $registry;
    }
}

Если бы мы хотели получить реестр позже, мы могли бы сделать это, используя метод загрузчика getResource ():

$registry = $bootstrap->getResource('Registry');

Обратите внимание, что мы передаем имя метода без префикса «_init», это «краткое имя» показывает как ресурс упоминается в загрузчике, и как вы будете ссылаться на него позже.

Теперь, допустим, у вас есть ресурс, который зависит от вашего ресурса «Реестр». Например, вы хотите создать объект Zend_Currency и передать его в реестр. Zend_Application_Bootstrap был спроектирован для обработки этой ситуации, и включает в себя отслеживание зависимостей (это, на самом деле, истинная причина создания методов инициализации защищенными, что предотвращает их прямой вызов). Просто вызовите метод bootstrap() с названием ресурса для его инициализации. Кроме того, метод getResource () может быть использован для получения значений, зарегистрированных этим ресурсом. К примеру:

class Bootstrap
          extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initCurrency()
    {
        $this->bootstrap('Registry');
        $registry = $this->getResource('Registry');

        $currency = new Zend_Currency('$');
        $registry['Zend_Currency'] = $currency;
        return $currency;
    }
    protected function _initRegistry()
    {
        $registry = new Zend_Registry();
        return $registry;
    }
}

Вот что произойдет:

• Zend_Application вызовет bootstrap() без аргументов, который сначала перебирает внутренние методы ресурсов, а затем любые настраиваемые плагины ресурсов.
• этот загрузчик выполнит метод _initCurrency ()
• он встречает метод bootstrap() и выполняет его
• вызов bootstrap() выполняет метод _initRegistry (), сохраняя по завершению экземпляр Zend_Registry (который был возвращен из метода)
• выполнение _initCurrency () продолжается вызовом getResource (); он возвращает экземпляр Zend_Registry, хранящемуся в загрузчике по этому ключу.
• выполнение _initCurrency () завершается, и загрузчик сохраняет возвращенный экземпляр Zend_Currency.
• метод bootstrap() затем пытается вызвать метод _initRegistry (), но при этом отмечает, что он уже был выполнен, и поэтому переходит к выполнению плагинов ресурсов.

Как вы можете теперь видеть, загрузчик функционально достаточно гибкий и мощный, и предоставляет целый ряд преимуществ сразу «из коробки».

До следующей встречи ...

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

Похожие записи

• Создание повторно используемых плагинов ресурсов Zend_Application (0)
• Пользовательские ресурсы для Zend_Application (0)
• Zend_Tool и ZF 1.8 (3)
• Хитрости ZF1.8 (1)
• Перехватчики в помощниках действий (0)

Источник: Custom Zend_Application Resources
Автор: Rob Allen
Переводчик: Лобач Олег

Рано или поздно, вы захотите использовать Zend_Application эффективней при помощи создания собственных плагинов ресурсов. Это значительно упрощает и ускоряет начальную стадию разработки нового приложения за счет повторного использования однажды уже проделанной работы по инициализации окружения. К тому же это сделает ваш Boostrap-класс очень компактным!

В моем случае, я хотел создать ресурс для CouchDb, который проверял бы что база данных была создана, в противном случае создавал бы её.

Создание собственных плагинов достаточно просто. Очевидным местом для размещения будет library/App/Application/Resource и типичный ресурс будет выглядеть следующим образом:

class App_Application_Resource_Couchdb
            extends Zend_Application_Resource_ResourceAbstract
{
    /**
     * Defined by Zend_Application_Resource_Resource
     *
     * @return Phly_Couch|null
     */
    public function init()
    {
         // тут выполняются действия для инициализации CouchDb
        $options = $this->getOptions();
        // в $options находится все содержимое 'resources.couchdb' из application.ini
    }
}

Вы должны уведомить Zend_Application о ваших новых плагинах. Это делается посредством одной строчки в application.ini:

pluginPaths.App_Application_Resource_ = "App/Application/Resource"

Теперь вы можете иметь столько плагинов ресурсов, сколько вам захочется, располагая их в пространстве App_Application_Resource_.

Кроме того, Matthew Weier O'Phinney написал статью о Zend_Application, которую вам обязательно стоит прочесть.

Похожие записи

• Создание повторно используемых плагинов ресурсов Zend_Application (0)
• Хитрости ZF1.8 (1)
• Быстрый старт с Zend_Application_Bootstrap (0)
• Zend_Tool и ZF 1.8 (3)
• Перехватчики в помощниках действий (0)

После полугодового перерыва я решил вернуться к публикациям постов в этом блоге. Основной причиной такого затишья было отсутствие свободного времени из-за разработки достаточно трудозатратного проекта параллельно основной работе. И хотя сейчас времени все ещё немного, я собираюсь часть его снова посвятить ведению блога. Накопилось некоторое количество материала, которым я хотел бы поделиться с моими читателями.

В ближайших планах:

• перевод заметки о плагинах ресурсов для Zend_Application
• перевод статьи, рассказывающей об использовании Zend_Application
• публикация фильтра для Zend_Filter_File
• и, надеюсь, я дозрею до смены дефолтного шаблона на что-то иное ;)

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

P.S.: Поздравляю всех с наступившим Новым Годом и Рождеством.

Похожие записи

• Нет похожих записей

Этот пост я хочу посвятить решению одной проблемы, которая доставила мне массу проблем. Хотя, если говорить о неприятностях, то они скорее были не у меня, а у пользователей проекта, в котором я участвую¹.

Проблема заключалась в том, что пользователи не могли сохранить на сервере данные, если они превышали определённый объём. При чем, не могли сохранить на столько, что отправляли апач в «кору». Честно говоря, это сильно раздражало, потому что происходило буквально на ровном месте.

В конце концов такая ситуация надоела и я по локоть залез своими шаловливыми ручонками вглубь Zend_Db. Предположения о вероятной причине у нас были и это несколько облегчило задачу. Падения могли происходить из-за того, что регулярка уходила в глубокую рекурсию и там умирала. Эту гипотезу я и стал проверять. Почему я полез именно в Zend_Db? Очень просто — поиск причины показал, что скрипт умирает именно там.

И оказалось таки да — Zend_Db при создании экземпляра стэйтмента регуляркой вырезал все экранирующие символы. Если при этом тест запроса был достаточно объемным, то весь процесс завершался падением.

Вот так наш код выглядел ранее (естественно, код крайне упрощен):

$sql = "INSERT INTO tab (id,name)
             VALUES (null,'очень ... длинный ... текст')";
$db->query($sql); // $db - экземпляр Zend_Db_Adapter_Mysqli

Пытливый ум некоторый читателей моего блога может зародить разумную мысль: «А зачем, собственно, писать текст запроса целиком, если есть методы и для вставки, и для выборки?». И, таки да, будет в чем-то прав. Но! К сожалению, Zend_Db реализует не все возможности SQL и иногда приходится идти на крайние меры и писать запросы явно.

Вернемся к проблеме. Покрутив и так, и эдак, я решил пойти по пути наименьшего сопротивления. А именно, воспользоваться плейсхолдерами. Теперь код стал выглядеть так:

$sql = "INSERT INTO tab (id,name)
             VALUES (null, ?)";
$name = 'очень ... длинный ... текст'; // значение поступает от пользователя
$db->query($sql, array($name)); // $db - экземпляр Zend_Db_Adapter_Mysqli

Это изменение полностью решило данную проблему. Ура!

Пытливый читатель может опять спросить: «А чего же не вы не воспользовались плейсхолдерами сразу?!». И будет снова прав! Надо было поступать именно так. Но богомерзкое желание сохранить пару тактов процессора сделало свое грязное дело и мы нашли приключения на свой зад проблемы на свою голову.

Мораль сей басни такова: пользуйтесь плейсхолдерами и ваши волосы будут мягкими и шелковистыми!

P.S.: Я надеюсь, что после прочтения этого поста у вас не сложилось впечатление, что мы запросы к базе пишем исключительно текстом. Спешу развеять это впечатление: поиск по нашему (очень не маленькому) проекту выявил всего 4 или 5 таких мест. Код исправлен, виновные понесли заслуженное поощрение.

Постовой:

Если Вам нужен эвакуатор, то заказать его можете тут: эвакуатор в Москве. А если хочется экзотики, то можете съездить на отдых в Японии

Похожие записи

• Хитрости ZF1.8 (1)
• Создание повторно используемых плагинов ресурсов Zend_Application (0)
• Пользовательские ресурсы для Zend_Application (0)
• Перехватчики в помощниках действий (0)
• Открыта регистрация на первую Российскую конференцию посвященную Zend Framework (0)

Источник: Zend_Tool and ZF 1.8
Автор: Ralph Schindler
Переводчик: Лобач Олег

Вы уже наверняка слышали новость о выпуске Zend Framework 1.8. Вместе с ZF 1.8 в наше распоряжение поступило несколько новых инструментов, таких как Zend_Tool (это мой любимчик), Zend_Application, Zend_Navigation и Zend_Tag_Cloud. Zend_Tool не является компонентом в обычном понимании. Большинство компонентов имеют класс на верхнем уровне пространства имен, а Zend_Tool нет. Большинство компонентов обычно используется внутри кода вашего приложения для упрощения выполнения задач, а Zend_Tool нет. Zend_Tool более близок к фреймворку, нежели к компоненту — этакий фреймворк в фреймворке.

Так что же такое Zend_Tool?

Первый шаг — приступить к изучению того, что нужно предпринять для разработки следующего поколения фреймворка для RAD¹. RAD, как вы можете себе представить, это термин, имеющий довольно широкое определение. В общем смысле, этот термин обозначает скорость, с которой вы можете создать ресурсы, требуемые вашему приложению. В идеальной ситуации, начальная разработка (или подготовительная фаза проекта²) должна быть сведена к минимуму с тем, чтобы разработчики могли приступить к более интересной разработке. В конце концов, «интересная разработка» является наиболее вероятной причиной рождения приложения.

Итак, если есть «интересная разработка», что же такое «неинтересная разработка»? Для Zend Framework (и большинства MVC-фреймворков, если уж на то пошло) это процесс создания начальных ресурсов проекта, общих для всех проектов: первичная структура проекта, первичные файлы конфигурации, первичный загрузочный код и код автозагрузки, и т.п. Это так же включает задачи обработки ошибок, создания контроллеров и представлений и многое другое. Для кого-то, кто только начинает увлекаться ZF, некоторые из этих задач потребуют часы чтения учебников, руководств и материалов типа «быстрый старт». Не слишком «быстро», не так ли?

Zend_Tool как фреймворк

Вместо тесного связывания системы, которая была бы специально нацелена на создание ZF-приложений непосредственно из командной строки, и точной генерации кода, без модификации существующего кода, мы заложили в архитектуру системы расширяемость в местах, которые должны касаться разработчика. Zend_Tool был разработан для облегчения абстракции во всех необходимых местах, которые мы посчитали удобными разработчикам для расширения системы. Например, у нас пока основной клиент — CLI³, но фреймворк разработан как универсальная RPC-система, с тем, чтобы разрабатывать другие, не-CLI, клиенты. Хотя у нас уже есть запас провайдеров (базовые возможности системы), интерфейсы для построения провайдеров в будущем остается простым и удобным для расширения и понимания.

Zend_CodeGenerator и Zend_Reflection

В ходе разработки, мы обнаружили несколько проблемных областей, которые не имели единодушного решения. Генерация кода — одна из таких областей. Вообще говоря, когда Вы говорите о генерации кода, это обычно подход, основанный на шаблонах — генерируемый код поступает из файлов шаблонов, которые обычно написаны без учета правильно ли они сформированы⁴ (в соответствии со стандартами языка). Имея подход, основанный на шаблонах, включает риск того, что разработчики выйдут за рамки стандартов кодирования и будут генерировать вообще плохой код (плохой код в этом смысле — это и неработающий код, и плохо сформированный код). Итак, мы сразу поняли, что существует возможность создать компонент, который будет обеспечивать объектно-ориентированный интерфейс, аналогичный Reflection API в PHP, с единственной целью — создание хорошо сформированного и хорошо отформатированного объектно-ориентированного кода. Следует отметить, что компонент Zend_CodeGenerator может быть использован без остальной части Zend_Tool. Это означает, что если вы когда-нибудь окажетесь в положении, когда нужно постоянно генерировать код, в первую очередь вы должны посмотреть в сторону Zend_CodeGenerator.

Zend_CodeGenerator не просто пишет код с нуля; у него есть возможность чтения существующего кода, изменения его, и создания нового кода. Это главным образом связано с другим компонентом — Zend_Reflection, рожденным вне Zend_Tool. Zend_Reflection — это не, и я это особо подчеркну, переизобретение колеса. Фактически, он расширяет Reflection API, добавляя поддержку пользовательских расширений, отражений Dockbloc (и в том числе тэгов dockbloc), и основанных на файлах отражений. Семантика компонента такая же, как у прародителя, и он может использоваться в качестве замены базовых классов в случае необходимости в дополнительных возможностях.

Zend_CodeGenerator и Zend_Reflection имеют схожие API: Zend_Reflection нацелен на чтение структур кода, а Zend_CodeGenerator нацелен на написание структур кода. Вместе эти два компонента облегчают исследование и написание кода во время процесса развития приложения.

Клиент командной строки Zend_Tool

Само собой разумеется, что RAD, основанный на интерфейсе командной строки, очень востребован у ZF-разработчиков. Как упомянуто ранее, задача настраивания начальных ресурсов проекта может быть утомительной. Многие разработчики предпочитают взаимодействовать со средой разработки через терминал, или командную строку, так что, естественно, мы решили, что наиболее целесообразно встроить клиента в Zend_Tool. Это не означает, что может быть только один клиент — как упомянуто ранее, клиентские функциональные возможности Zend_Tool были абстрагированы таким образом, что дополнительные клиенты могут быть построены так, чтобы взаимодействовать с Zend_Tool. У интегрированных сред разработки и редакторов текста есть возможность встроиться в клиентский фреймворк и подавать команды посредством их родного интерфейса. Два вероятных расширения включают два моих любимых инструмента: Zend Studio и Textmate — но возможности почти безграничны. Любой клиент, который способен выполнять PHP-код, может эффективно надстроиться поверх Zend_Tool для нужд инструментов.

Zend_Tool_Project

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

Zend_Tool_Project намеревается решать эту проблему. Zend_Tool_Project это набор функциональности выстроенной для работы с Zend_Tool_Framework, чтобы предоставить решение проблемы управления проектами. Zend_Tool_Project отслеживает ресурсы внутри вашего приложения, где они находятся по отношению друг к другу, и названия, которыми вы обращаетесь к ним, что является ключевым моментом, который дает возможность «итерационную разработку». Например, если вы имеете созданный проект с контроллером, названным «Foo», вы можете позже захотеть добавить действие в этот контроллер. Чтобы сделать разработку настолько гладкой, на сколько возможно, изменение должно быть таким же простым, как создание новых ресурсов. Чтобы сделать это, Zend_Tool_Project отслеживает все, что вы уже сделали в вашем проекте.

Помимо отслеживания ресурсов приложения, Zend_Tool_Project является ключевой частью Zend_Tool, которая обеспечивает решение «построение проекта, основанного на Zend Framework». Zend_Tool_Project точно знает, что такое проект, контроллер, представление, загрузочный класс, файл index.php, и т.д., как должны выглядеть, и помогает вам в их создании. Если вы извлечете Zend_Tool_Project из среды выполнения Zend_Tool, у вас останется только фреймворк (или платформа) для построения инструментальной системы. Это говорит о том, что любой проект может использовать Zend_Tool_Framework для создания инструментов, обеспечивающих их нужды.

На что оно способно сейчас

Итак, имеем в виду все вышесказанное. Что оно может сделать прямо сейчас? Вместо того чтобы говорить об этом, давайте посмотрим несколько скриншотов.

Помощь

Ошибка

Создание проекта

Создание контроллера

Создание действия

Что дальше

В дополнение к тому, что уже сделано в релизе 1.8, ряд дополнительных возможностей уже в процессе разработки. Некоторые из этих возможностей уже в статусе бета-версии (и это причина, почему они не в дистрибутиве релиза), или все еще в фазе проектирования. К примеру, Zend_Application — мы приняли решение о том, как «модель» должна выглядеть, пусть даже всего лишь мы говорим о названии. Так же, с релизом 1.8 мы опубликовали структуру проекта по-умолчанию. Для проекта, основой которого является «библиотека компонентов», это огромный шаг.

В дополнение к поддержке моделей, мы планируем добавить поддержку «моделей» (для построения компонентных приложений), соединений с базой данных и генерацию файлов Zend_Db_Table. Ищите эти возможности в ближайших релизах. Кроме того, поскольку Zend_Tool так расширяем, новые возможности могут быть вынесены за пределы проектов, внедряемых непосредственно в модуль Zend_Tool.

Похожие записи

• Пользовательские ресурсы для Zend_Application (0)
• Создание повторно используемых плагинов ресурсов Zend_Application (0)
• Быстрый старт с Zend_Application_Bootstrap (0)
• Хитрости ZF1.8 (1)
• Перехватчики в помощниках действий (0)

В комментариях к учебнику в блоге Роба Алена (кстати, он его уже обновил до последней текущей версии ZF — 1.8) задают вопрос:

Как в новой версии фреймворка применять конфигурационный файл?
Раньше вопрошающий устанавливал переменную в своем конфигурационном файле:
cms.max.feeds = 10

А в загрузочном файле писал следующее:

$configuration = new Zend_Config_Ini(
    APPLICATION_PATH . '/config/app.ini',
    APPLICATION_ENVIRONMENT
);
$registry = Zend_Registry::getInstance();
$registry->configuration = $configuration;

Соответственно в контроллере получал значение следующим образом:

$this->_nMaxFeeds = INTVAL(Zend_Registry::getInstance()
             ->configuration
             ->cms
             ->max
             ->feeds);

Комментатор жалуется, что теперь он не знает как получить подобную функциональность в ZF1.8¹

Роб ответил:

В контроллере можно сделать так:

$bootstrap = $this->getInvokeArg('bootstrap');
$configArray = $bootstrap->getOptions();

А если нужен экземпляр объекта _Zend_Config_, то надо добавить строчку:

$config = new Zend_Config($configArray);

Такая вот маленькая хитрость, которая наверняка может сохранить массу времени при переходе на новый релиз.

Кстати1: из этой заметки наверняка понятно, что вышел новый релиз ZF, но если кто еще не знает рекомендую ознакомиться с переводом анонса релиза ZF1.8 — Вышел Zend Framework 1.8.0

Кстати2: Рекомендую ознакомиться с учебником Роба, чтобы иметь представление о применении консоли ZF, если кто еще не пробовал её в работе.

Upd: Там же в комментариях Роб предложил универсальное решение в «старом» стиле:

class Bootstrap extends Zend_Application_Bootstrap_Base
{
   public function run()
   {
       Zend_Registry::set('config',
           new Zend_Config($this->getOptions()));
       parent::run();
   }
}

В этом случае объект конфига будет доступен в любом месте приложения.

Похожие записи

• Пользовательские ресурсы для Zend_Application (0)
• Создание повторно используемых плагинов ресурсов Zend_Application (0)
• Использование Zend_Application (0)
• Быстрый старт с Zend_Application_Bootstrap (0)
• Zend_Tool и ZF 1.8 (3)

Больше года назад я уже писал о примере реализации скроллера на jQuery. Смысл скроллера состоял в том, что нужно было сделать «бесконечную» ленту неких объектов и отображать в их в небольшом окошке, в котором эта лента как-бы прокручивается. Реализация получилась вполне работоспособная, хоть и не без недостатков.

А совсем недавно мне снова потребовался скроллер, но горизонтальный и управляемый пользователем (в отличии от предыдущего вертикального и автоскролируемого). Изобретать велосипед снова мне было лениво и я решил проверить, есть ли плагины для jQuery с нужным мне функционалом. Перепробовал я массу разных плагинов (упоминать о них смысла нет) пока не набрел на настоящую жемчужину! Идеальный для моей задачи плагин — Scrollable (страница в каталоге и домашняя страница).

Плагин совершенно замечательный — масса возможностей, прост в использовании, понятные примеры, приятный код.

Фичи:

• горизонтальный и вертикальный скролинг
• скролинг при помощи навигационных кнопок, вызовов API, курсорных клавиш на клавиатуре и колесом прокрутки на мыше
• настраиваемое количество элементов скролируемых за раз
• настраивание навигационных кнопок без единой строчки JavaScript
• постраничное скролирование
• действия, вызываемые программно: next, prev, nextPage, prevPage, seekTo, begin, end ...
• динамическое добавление и удаление элементов
• автоматически скролинг
• возможность настроить поведение скролинга с помощью листенеров onBeforeSeek и onSeek
• размер минимизированного файла около 6.0K

Применил я этот плагин для организации вывода постраничной навигации. На мой взгляд получилось достаточно удобно — легко можно добраться до любой страницы. Правда у этого способа тоже есть недостаток — если страниц уж очень много, то это становится неудобно для пользователя и тяжеловато для браузера. Мы решили ограничиться 100 страницами, а остальные просо отбрасываем.

Была у мне с этим плагином одна непонятка: не срабатывали вызовы API. Моя логика (основываясь на курении доки) подсказывала такой способ вызова:

var api = $("div.scrollable").scrollable();
api.click(10); // для перехода к десятому элементу

Но этот код работать не захотел. Пришлось извратиться так:

$("div.scrollable").scrollable();
$("div.scrollable").scrollable().click(10);

Если кто-нибудь подскажет более красивое решение или объяснит где я неправ в своих хотелках — буду очень признателен.

Еще статьи об этом плагине:

• Скроллер содержимого на jQuery
• Навигация с использованием jQuery

Похожие записи

• Пример создания SlideUp скроллера с помощью jQuery (8)
• Создание повторно используемых плагинов ресурсов Zend_Application (0)
• Как сделать ajax-запрос на другой домен? (3)
• Внешние зависимости (1)
• Включение условных запросов в приложениях на Zend Framework (0)

Предлагаю перевод хорошей статьи с советами по выполнению фиксаций в хранилище. Оригинал написан для проекта T2, но практически все советы универсальны и легко применимы для любого другого проекта. А самое главное — они действительно полезны.

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

Источник: T2 SVN commit tutorial
Автор: The T2 SDE Project
Перевод: Лобач Олег

Дважды подумайте перед фиксацией изменений

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

Никогда не фиксируйте код, который не компилируется

Прим. пер.: в этом пункте речь идет о компиляции, что для веб-разработки не актуально, но если под компиляцией понимать отсутствие ошибок, то пункт вполне обретает смысл и для веб-приложений

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

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

Тестируйте ваши изменения перед фиксацией

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

Дважды проверьте то, что фиксируете

Сделайте «svn up» и «svn diff» перед фиксацией. Получите сообщения от SVN о конфликтах, неизвестных файлах и прочее. «svn diff» покажет, что же именно вы фиксируете. Проверьте, действительно ли это то, что вы собирались фиксировать.

Всегда добавляйте содержательные комментарии¹ к фиксации

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

На практике, заносите в комментарии всю важную информацию, которую невозможно увидеть из вывода команды diff.

Система контроля версий не является заменой общению между разработчиками

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

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

Возьмите на себя ответственность за собственные фиксации

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

Не фиксируйте код, который вы не понимаете

Избегайте ситуаций, подобных этой: «Я не знаю, почему он падает, но когда я делаю это, он больше не падает» или «Я не вполне уверен, что это правильно, но во всяком случае у меня это работает».

Если вы не нашли решение проблемы, обсудите её с другими разработчиками.

Не злоупотребляйте своим SVN-аккаунтом, чтобы пропихнуть изменения, отвергнутые другими разработчиками

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

Если вы фиксируете багфикс, учитывайте перенос исправлений в другие ветки

Используйте одинаковый комментарий для обеих фиксаций – основного исправления и переносимого (только дополните комментарий номером ревизии основной фиксации). Таким образом, можно легко увидеть, какие исправления были уже перенесены.

Если вы исправляете ошибки, зафиксированные в системе учета ошибок², добавьте в комментарий номер ошибки

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

Создавайте атомарные фиксации

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

Не смешивайте изменения форматирования и изменения кода

Изменение форматирования кода, такое как отступ или разрежение, просто взрывает diff, что сильно затрудняет поиск изменений в коде если они перемешаны с форматированием. Фиксирование изменений форматирования отдельно разрешает эту проблему.

Похожие записи

• Снова про использование Subversion (0)
• Пользовательские ресурсы для Zend_Application (0)
• Как слить изменения между ветками. Часть 2 (1)
• Как слить изменения между ветками. Часть 1 (1)
• Как и Зачем делать ветки? (3)

Источник: Enable your Zend Framework App with Conditional GET!
Автор: Danila Vershinin
Перевод: Лобач Олег

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

Эта техника предполагает использование условного GET-запроса (HTTP conditional GET). Это базовая возможность HTTP-протокола. Посылая правильные HTTP-заголовки, ваше приложение позволяет браузерам посетителей кэшировать страницы вашего сайта.

Вы беспокоитесь о посетителях, имеющих старые версии страниц в кэше? Не стоит! Предлагаемый метод позволяет получить все выгоды от кэширования на стороне клиента без внесения каких-либо изменений, и требует всего 5 минут вашего времени для ее интеграции :).

Zend Framework великолепен в том, что вы можете легко расширить его. Мы собираемся создать плагин фронт-контроллера, который будет заботиться о обработке условных GET-запросов.

Давайте создадим наш плагин фронт-контроллера:

<?php
/**
 * Plugin to support conditional GET for php pages (using ETag)
 * Should be loaded the very last in the plugins stack
 *
 * @author $Author: danila $
 * @version $Id: Conditional.php 15741 2009-02-08 11:58:44Z danila $
 *
 */
class Smartycode_Http_Conditional extends Zend_Controller_Plugin_Abstract
{

    public function dispatchLoopShutdown()
    {
        $send_body = true;

        $etag = '"' . md5($this->getResponse()->getBody()) . '"';

        $inm = split(',', getenv("HTTP_IF_NONE_MATCH"));

        $inm = str_replace('-gzip', '', $inm);

        // TODO If the request would, without the If-None-Match header field,
        // result in anything other than a 2xx or 304 status,
        // then the If-None-Match header MUST be ignored

        foreach ($inm as $i) {
            if (trim($i) == $etag) {
                $this->getResponse()
                     ->clearAllHeaders()
                     ->setHttpResponseCode(304)
                     ->clearBody();
                $send_body = false;
                break;
            }
        }

        $this->getResponse()
             ->setHeader('Cache-Control', 'max-age=7200, must-revalidate', true)
             ->setHeader('Expires', gmdate('D, d M Y H:i:s', time() + 2 * 3600) . ' GMT', true)
             ->clearRawHeaders();

        if ($send_body) {
            $this->getResponse()
                 ->setHeader('Content-Length', strlen($this->getResponse()->getBody()));
        } 

        $this->getResponse()->setHeader('ETag', $etag, true);
        $this->getResponse()->setHeader('Pragma', '');
    }
}

Подключить этот плагин к фронт-контроллеру очень легко. Так же легко, как добавление строки в загрузочный файл:

$frontController->registerPlugin(
            new Smartycode_Http_Conditional(),
            101
        );

Обратите внимание на «101». Вы должны зарегистрировать плагин последним в стеке плагинов.

Эти простые шаги сделают ваше приложение на Zend Framework более дружелюбным к окружению:

• Работа AJAX-запросов происходит через зендовский MVC (все виды запросов)
• Если страницы не изменялись со времени последнего запроса, то они не будут передаваться
• Можно также полагать, что вы получите пользу для SEO — поисковые системы, поддерживающие Etag, смогут эффективно пропускать загрузку / повторный анализ страниц сайта, что ускорит индексацию страниц вашего сайта
• Отправка заголовка Content-Length включает постоянные соединения (Keep-Alive connections)
• Есть еще достоинства, но мне лень о них думать

Похожие записи

• Создание повторно используемых плагинов ресурсов Zend_Application (0)
• Пользовательские ресурсы для Zend_Application (0)
• Перехватчики в помощниках действий (0)
• Использование помощников действий (7)
• Быстрый старт с Zend_Application_Bootstrap (0)

Сегодня с подачи Федерико обнаружил один интересный плагин — «Scienta ZF Debug Bar».

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

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

В ближайшее время попробую этот плагин в работе. О впечатлениях напишу.

Похожие записи

• Создание повторно используемых плагинов ресурсов Zend_Application (0)
• Включение условных запросов в приложениях на Zend Framework (0)
• Хитрости ZF1.8 (1)
• Пользовательские ресурсы для Zend_Application (0)
• Перехватчики в помощниках действий (0)

Роб Аллен опубликовал статью с описанием применения нового «пакета» Zend_Application. Этот «пакет» представляет собой набор классов для упрощения и облегчения  создания загрузчика приложения (bootstrap file). Zend_Application сейчас находится в инкубаторе и его активно дорабатывают. Выпуск намечен в релизе 1.8.

Роб описывает два варианта использования Zend_Application: воспользоваться системой плагинов, каждый из которых отвечает за инициализацую своей части приложения (БД, представление, фронт-контроллер, и т.д.), или реализовать инициализацию в методах специального класса.

На мой взгляд это будет достаточно полезный класс и если у кого-то возникло желание познакомится с ним поближе — предлагаю начать с чтения статьи «Initial notes on Zend_Application»

Похожие записи

• Хитрости ZF1.8 (1)
• Пользовательские ресурсы для Zend_Application (0)
• Создание повторно используемых плагинов ресурсов Zend_Application (0)
• Перехватчики в помощниках действий (0)
• Открыта регистрация на первую Российскую конференцию посвященную Zend Framework (0)

Сегодня я хочу предложить вам перевод статьи Federico Cargnelutti PHPUnit: Testing Zend Framework Controllers, посвященной первым шагам в модульном тестировании контроллеров действий Zend Framework.

Тестирование Веб-приложений — это комплексная задача, потому что веб-приложение создается из нескольких логических слоев. Модульное тестирование контроллера Zend Framework может быть весьма трудной задачей, особенно для тех, кто слабо знаком с Zend Framework.

Вы можете тестировать свои контроллеры действий использую Zend_Test и/или PHPUnit. Zend_Test позволяет вам имитировать запросы, передавать тестовые данные, контролировать вывод вашего приложения и в целом убедиться в том, что ваш код делает именно то, что должен делать. Вам решать, какой из них использовать. Если вы не можете выбрать один из них, то можете использовать оба. Если вы только знакомитесь с тестированием с помощью Zend_Test, то эта статья будет лучшим местом старта.

Фреймворк PHPUnit может показаться очень знакомым тем разработчикам, которые пришли из Java. Разработчики PHPUnit черпали вдохновение из JUnit — тестовом фреймворке для платформы Java, поэтому вы будете чувствовать себя как дома при использовании PHPUnit если вам уже приходилось сталкиваться с JUnit или одним из его клонов.

Конечно, никто не запрещает вам использовать системы бок о бок (даже в одном и том же приложении). В конце концов, большинство проектов так и будет использовать.

Использование PHPUnit

Во-первых, вам необходимо создать структуру каталогов:

app/
    config/
    controllers/
        ExampleController.php
    models/
    views/
lib/
    Zend/
public/
tests/
    controllers/
        AllTests.php
        ExampleControllerTest.php
    lib/
    AllTests.php
    bootstrap.php

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

tests/bootstrap.php [ Открыть в Codepad ]

<?php
/* Start output buffering */
ob_start();

/* Report all errors directly to the screen for simple diagnostics in the dev environment */
error_reporting( E_ALL | E_STRICT );
ini_set('display_startup_errors', 1);
ini_set('display_errors', 1);
date_default_timezone_set('Europe/London');

/* Determine the root and library directories of the application */
$appRoot = dirname(__FILE__) . '/..';
$libDir = "$appRoot/lib";
$path = array($libDir, get_include_path());
set_include_path(implode(PATH_SEPARATOR, $path));

define('APPLICATION_PATH', $appRoot . '/app');
define('APPLICATION_ENVIRONMENT', 'dev');

require_once "Zend/Loader.php";
Zend_Loader::registerAutoload();

$front = Zend_Controller_Front::getInstance();
$front->throwExceptions(true);
$front->setParam('noViewRenderer', true);
$front->setParam('env', APPLICATION_ENVIRONMENT);
$front->setRequest(new Zend_Controller_Request_Http());
$front->returnResponse(true);

$router = $front->getRouter();
include APPLICATION_PATH . '/config/routes.php';
$router->addRoutes($routes);
$router->setParams($front->getParams());

$dispatcher = $front->getDispatcher();
$dispatcher->setParams($front->getParams());
$dispatcher->setResponse($front->getResponse());
$router->route($front->getRequest());

Обратите внимание! Отключение помощника ViewRenderer является не обязательным. Однако, вам должно быть известно, что использование класса Zend_Controller_Action_Helper_ViewRenderer может привести к снижению производительности. Подробнее об этом можно прочесть здесь.

Класс PHPUnit_Framework_TestSuite фреймворка PHPUnit позволяет вам организовать тесты в иерархические наборы тестов:

tests/AllTests.php [ Открыть в Codepad ]

<?php
require_once dirname(__FILE__) . '/bootstrap.php';
require_once dirname(__FILE__) . '/controllers/AllTests.php';

class AllTests
{
    public static function main()
    {
        $parameters = array();
        PHPUnit_TextUI_TestRunner::run(self::suite(), $parameters);
    }

    public static function suite()
    {
        $suite = new PHPUnit_Framework_TestSuite('My Application');
        $suite->addTest(ControllersAllTests::suite());
        return $suite;
    }
}
AllTests::main();

tests/controllers/AllTests.php [ Открыть в Codepad ]

<?php
require_once dirname(__FILE__) . '/ExampleControllerTest.php';

class ControllersAllTests
{
    public static function main()
    {
        PHPUnit_TextUI_TestRunner::run(self::suite());
    }
    public static function suite()
    {
        $suite = new PHPUnit_Framework_TestSuite('My Application - Controllers');
        $suite->addTestSuite('ExampleControllerTestCase');
        return $suite;
    }
}

Написание модульных тестов

Из-за довольно странных причин эта часть не описана в документации. Вот что вам нужно сделать до написания теста:

1. Подключить контроллер, который вы собираетесь тестировать.
2. Расширить контроллер действий (унаследовавшись от него).
3. Сбросить состояние экземпляра фронт-контроллера.
4. Указать путь к тестируемому контроллеру действий.
5. Установить объекты Запроса и Ответа.
6. Создать экземпляр тестируемого объекта.

Пример:

tests/controllers/ExampleControllerTest.php [ Открыть в Codepad ]

<?php
require_once APPLICATION_PATH . '/controllers/ExampleController.php';

class ExampleControllerTest extends ExampleController
{
    public function __construct($url = null)
    {
        $front = Zend_Controller_Front::getInstance();
        $front->resetInstance();
        $front->setControllerDirectory(APPLICATION_PATH . '/controllers');
        $front->setRequest(new Zend_Controller_Request_Http($url));
        $front->setResponse(new Zend_Controller_Response_Http());
        parent::__construct($front->getRequest(), $front->getResponse());
    }
}

Вся магия происходит внутри класса ExampleControllerTest. Он делает так, что контроллер действий думает, что был вызван фронт-контроллером в цикле диспетчеризации. Единственный путь сделать это — создание экземпляра контроллера действий без диспетчеризации запроса. Получение экземпляра контроллера действий дает вам больше контроля и гибкости, особенно при тестировании веб-сервисов.

А теперь пришло время создать наш первый тестовый набор. Тестовый набор это класс, наследуемый от PHPUnit_Framework_TestCase, содержащий тестовые методы, определяемые по префиксу “test” в названии метода.

[ Открыть в Codepad ]

require_once APPLICATION_PATH . '/controllers/ExampleController.php';

class ExampleControllerTest extends ExampleController
{
    ...
}

class ExampleControllerTestCase extends PHPUnit_Framework_TestCase
{
    public function testDefaultAction()
    {
        $controller = new ExampleControllerTest();
        $isDispatched = $controller->indexAction();

        $this->assertTrue($isDispatched);
    }

    public function testFirstAction()
    {
        $url = 'http://localhost/example/first';
        $controller = new ExampleControllerTest($url);
        $controller->firstAction();
        $errorMsg = $controller->getRequest()->getParam('error_message', null);

        $this->assertEquals(null, $errorMsg);
    }

    public function testGetParameterName()
    {
        $url = 'http://localhost/example/first/fed';
        $controller = new ExampleControllerTest($url);
        $name = $controller->getRequest()->getParam('name', null);

        $this->assertEquals('fed', $name);
    }

    public function testGetNameMethod()
    {
        $url = 'http://localhost/example/first/fed';
        $controller = new ExampleControllerTest($url);
        $name = $controller->getName();
        $this->assertEquals('fed', $name);
    }
}

Запуск тестов

federico@tests$ phpunit AllTests
PHPUnit 3.3.8 by Sebastian Bergmann.
.....
Time: 0 seconds
OK (4 tests, 4 assertions)

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

Похожие записи

• Хитрости ZF1.8 (1)
• Создание повторно используемых плагинов ресурсов Zend_Application (0)
• Пользовательские ресурсы для Zend_Application (0)
• Перехватчики в помощниках действий (0)
• Открыта регистрация на первую Российскую конференцию посвященную Zend Framework (0)