Список докладов и финальная регистрация ZFConf 2011

Основные подготовительные работы по конференции закончены. Доклады сформированы. Среди спикеров представители KnpLabs, Magento, JetBrains, Sphinx и других известных компаний.

Открыта финальная регистрация!

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

Пожалуйста, обратите внимание на то, что изменилось место проведения! Мероприятие будет проходить на прошлогодней площадке — в актовом зале ЛГТЦ (Ленгипротранс-Центр), по адресу: Московский пр., 143, ст. м. «Электросила». Кофе-брейки и обсуждения на флипчартах будут проходить в фойе.

Cписок докладов:

• Гибкая архитектура Zend Framework приложений с использованием Dependency Injection
  Алексей Качаев (Сogniance, Senior PHP Developer)
• Воюем за ресурсы: Повышение производительности Zend Framework приложения с помощью phpDaemon, Varnish и ESI
  Алексей Качаев (Сogniance, Senior PHP Developer)
• Behavior Driven Development в PHP и Zend Framework
  Константин Кудряшов (KnpLabs, Senior Web Developer)
• Разделение труда: Организация многозадачной, распределенной системы в Zend Framework с помощью Job Queue
  Александр Готгельф (Magento, PHP-разработчик)
• Как может помочь среда разработки при написании приложения на Zend Framework?
  Николай Матвеев (JetBrains, разработчик)
• Создание REST-API для сторонних разработчиков и мобильных устройств с авторизацией по протоколу OAuth 1.0
  Дмитрий Чижевский (Дзен-мани, разработчик)
• Толстая модель: История разработки собственного ORM
  Михаил Шамин (Геометрия, ведущий разработчик)
• Что такое Sphinx, зачем он вообще нужен и как его использовать с PHP (от простого индекса до поискового кластера)
  Владимир Федорков (Sphinx, Director of Professional Services)

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

Торопитесь, количество мест ограничено!

Обязательно следите за последними новостями:
— RSS-канал: feeds.feedburner.com/zfconf
— Twitter: @zfconf
— Группа ВКонтакте: vkontakte.ru/club14951507

Организатор: компания Wizartech
Партнеры: сообщество zendframework.ru и конференция ZFConf Ukraine

 

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

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

Реализовать загрузку файлов проблемы не составляет — для этого в Zend Framework есть специальный компонент: Zend_File_Transfer. Подробно его использование я описывать не буду — в руководстве это описано достаточно хорошо, а хочу остановиться на связанной с загрузкой изображений задаче. А именно на изменении размеров загруженных изображений.

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

• подготовить изображение нужного размера при его загрузке пользователем
• изменить размер изображения в момент получения запроса на его отображение

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

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

Основой моего класса стала статья Ильдара Шайморданова «Thumbnails: Теория и практика создания миниатюрных изображений» (исходный код библиотеки). Код класса также частично основан на библиотеке Ильдара (с его любезного разрешения). Загрузить фильтр можно с github-а. Кстати, буду благодарен за помощь в написании английской версии документации.

Параметры

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

• width — ширина миниатюры в пикселях (целое положительное число, по умолчанию 800);
• height — высота миниатюры в пикселях (целое положительное число, по умолчанию 600);
• method — метод обработки — максимальное/минимальное сжатие, вырезание фрагмента целого(целое число, по умолчанию максимальное сжатие);
• percent — масштабирование в процентах от оригинала (положительное вещественное число на интервале от 0 до 1, по умолчанию 0);
• halign — вертикальное выравнивание (допустимые значения 0 — по центру, < 0 — выравнивание по верхнему краю, > 0 — выравнивание по нижнему краю, по умолчанию — 0);
• valign — горизонтальное выравнивание (допустимые значения 0 — по центру, < 0 — выравнивание влево, > 0 — выравнивание вправо, по умолчанию — 0);

Если указать параметр «масштаб», отличный от 0, то для вычисления размеров будет использован он, а ширина и высота проигнорированы.

В классе определены несколько констант:

• Методы обработки:
  • METHOD_SCALE_MAX — максимальное сжатие;
  • METHOD_SCALE_MIN — минимальное сжатие;
  • METHOD_CROP — вырезание фрагмента;
• Методы выравнивания:
  • ALIGN_CENTER — выравнивать по центру, подходит для горизонтального и вертикального выравнивания;
  • ALIGN_LEFT — выравнивать по левому краю;
  • ALIGN_RIGHT — выравнивать по правому краю;
  • ALIGN_TOP — выравнивать по верхнему краю;
  • ALIGN_BOTTOM — выравнивать по нижнему краю;

Примеры

Предупреждение

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

Пример создания фильтра:

$filter = new App_Filter_File_ImageResize(array(
    'width' => 100,
    'heigth' => 100
));
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addFilter($filter);

Создание миниатюры:

$options = array('width' => 100, 'height' => 100);
 
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addFilter(new App_Filter_File_ImageResize($options))
       ->setDestination('/path/to/upload/directory');
if (!$upload->receive()) {
    echo implode("\n", $upload->getMessages());
    return;
}
$filename = $upload->getFileName();

В переменной $filename будет имя уже уменьшенного файла.

Каскадное уменьшение больших изображений:

$bigSize   = array('width' => 1600, 'height' => 1200);
$smallSize = array('width' => 800, 'height' => 600);
 
$upload = new Zend_File_Transfer_Adapter_Http();
$upload->addFilter(new App_Filter_File_ImageResize($bigSize))
       ->addFilter(new App_Filter_File_ImageResize($smallSize))
       ->setDestination('/path/to/upload/directory');
if (!$upload->receive()) {
    echo implode("\n", $upload->getMessages());
    return;
}
$filename = $upload->getFileName();

