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

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

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

Постовой:

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

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

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

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

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

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

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

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

Zend_CodeGenerator и Zend_Reflection

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

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

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

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

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

Zend_Tool_Project

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

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

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

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

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

Помощь

Ошибка

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

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

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

Что дальше

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

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

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

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

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

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

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

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

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

Роб ответил:

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

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

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

$config = new Zend_Config($configArray);

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

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

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

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

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

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

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

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

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

Фичи:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    public function dispatchLoopShutdown()
    {
        $send_body = true;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

[ Открыть в Codepad ]

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

class ExampleControllerTest extends ExampleController
{
    ...
}

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

        $this->assertTrue($isDispatched);
    }

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

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

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

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

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

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

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

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

В последний день 2008 года хочу поздравить читателей этого блога с наступающим новым 2009 годом!

Осталось совсем немного времени до полуночи, поэтому буду краток :)

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

С НОВЫМ ГОДОМ!

PS: Оставайтесь, будет интересно ;)

Недавно на DevZone появился анонс статьи о создании многоязычных сайтов средствами ZendFramework — «using Zend Framework Language component. Вопреки сложившейся в последнее время традиции, я не стал переводить заинтересовавшую меня статью. Вместо этого я решил развить реализацию, предложенную автором.

Вначале очень краткий ликбез. Механизм поддержки различных языков в 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. Читаю его давно и с интересом.

Не могу не написать о выпуске новой версии ZF. Этот релиз исключительно багфиксовый, посему рекомендуется обновиться.

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

Роб Ален опубликовал новую заметку в своем блоге — File uploads with Zend_Form_Element_File. Пост хоть и не большой, но для новичков полезный. Предлагаю мой перевод этой заметки. Рекомендую обратить особое внимание на первый абзац заключения.

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

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

Итак, приступим:

Форма

Мы расширим Zend_Form и сохраним полученный класс forms_UploadForm в каталоге application/forms:

<?php

class forms_UploadForm extends Zend_Form
{
    public function __construct($options = null)
    {
        parent::__construct($options);
        $this->setName('upload');
        $this->setAttrib('enctype', 'multipart/form-data');

        $description = new Zend_Form_Element_Text('description');
        $description->setLabel('Description')
                  ->setRequired(true)
                  ->addValidator('NotEmpty');

        $file = new Zend_Form_Element_File('file');
        $file->setLabel('File')
            ->setDestination(BASE_PATH . '/data/uploads')
            ->setRequired(true);

        $submit = new Zend_Form_Element_Submit('submit');
        $submit->setLabel('Upload');

        $this->addElements(array($description, $file, $submit));
    }
}

Как и ранее (прим. пер.: в предыдущей заметке, ссылка на которую была выше), мы задаем имя формы и атрибут enctype для включения механизма загрузки файлов. Сама форма имеет два поля: текстовое поле, названное «Описание», и поле для загрузки файла, названное «Файл», наряду с кнопкой «Отправить». Здесь ничего особо сложного нет.

Элемент Zend_Form_Element_File имеет метод setDestination (), который используется для указания нижележащему (прим. пер.: имеется в виду с точки зрения абстракции) Zend_File_Transfer_Adapter_Http где мы хотим сохранить загруженные файлы. В данном примере мы выбрали каталог data/uploads.

Контроллер и представление

Контроллер так же весьма стандартный:

<?php

class IndexController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $this->view->headTitle('Home');
        $this->view->title = 'Zend_Form_Element_File Example';
        $this->view->bodyCopy = "<p>Please fill out this form.</p>";

        $form = new forms_UploadForm();

        if ($this->_request->isPost()) {
            $formData = $this->_request->getPost();
            if ($form->isValid($formData)) {

                // success - do something with the uploaded file
                $uploadedData = $form->getValues();
                $fullFilePath = $form->file->getFileName();

                Zend_Debug::dump($uploadedData, '$uploadedData');
                Zend_Debug::dump($fullFilePath, '$fullFilePath');

                echo "done";
                exit;

            } else {
                $form->populate($formData);
            }
        }

        $this->view->form = $form;
    }
}

Представление views/scripts/index.phtml абсолютно тривиально:

<h1><?= $this->title; ?></h1>
<?= $this->bodyCopy; ?>
<?= $this->form; ?>

Если форма успешно прошла валидацию, массив $uploadedData будет содержать значения полей формы вместе с именем загруженного файла. Обратите внимание, что имя файла не полное. Если вам нужен весь путь к файлу, то используйте метод getFileName () файлового элемента.

