В новом Zend Framework 1.10 появились переводы для встроенных валидаторов! Ура!
Теперь не нужно переводить самому, как, например, делал я когда-то. Теперь можно тупо:

$language = 'ru';
$translator = new Zend_Translate(
    'array',
    '/resources/languages',
    $language,
    array('scan' => Zend_Locale::LOCALE_DIRECTORY)
);

Zend_Validate_Abstract::setDefaultTranslator($translator);

И всё - радуемся.

Информация из оригинального поста Томаса Вейднера, разработчика i18n в ZF.

UPD: мы с ребятами с zendframework.ru (спасибо им) перевели сообщения валидаторов на русский язык. Ожидается, что наш перевод появится в ZF 1.10.2 (выйдет 23 февраля 2010). Так же, ожидается перевод на украинский язык.

During my research, I found a convenient way to work with html blocks on the site. Almost every site has a number of blocks that should be present on some pages and absent on others. So, you need a flexible tool for managing the blocks.

I will present my vision of how to manage the blocks under Zend Framework.
Read the rest of this entry »

Я обновил статью Блоки в Zend Framework. Финальная версия и добавил в код дополнение, позволяющие передавать параметры главного контроллера в блок.
Это означает, что когда вы находитесь на странице, к примеру, http://example.com/pages/view/777 (где controller - pages, action - view и id - 777), то идентификатор (777) передастся так же в контроллер блока, который вы загружаете на данной странице, где его можно получить стандартным способом: $this->_request->getParam(’id’).

Как работать с несколькими БД в ZF? Давайте посмотрим, начнем с конфигурационного файла. Вы ведь используете компонент Zend_Application? Тогда поехали.

Будем придерживаться правильного подхода в разработке приложений. Давайте создадим такой ini файл с настройками для Zend_Application. В конфиге будет одна общая секция, и 3 секции для разных сред выполнения нашего приложения - development, test и production. В каждой из этих секций мы сможем работать с несколькими БД одновременно.
Read the rest of this entry »

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

Кроме того, я почему-то уверен, что использование декораторов в Zend Form это не лучшее решение. В настоящей действительности все чаще приходится работать с готовой XHTML разметкой, которую предоставляет верстальщик. В таком случае, программисту приходится “переводить” уже сверстанную форму в php-код. Разве это удобно, разве это способствует продуктивности? Никак нет. Просто делается лишняя работа, вместо того, чтобы подставить в нужные места формы вывод ошибок и прочего.

Но как сделать так, чтобы наша форма сохраняла функциональность валидаторов, “зашитых” в ней, и при этом мы могли бы визуально видеть разметку формы? Как ни странно, но в этом нам поможет декоратор! Read the rest of this entry »

Часто приходится видеть, как люди неправильно используют хелперы вида в своих приложениях. В такие хелперы они внедряют большие куски html разметки, даже не понимая, что хелперы вида предназначены совсем не для этого. Посмотрите на код стандартных хелперов вида в Zend Framework - разве они содержат огромные куски разметки? Нет.

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

Если же вам требуется вывести какой-либо большой кусок html разметки в нескольких местах проекта - здесь отлично подойдут партиалы (partials). Они-то как раз и предназначены для решения подобного типа задач. Кстати, за подключение партиала в скрипт вида отвечает хелпер - partial и partialLoop (если требуется вывести партиал в цикле). Почувствуйте разницу.

Если вы еще не использовали партиалы ни разу, вот вам ссылка на официальный мануал, читайте до полного понимания: Partial Helper

Я продолжил свои изыскания на тему блоков в Zend Framework. Я все искал, как сделать работу с блоками на сайте максимально удобной.

До этого, я написал несколько статей, посвященных блокам:

• Меню администратора, или блоки в Zend Framework
• Блоки в Zend Framework
• Блоки в Zend Framework, версия 2

Но не далее, как неделю назад я придумал еще более удобный способ работы с блоками. Некоторые мои предыдущие утверждения я опровергнул :)

Блоки в новой версии так же работают на основе конфига блоков. Но теперь блоки можно как включать, так и отключать в любом месте контроллера. Именно отключения блоков и не было в прошлых версиях - как мне тогда показалось, оно было излишним. Но практика показала, что это не так.

Итак, в этой версии у нас есть помощник действия (action helper) и плагин фронт-контроллера (controller plugin). При помощи помощника действия мы указываем, какие блоки нужно будет загрузить или отключить, а плагин фронт-контроллера управляет непосредственно загрузкой блоков, которая происходит сразу после диспетчеризации действия в контроллере. Read the rest of this entry »

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

Вроде бы всё хорошо, все пользуются и все довольны. Но если подумать, то в ZF валидация располагается не на том уровне, на котором хотелось бы. Я уверен, что валидация входных данных должна производиться именно в моделях и ни в коем случае не в формах, как сделано на даный момент. Почему? Остановимся на этом подробнее. Read the rest of this entry »

По-умолчанию в схеме маршрутизации Zend Framework используется дефолтный маршрут. Он добавляется непосредственно перед началом процесса маршрутизации, в методе Zend_Controller_Router_Rewrite::route()

Дефолтный маршрут - это объект класса Zend_Controller_Router_Route_Module. При создании этого объекта в его конструктор передаются объекты диспетчера и запроса.

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

Если вы собрались переопределить Zend_Controller_Router_Route_Module, то не забывайте при инстанцировании своего класса всегда передавать в него диспетчер и объект запроса - иначе долго будете искать ошибку, почему ничего не работает (как я искал):

$front = Zend_Controller_Front::getInstance();

$front->getRouter()->addRoute('default',
    new My_Controller_Router_Route_Module(
        array(
                'lang'       => 'en',
                'module'     => 'application',
                'controller' => 'index',
                'action'     => 'index',
        ),
        $front->getDispatcher(),
        $front->getRequest()
    )
);

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

Zend_Form - переопределение ошибок.

Иногда требуется в форме установить собственное сообщение об ошибке, когда форма проходит валидацию.

Например, мы хотим проверить, заполнено ли имя пользователя:

$username = $this->createElement('text', 'username');
$username->setRequired();

$username->addValidator('NotEmpty', false, array(
    'messages' => array(
        'isEmpty' => 'EmptyUsername'
    )
));

Видно, как в массиве сообщений мы делаем как бы алиас на нужное нам сообщение. Теперь осталось только добавить в файл с переводами строчку

'EmptyUsername' => 'Введите имя пользователя'

и при валидации, если поле будет пустое, мы увидим переопределенную нами ошибку:

Введите имя пользователя

Вот так вот.