В этом примере изображение сначала уменьшается до размеров 1600×1200, а за тем до 800×600. Такое каскадное уменьшение позволяет в итоге получить качество несколько лучшее, чем уменьшение очень большого изображения до очень маленького за один шаг.

В заключении приведу еще раз ссылку на исходный код класса: App_Filter_File_ImageResize.

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

 

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

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

27го ноября в в Киеве пройдет бесплатная, международная, совместная конференция ZFConf Ukraine & MageConf. Цель конференции — объединить лучших специалистов PHP и Zend Framework Украины, России и других стран СНГ.

ZFConf Ukraine – первая в Украине конференция по Zend Framework, проводится в партнерстве с ZFConf Russia и сообществом zendframework.ru. ZFConf Russia была первой конференцией по Zend Framework и прошла в марте этого года в Санкт-Петербурге, Россия, собрав более 200 участников из России, Беларуси, Украины, Литвы и других стран СНГ

Конференция MageConf впервые прошла в мае 2010 года в Киеве. Это была первая конференция из серии PHP and Zend Framework в Украине. Ее посетили более 150 специалистов.

Конференция пройдет 27 ноября, в Киеве
Титульный спонсор конференции – компания Magento
Место: КиевЭкспоПлаза, ул. Салютная 2б, 3 павильон
Время: 27 ноября 2010 г. (с 11:00 до 19:00)
Длительность: 1 полный день
Формат: доклады в три потока и обсуждения на флипчарте (в перерывах)
Язык докладов: русский
Стоимость участия: бесплатно
Потоки: Zend Framework, PHP, Magento.

Аудитория: Разработчики ПО и специалисты по Project Management с Украины, России и близлежащих стран СНГ. Ожидаемое количество участников – 500 человек.

Доклады

1. Встречайте Zend Framework 2.0
Александр Веремьев / Zend Framework Core команда (Zend Technologies)

2. Эволюция ZF: архитектура, шаблоны, рефакторинг
Виктор Фараздаги / Component Maintainer и Contributor ZF 2.0 (4C)

3. Юнит тестирование в Zend Framework 2.0
Ростислав Михайлив / Chief Developer / Software Architect (Gadu-Gadu)

4. Хранение, обработка и отдача статики с использованием \Zend \File. Опыт социальной сети starlook.ru
Кирилл Мокевнин / Senior developer (undev)

5. Чуть сложнее чем Singleton: аннотации, IOC, АОП
Кирилл Чебунин / Senior PHP Developer (Альпари)

6. Doctrine 2
Валерий Рабиевский / Team leader (stfalcon.com)

Список еще будет обновляться, вы также можете подать заявку на доклад, если вам есть чем поделиться поделиться с общественностью. Также были бы рады услышать ваши комментарии по текущим темам.

Регистрация
Регистрируясь на одну конференцию, вы автоматически получаете доступ и на другую.

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

Регистрируйтесь и следите за обновлениями на http://zfconf.org.ua

 

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

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

Главной причиной, побудившей меня написать эту заметку, стало включение моего класса для тестирования рассылки почты в этот релиз. Хочу выразить огромную благодарность за работу по внедрению этого компонента в ZF Александру Стешенко.

Ну, и раз начал, кратко опишу что нового появилось в этом релизе:

• поддержка мобильных устройств с помощью компонента Zend_Http_UserAgent
• поддержка SimpleCloud API (класс Zend_Cloud)
• Dojo обновлен до версии 1.5.0
• поддержка Amazon SimpleDb
• поддержка eBay Findings API
• Zend_Db совместима с MariaDB
• добавлены два новых формата конфигурационных файлов — YAML и JSON
• появился сервис для сокращения ссылок. В комплекте идут адаптеры для http://jdem.cz и http://tinyurl.com
• добавлены вью-хелперы:
  • Zend_View_Helper_UserAgent (поддержка мобильных устройств)
  • Zend_View_Helper_TinySrc (сокращение ссылок)
  • Zend_View_Helper_Gravatar (подгрузка аватарок из Gravatar-а)
• а так же множество багфиксов

 

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

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

Upd: этот класс был включен в Zend Framework 1.11.0. Раздел руководства по использованию компонента.

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

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)
• Список докладов и финальная регистрация ZFConf 2011 — второй российской конференции по Zend Framework (0)
• Создание повторно используемых плагинов ресурсов Zend_Application (2)
• Пользовательские ресурсы для Zend_Application (0)

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

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

 

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

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

В моей последней статье (Быстрый старт с 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 (7)
• Включение условных запросов в приложениях на 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

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

 

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

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

Мы добавили 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 (2)
• Пользовательские ресурсы для 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 (2)
• Хитрости ZF1.8 (1)
• Быстрый старт с Zend_Application_Bootstrap (7)
• 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)
• Список докладов и финальная регистрация ZFConf 2011 — второй российской конференции по Zend Framework (0)
• Создание повторно используемых плагинов ресурсов Zend_Application (2)
• Пользовательские ресурсы для Zend_Application (0)
• Перехватчики в помощниках действий (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 (2)
• Быстрый старт с Zend_Application_Bootstrap (7)
• Хитрости 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 (2)
• Как протестировать рассылку почты (13)
• Использование Zend_Application (0)
• Быстрый старт с Zend_Application_Bootstrap (7)

В этой статье я покажу вам простой подход, позволяющий вашим приложениям на 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 (2)
• Пользовательские ресурсы для Zend_Application (0)
• Перехватчики в помощниках действий (0)
• Использование помощников действий (8)
• Быстрый старт с Zend_Application_Bootstrap (7)

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

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

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

 

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

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