Заключение

Это все, что нужно для построения простейшей формы загрузки файлов. Однако есть еще несколько настолько важных ошибок в компоненте, что имеет смысл дождаться версии 1.7.2. К примеру, валидатор Count не всегда работает так, как от него ожидаешь, а getValues () и receive () все еще не достаточно умны, чтобы вызывать move_uploaded_file () только один раз.

Как обычно, вот zip-файл проекта, созданный мной для тестирования: Zend_Form_Element_File_Example.zip (включает Zend Framework (снепшот ветки release-1.7) — именно поэтому он более 3,9Мб).

Сегодня хочу порекомендовать к прочтению пару блогов.

Первым представлю «Zend Framework по–русски» — полностью посвященный замечательному php-фреймворку. Сергей Митрошин, автор этого блога, публикует 3-4 весьма интересных статьи в месяц. Из последнего рекомендую к прочтению:

• статьи про использование ContextSwitch (Сергей его почему-то называет переключателем «контентов», вместо «контекстов») — Переключая контенты — экспорт в RSS и Переключая контенты — работа с AJAH
• Основы Zend_Form. Часть 1 — быстрый старт и Декораторы Zend_Form

Следующий на очереди — блог «От новичка до профессионала» (автор скрывается под ником Novice, хотя если судить по уровню статей, то новичком его назвать сложно :)). Зацепил он меня статьями о паттернах проектирования — крайне полезное знание для профессионального разработчика. Я сейчас как раз читаю классический труд на эту тему — «Приемы объектно-ориентированного проектирования. Паттерны проектирования», абсолютный must-have для разработчика, использующего ООП. Не зря эта книга считается самой полезной в плане изучения ООП.

Что-то я отвлекся, давайте вернемся к блогу. Описания паттернов собраны в двух рубриках: Продвинутый php и Профессиональный php (из последнего опубликованного — Антипаттерн: Спагетти-код). Кроме этих рубрик рекомендую заглянуть еще в AJAX / Javascript и Практика php. Вообщем, однозначно полезный блог.

Вчера Роб Ален опубликовал продолжение заметки про написание помощников действий в Zend Framework-е. Представляю перевод этой заметки.

Продолжая обсуждение помощников действий Zend Framework (мой перевод: Использование помощников действий, — прим. пер.), давайте поговорим о перехватчиках в них.

Перехватчики – это особенность помощников действий, которая позволяет вам выполнить некий код в определенных точках цикла диспетчеризации. Собственно, для помощников действий доступно всего два типа перехватчиков:

• preDispatch (): вызывается перед запуском действия
• postDispatch (): вызывается после завершения работы действия

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

Мы начнем с помощника действия в нашем каталоге controllers/helpers, названного Quote:

<?php

class Zend_Controller_Action_Helper_Quote extends Zend_Controller_Action_Helper_Abstract
{
    function preDispatch()
    {
        $view = $this->getActionController()->view;
        $view->footerQuote = $this->getQuote();
    }
    function getQuote()
    {
        $quotes[] = 'I want to run, I want to hide, I want to tear down the walls';
        $quotes[] = 'One man come in the name of love, One man come and go';
        return $quotes[rand(0, count($quotes)-1)];
    }
}

Метод preDispatch() получает объект представления из контроллера действия и присваивает случайную цитату свойству footerQuote этого объекта.

Мы должны сказать брокеру помощников, что мы хотим активировать этот перехватчик. Для этого в дополнение к вызову addPath(), наш загрузочный файл нужно дополнить вызовом addHelper(). После этого загрузчик станет содержать код:

// Action Helpers
    Zend_Controller_Action_HelperBroker::addPath(
        APPLICATION_PATH .'/controllers/helpers');
    $hooks = Zend_Controller_Action_HelperBroker::getStaticHelper('Quote');
    Zend_Controller_Action_HelperBroker::addHelper($hooks);

Пока мы используем addPath() для указания брокеру помощников где искать помощники действий, мы можем использовать getStaticHelper() в качестве простого способа инстанцирования класса без require() и последующего вызова new. Затем мы можем зарегистрировать его с помощью помощника брокера использовав addHelper().

Так как цитата отображается в подвале сайта, требуется внести изменения в HTML-код в layout.phtml:

<div id="footer">
    <div id="quote">
        <?php echo $this->footerQuote; ?>
    </div>
</div>

Вот и все — не сложно, правда?