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

1. установить почтовый прокси и настроить приложение (или php) на отправку почты через него
2. использовать специальный почтовый транспорт.

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

Я же решил воспользоваться вторым вариантом, т.к. сделать это оказалось достаточно просто.

В Zend Framework есть специальный компонент, отвечающий за рассылку почты — Zend_Mail. Этот компонент предоставляет единый интерфейс для различных почтовых транспортов (таких как php-функция mail или прямое соединение с smtp-сервером). Написать собственный транспорт не составляет большого труда, что, собственно, я и сделал.

Пример использования почтового транспорта

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

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

А теперь вернемся к использованию транспорта.

Чтобы указать Zend_Mail каким образом следует отправлять почту, следует передать экземпляр нужного транспорта в метод отправки почты (см. документацию).

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

# application/config/application.in
autoloaderNamespaces[] = "bpLib_"

Во-вторых, перед вызовом метода send Zend_Mail-а создадим экземпляр файлового транспорта:

$transport = new bpLib_Mail_Transport_File(
        '/tmp',
        bpLib_Mail_Transport_File::MODE_REGULAR
);

Конструктор файлового транспорта принимает 3 параметра:

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

По первому параметру, я думаю, все ясно, поясню остальные. Режим работы задается маской — в нулевом бите режим формирования имен файлов, в первом режим записи в файл. Таким образом существует три варианта:

• bpLib_Mail_Transport_File::MODE_REGULAR — для постоянного имени файла с перезаписью содержимого файла
• bpLib_Mail_Transport_File::MODE_REGULAR | bpLib_Mail_Transport_File::MODE_APPEND — для постоянного имени файла с дополнением файла
• bpLib_Mail_Transport_File::MODE_RANDOM — для индивидуальных имен файлов у каждого письма

Четвертый вариант (индивидуальные имена с дополнением файла) хоть и возможен, но бессмыслен.

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

protected function randomFilename()
{
    return date('Y-m-d-H-i-s').'-'.rand(10000,99999).'.eml';;
}

Ну и наконец передаем созданный нами экземпляр транспорта в метод send:

$mail = new Zend_Mail('UTF-8');
$mail->setSubject("SUBJECT")
    ->addTo('recipient@mail.com')
    ->setFrom('from@mail.com', 'From User')
    ->setBodyText("some text...")
    ->send($transport)
    ;

Собственно это все, что нужно для использования.

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

$transport = new bpLib_Mail_Transport_File(
        '/tmp',
        bpLib_Mail_Transport_File::MODE_REGULAR
);
Zend_Mail::setDefaultTransport($transport);

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

До новых встреч!

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

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

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

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

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

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

В моей последней статье (Быстрый старт с 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 (2)
• Включение условных запросов в приложениях на Zend Framework (0)
• Zend_Tool и ZF 1.8 (4)
• Хитрости ZF1.8 (1)

На днях закончился прием тезисов по планируемым докладам. Примечательно, что в состав докладчиков вошли ведущие участники русскоязычного сообщества 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)

Мы добавили 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 (4)
• Хитрости ZF1.8 (1)
• Перехватчики в помощниках действий (0)

Рано или поздно, вы захотите использовать 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 (2)
• Zend_Tool и ZF 1.8 (4)
• Перехватчики в помощниках действий (0)

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

В конце концов такая ситуация надоела и я по локоть залез своими шаловливыми ручонками вглубь 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 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 (2)
• Хитрости ZF1.8 (1)
• Перехватчики в помощниках действий (0)

Как в новой версии фреймворка применять конфигурационный файл?
Раньше вопрошающий устанавливал переменную в своем конфигурационном файле:
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)
• Как протестировать рассылку почты (13)
• Использование Zend_Application (0)
• Быстрый старт с Zend_Application_Bootstrap (2)

В этой статье я покажу вам простой подход, позволяющий вашим приложениям на 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 (2)

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

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

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

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

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

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

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

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

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

Тестирование Веб-приложений — это комплексная задача, потому что веб-приложение создается из нескольких логических слоев. Модульное тестирование контроллера 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)

Вначале очень краткий ликбез. Механизм поддержки различных языков в ZendFramework реализована в виде компонента Zend_Translate. Он поддерживает массу различных форматов хранения переводов: array, csv, gettext, ini, tbx, tmx, qt, xliff, xmltm. За описаниями особенностей форматов я отправлю в руководство разработчике — Adapters for Zend_Translate. Настройка Zend_Translate на тот или иной формат выполняется с помощью подключения соответствующего адаптера. На этом, думаю, с вводной частью я закончу и покажу, как использовать Zend_Translate.

Простейший способ использования компонента заключается в создании экземпляра этого класса в загрузочном файле:

<?php

$translate = new Zend_Translate('gettext',
                                '/path/to/translate.mo',
                                'en');
Zend_Registry::set('Zend_Translate', $translate);

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

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

Код плагина приводить не буду — он доступен по ссылке в конце статьи. Опишу лишь отличия и покажу пример использования.

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

Спецификация конструктора следующая:

public function __construct(array $options = array(), Zend_Translate $translate = null, Zend_Locale $locale = null, $skipRegistry = false)

<

p>Входные параметры:

• $options — массив параметров для инициализации экземпляра Zend_Translate. Элементы массива идентичны параметрам конструктора Zend_Translate:
  • adapter — используемый адаптер
  • data — данные для адаптера
  • locale — используемая локаль
  • options — параметры конфигурации Zend_Translate
  • langKey — этот параметр относится уже непосредственно к плагину и определяет название параметра запроса, содержащего указание на запрашиваемый язык
• $translate — экземпляр класса Zend_Translate
• $locale — экземпляр класса Zend_Locale (может потребоваться если нужно указать язык, отличный от указанного в запросе)

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

<?php

$config = new Zend_Config_Ini('/path/to/config.ini');
Zend_Controller_Front::getInstance()->registerPlugin(new Zeus_Controller_Plugin_Language($config->translate));

Вот и все! Локаль настроена, переводчик инициализирован и готов к употреблению

Остановлюсь на еще одном моменте. Плагин в результате работы регистрирует экземпляр локали и переводчика в реестре использую стандартные ключи: Zend_Locale и Zend_Translate соответственно. Такое решение, помимо доступности объектов в любом месте приложения, позволяет воспользоваться стандартными помощниками вида и помощниками действий:

$this->view->title = $this->view->translate('default-register-index-title');

<?php echo $this->translate('default-register-index-title'); ?>

Код плагина можно взять тут:

• Zeus_Controller_Plugin_Language
• SVN

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

P.S.: Вчера вышел ZendFramework 1.7.2. Посмотреть исправления можно по адресу http://framework.zend.com/issues/secure/views/IssueNavigator.jspa?requestId=10923. Последний релиз, как всегда, берем http://framework.zend.com/download/latest/.

P.P.S.: Хочу порекомендовать блог Романа Настенко «Перфектомания». Роман пишет на темы, связанные с разработкой сайтов: юзабилити, проектирование, SMO. Читаю его давно и с интересом.

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

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

P.S.: ну и пользуясь случаем, хочу выполнить обещание и порекомендовать обратить внимание на каталог ссылок по теме Zend Framework — стоит пробежаться по собранным там ресурсам, можно найти кое-что интересное.

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

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