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

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

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

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

Продолжая обсуждение помощников действий 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>

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

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

Первое, что вы должны сделать - решить где разместить их. Последняя версия рекомендаций по стандартной структуре проекта предлагает использовать подкаталоги вашего каталога контроллеров. Т.е. application/controllers/helpers/, и это лучший вариант.

Во-первых, вы должны сказать брукеру помощников где располагаются ваши помощники действий. Я обычно делаю это в загрузчике (bootstrap file), но точно так же можно сделать это и в плагине фронт-контроллера.

    Zend_Controller_Action_HelperBroker::addPath(
        APPLICATION_PATH .'/controllers/helpers');

Затем вы должны создать помощник действий, мы назовем его Multiples в нашем примере, тогда название файла будет application/controllers/helpers/Multiples.php:

<?php

class Zend_Controller_Action_Helper_Multiples extends
                Zend_Controller_Action_Helper_Abstract
{
    function direct($a)
    {
        return $a * 2;
    }
}

Обратите внимание на префикс названия класса помощника действий - Zend_Controller_Action_Helper. Вы можете поменять этот префикс на другой, передав его вторым параметром в функции Zend_Controller_Action_HelperBroker::addPath(), вызвав её в вашем загрузчике.

Наконец, использование в действии контроллера:

<?php

class IndexController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $this->view->headTitle('Home');
        $this->view->title = 'Test of the Multiples action helper';

        $number = 30;
        $twice = $this->_helper->multiples($number);

        $this->view->number = $number;
        $this->view-twice = $twice;
    }
}

Обратите внимание на то, что мы вызываем помощник действия как метод класса _helper. Этот вызов транслируется в вызов метода direct() нашего класса помощника.

Также вы можете написать несколько методов в одном помощнике действий:

class Zend_Controller_Action_Helper_Multiples extends
                Zend_Controller_Action_Helper_Abstract
{
    function direct($a)
    {
        return $a * 2;
    }

    function thrice($a)
    {
        return $a * 3;
    }
}

Для вызова метода thrice() в действии вашего контроллера делайте так:

$thrice = $this->_helper->multiples->thrice($number);

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

Это всего лишь общие сведения для начала освоения. За подробностями обращайтесь к руководству.

Удачи и избегайте копи-паста общей функциональности!

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

Что же нового появилось? Пока могу лишь предполагать на основе сравнения кода первого и второго кандидатов:

• Добавили класс для работы с капчей и соответствующее поле для формы
• Добавили поддержку FirePHP (расширения FireBug) для Zend_Log и Zend_Db_Profiler
• Добавили новые хелперы для Dojo
• Добавили класс загрузки файлов и поле для Zend_Form + валидаторы
• … и масса изменений в остальных классах…

Пробуем и ждем релиз?

Из интересного лично мне:

• класс для поддержки модульного тестирования контроллеров
• паджинатор
• Zend File Transfer

Кроме того:

• интеграция с JS-фреймворком Dojo
• SOAP
• поддержка формата файлов индексов Lucene 2.3
• Zend_Session теперь может хранить данные в БД
• поддержка Text/Figlet
• поддержка компонентом Zend_Config_Xml атриботов
• установка кодировки соединения в адаптере БД
• новые хелперы видов для медиа-форматов
• поддержка компонентом Zend_Translate INI-файлов

Новость на английском - Zend Framework 1.6 Release Candidate 1 now available!

Разработчики предостерегают от использования этого релиза в продакшене — релиз предназначен для ознакомления с нововведениями в ветке 1.6 и еще не стабилен.

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

Прежде, чем начать

Хоть я и старался сохранить статью простой, это не значит, что тут будет введение в обе технологии. Я предлагаю вам поиграть с обеими технологиями по отдельности, прежде чем пытаться объединить их. Они обе имеют достаточно хорошую документацию, что бы с нее начать: Zend Framework Quick Start и Doctrine’s My First Project. Кроме того, Akra’s Zend Framework Tutorial (“Введение в Zend Framework” - перевод от Александра Мусаева) тоже очень хорошее введение в тему.

Zend Framework имеет “используй-как-хочешь” архитектуру. Это значит, что вы свободны в использовании только тех частей, которые вам нужны, в отличии от других фреймворков, предлагающих решения “все-или-ничего”. Эта архитектура (используй-как-хочешь) великолепна: она позволяет нам разрабатывать настоящие Zend Framework приложения, без использования ZF абстракции от БД (Zend_Db). Хотя Zend_Db не плохая технология, она все еще довольно низкоуровневая, и слишком близка к базе данных. Используя Doctrine, вы можете манипулировать вашими данными как объектами, не слишком беспокоясь о базе данных.

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

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

Сначала мы создадим типовую структуру проекта и установим библиотеки. Откройте файл-менеджер и создайте структуру папок, как показано ниже. Я объясню, назначение этих папок через минуту.

Типовая структура папок

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

• application/doctrine/ — в ней содержаться все файлы данных Doctrine, такие как sql и yaml схемы бд, миграции, дампы, и т.п.
• application/models/ — Doctrine будет автоматически генерировать файлы моделей в этой директории, что легко использовать в рамках вашего Zend Framework приложения.
• library/ — как правило, вы бы просто установить свою копию Zend Framework в эту папку. В нашем приложении нам нужны две библиотеки: Zend Framework и Doctrine. Таким образом, мы делаем два подкаталога и устанавливаем туда библиотеки.
• scripts/ — Doctrine поставляется с удобнымм скриптами командной строки (делее просто “скрипты доктрины”), мы будем хранить их здесь (как в предложении, упомянутом выше).

Следующий шаг — установка Zend Framework и Doctrine. Загрузите последнюю версию с соответствующих веб-сайтов и разархивируйте library (для ZF) или lib (для Doctrine) в созданные нами папки. Должно получиться приблизительно следующее:

Zend Framework и Doctrine установлены

Время заняться загрузочным файлом

Если вы помните по Zend Framework Quick Start, мы должны создать загрузочный файл. Мы сделаем это сейчас, но с некоторыми изменениями, с тем, чтобы использовать Doctrine.

Во-первых, мы создадим файлы public/index.php и public/.htaccess. Запустите ваш любимый редактор и скопируйте следующие куски кода:

public/index.php

<?php
require '../application/bootstrap.php';

public/.htaccess

RewriteEngine on

RewriteCond %{SCRIPT_FILENAME} !-f
RewriteRule ^(.*)$ index.php/$1

Как вы видите, все так же, как и в любом приложении на базе Zend Framework.

Файл application/bootstrap.php выглядит немного иначе. Я разделил его на два файла: application/bootstrap.php и application/global.php. Первый занимается обработкой запросов клиентов, последний подключает все необходимые файлы. Я разделил их потому, что код из global.php нужен также в скриптах Doctrine (которое мы увидим через минутку).

application/global.php

<?php
error_reporting(E_ALL | E_STRICT);
ini_set('display_startup_errors', 1);
ini_set('display_errors', 1);
date_default_timezone_set('Europe/Brussels');

/*
* Setup libraries & autoloaders
*/
set_include_path(dirname(__FILE__).'/../library/zendframework'
    . PATH_SEPARATOR . dirname(__FILE__).'/../library/doctrine'
    . PATH_SEPARATOR . dirname(__FILE__).'/models'
    . PATH_SEPARATOR . dirname(__FILE__).'/models/generated'
    . PATH_SEPARATOR . get_include_path());
require 'Zend/Loader.php';
Zend_Loader::registerAutoload('Zend_Loader');

/*
* Set super-global data
*/
Doctrine_Manager::connection("mysql://user:pass@localhost/database");

/*
* Configure Doctrine
*/
Zend_Registry::set('doctrine_config', array(
    'data_fixtures_path'  =>  dirname(__FILE__).'/doctrine/data/fixtures',
    'models_path'         =>  dirname(__FILE__).'/models',
    'migrations_path'     =>  dirname(__FILE__).'/doctrine/migrations',
    'sql_path'            =>  dirname(__FILE__).'/doctrine/data/sql',
    'yaml_schema_path'    =>  dirname(__FILE__).'/doctrine/schema'
));

application/bootstrap.php

<?php
require dirname(__FILE__).'/global.php';

Zend_Controller_Front::run(dirname(__FILE__).'/controllers');
?>

Давайте рассмотрим его шаг за шагом:

<?php
error_reporting(E_ALL | E_STRICT);
ini_set('display_startup_errors', 1);
ini_set('display_errors', 1);
date_default_timezone_set('Europe/Brussels');
?>

Это всегда хорошая идея — установить правильную обработку ошибок и часовой пояс. Здесь ничего особенного.

<?php
/*
* Setup libraries & autoloaders
*/
set_include_path(dirname(__FILE__).'/../library/zendframework'
    . PATH_SEPARATOR . dirname(__FILE__).'/../library/doctrine'
    . PATH_SEPARATOR . dirname(__FILE__).'/models'
    . PATH_SEPARATOR . dirname(__FILE__).'/models/generated'
    . PATH_SEPARATOR . get_include_path());
require 'Zend/Loader.php';
Zend_Loader::registerAutoload('Zend_Loader');
?>

Именно здесь мы подключаем Doctrine. Как вы видите, мы установили include_path для подключения Zend Framework и Doctrine. Мы также подключили папки, в которых Doctrine будет генерировать файлы моделей. Заметим, что нам не нужно настраивать автозагрузчик Doctrine. Использование загрузчика Зенда работает так же хорошо, до тех пор, пока include_path настроен правильно. Предупреждение: в текущей версии ZF (1.5.1) есть ошибка, приводящая к печати безобидных предупреждений при использовании классов шаблонов Doctrine. Она должна быть исправлена в будущих версиях.

<?php
/*
* Set super-global data
*/
Doctrine_Manager::connection("mysql://user:pass@localhost/database");

/*
* Configure Doctrine
*/
Zend_Registry::set('doctrine_config', array(
    'data_fixtures_path'  =>  dirname(__FILE__).'/doctrine/data/fixtures',
    'models_path'         =>  dirname(__FILE__).'/models',
    'migrations_path'     =>  dirname(__FILE__).'/doctrine/migrations',
    'sql_path'            =>  dirname(__FILE__).'/doctrine/data/sql',
    'yaml_schema_path'    =>  dirname(__FILE__).'/doctrine/schema'
));
?>

Это последний кусочек кода. Во-первых, мы создали соединение с базой данных. Чтобы не усложнять, я просто забил в код это строковое значение. В реальных системах вы должны использовать что-нибудь подобное Zend_Config. Я оставлю это вам в качестве домашнего задания. Во-вторых, этот кусок кода настраивает пути к инструментам Doctrine для командной строки (которые генерируют весь код и схемы баз данных). Я сохранил этот массив в Zend_Registry, который является универсальным хранилищем, местом, где вы можете хранить объекты и получить их в нужный момент.

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

Содержимое файла application/bootstrap.php не должно вызывать у вас удивления. Опять же, я пытался сохранить этот пример как можно более простым.

Наконец, давайте настроим интерфейс командной строки Doctrine:

scripts/doctrine-cli

#!/usr/bin/env php
<?php
require dirname(__FILE__).'/../application/global.php';

$cli = new Doctrine_Cli(Zend_Registry::get('doctrine_config'));
$cli->run($_SERVER['argv']);

Сделайте этот сценарий исполняемым:

chmod +x scripts/doctrine-cli

и вы готовы двигаться дальше.

Создание приложения

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

Мы будем делать это очень просто: только один контроллер и один скрипт. Скопируйте следующие файлы:

application/views/scripts/index/index.phtml

<html>
<head>
    <title>ZF & Doctrine example</title>
</head>

<body>
<h1>Submit a message:</h1>
<?=$this->form?>

<hr />
<h1>Messages posted:</h1>
<!-- TODO: Show messages here -->
</body>
</html>

application/controllers/IndexController.php

<?php
class IndexController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $form = $this->getForm();
        $req = $this->getRequest();
        if ($req->getPost() && $form->isValid($req->getPost())) {
            // TODO: Insert message into database
        }
        $this->view->form = $form;

        // TODO: Retrieve all messages.
    }

    private function getForm()
    {
        $form = new Zend_Form();
        $form->addElement('text', 'name', array(
                'label' => 'Your name',
                'required' => true
        ));
        $form->addElement('textarea', 'message', array(
                'label' => 'Message',
                'required' => true,
                'rows' => 4
        ));
        $form->addElement('submit', 'send');
        return $form;
    }
}
?>

Как вы видите, остались три больших TODO пункта: один в скрипте и два в контроллере. Это места, где мы будем подключать Doctrine. Но для этого мы должны в первую очередь определить некоторые объекты данных. Мы вернемся к контроллеру и скрипту позже, сейчас пришло время для создания схемы базы данных.

Определение схемы базы данных

Doctrine позволяет указать ваши схемы баз данных в YAML-файлах, очень простом текстовом представлении. Мы воспользуемся этим и пусть Doctrine генерирует PHP-файлы автоматически. Я определил следующие схему:

application/doctrine/schema/schema.yml

Message:
    columns:
        id:
            primary: true
            autoincrement: true
            type: integer(4)
        posted:
            type: timestamp
        name:
            type: string(255)
        message:
            type: string

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

Теперь мы можем использовать командную строку Doctrine для создания файлов моделей и таблиц баз данных. Из вашего шелла выполните следующее:

$ ./scripts/doctrine-cli generate-models-yaml
generate-models-yaml - Generated models successfully from YAML schema
$ ./scripts/doctrine-cli generate-sql
generate-sql - Generated SQL successfully for models
$ ./scripts/doctrine-cli create-tables
create-tables - Created tables successfully

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

Соеденим все вместе

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

<?php
// TODO: Insert message into database
?>

Вот этим (игнорируя тэги <?php и ?>):

<?php
$message = new Message();
$message->fromArray($form->getValues(true));
$message->posted = new Doctrine_Expression('NOW()');
$message->save();
?>

Как вы видите, мы используем объект класса Сообщение. Этот класс был автоматически сгенерирован Doctrine. Вы можете найти его в application/models/. Автозагрузчик позаботится о загрузке всего, что потребуется.

Мы также должны получать сообщения, чтобы показать их. Во-первых, контроллер. Заменить:

<?php
// TODO: Retrieve all messages.
?>

На:

<?php
$messages = Doctrine_Query::create()
        ->from('Message m')
        ->orderBy('m.posted DESC')
        ->execute();
$this->view->messages = $messages;
?>

Опять же, это очень просто. Я использовал DQL запрос, чтобы сортировать в обратной хронологической последовательности.

Теперь все, что осталось — показать сообщение в нашем скрипте представления. Опять же, замените:

<!-- TODO: Show messages here -->

На:

<?php foreach ($this->messages as $message): ?>
    <h2><?=$message->name?> (<?=$message->posted?>)</h2>
    <?=$message->message?>
<?php endforeach; ?>

И мы сделали, результат должен выглядеть подобно этому:

Завершенное приложение

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

Заключение

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

Если у Вас есть какие-либо замечания, комментарии или вопросы, не стесняйтесь, пишите мне по электронной почте (ruben@savanne.be), или оставляйте комментарий в моем блоге.

Приложение: Полный код файлов

application/controllers/IndexController.php

<?php
class IndexController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $form = $this->getForm();
        $req = $this->getRequest();
        if ($req->getPost() && $form->isValid($req->getPost())) {
            $message = new Message();
            $message->fromArray($form->getValues(true));
            $message->posted = new Doctrine_Expression('NOW()');
            $message->save();
        }
        $this->view->form = $form;

        $messages = Doctrine_Query::create()
            ->from('Message m')
            ->orderBy('m.posted DESC')
            ->execute();
        $this->view->messages = $messages;
    }

    private function getForm()
    {
        $form = new Zend_Form();
        $form->addElement('text', 'name', array(
                'label' => 'Your name',
                'required' => true
        ));
        $form->addElement('textarea', 'message', array(
                'label' => 'Message',
                'required' => true,
                'rows' => 4
        ));
        $form->addElement('submit', 'send');
        return $form;
    }
}
?>

application/views/scripts/index/index.phtml

<html>
<head>
    <title>ZF & Doctrine example</title>
</head>

<body>
    <h1>Submit a message:</h1>
    <?=$this->form?>

    <hr />
    <h1>Messages posted:</h1>
    <?php foreach ($this->messages as $message): ?>
        <h2><?=$message->name?> (<?=$message->posted?>)</h2>
        <?=$message->message?>
    <?php endforeach; ?>
</body>
</html>

В первой части (Интеграция Zend_Acl и MVC. Часть 1) мы говорили о том, как настроить экземпляр Zend_Acl и включить его в окружение MVC (с использованием плагина фронт-контроллера). Но как же настройки других действий для блокирования доступа, или как сделать редактирование статьи только её автором? Это и кое-что еще будет рассмотрено далее.

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

1. Использование модулей

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

Общий модуль

1. Контроллер пользователей.
2. Контроллер статей.

Административный модуль

1. Контроллер статей.
2. Контроллер коротких ссылок.
3. Контроллер категорий.

Основываясь на этой новой модели ресурсов, мы создадим экземпляр Zend_Acl, который будет отражает её.

Примечание: помните, что этот код и создание экземпляра объекта Zend_Acl должно исполняться перед вызовом метода диспетчеризации фронт-контроллера (во время загрузки).

/** Creating Roles */
require_once 'Zend/Acl/Role.php';
$myAcl->addRole(new Zend_Acl_Role('guest'))
      ->addRole(new Zend_Acl_Role('writer'), 'guest')
      ->addRole(new Zend_Acl_Role('admin'), 'writer');

/** Creating resources */
require_once 'Zend/Acl/Resource.php';
/** Default module */
$myAcl->add(new Zend_Acl_Resource('user'))
      ->add(new Zend_Acl_Resource('article'));

/** Admin module */
$myAcl->add(new Zend_Acl_Resource('admin'))
      ->add(new Zend_Acl_Resource('admin:article', 'admin'))
      ->add(new Zend_Acl_Resource('admin:quick-link', 'admin'))
      ->add(new Zend_Acl_Resource('admin:category', 'admin'));

/** Creating permissions */
$myAcl->allow('guest', 'user')
      ->deny('guest', 'article')
      ->allow('guest', 'article', 'view')
      ->allow(array('writer', 'admin'), 'article', array('add', 'edit'))
      ->allow('admin', 'admin');

/** Setting up the front controller */
require_once 'Zend/Controller/Front.php';
$front = Zend_Controller_Front::getInstance();
$front->setControllerDirectory(array('default' => 'path/to/default/controllers',
                                     'admin' => 'path/to/admin/controllers'));

/** Registering the Plugin object */
require_once 'Zend/Controller/Plugin/Acl.php';
$front->registerPlugin(new Zend_Controller_Plugin_Acl($myAcl, 'guest')); 

/** Dispatching the front controller */
$front->dispatch();

Отмечу, что как и раньше, мы создали ресурс для каждого контроллера. Но в случае с модулем администратора, мы создали ресурс для модуля и по одному для каждого контроллера внутри этого модуля в формате “модуль:контроллер”, сделав их потомками ресурса модуля. Так же мы сделали роль Администратор единственной, кому разрешен доступ ко всему модулю администрирования.

2. Использование ролей

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

Контроллер пользователей

class UserController extends Zend_Controller_Action
{
    protected $_application;

    public function init()
    {
        require_once 'Zend/Session/Namespace.php';
        $this->_application = new Zend_Session_Namespace('myApplication');
    }

    public function loginAction()
    {
        ... Validation code
        if ($valid) {
            /** Setting role into session */
            $this->_application->currentRole = $user->role;
            $this->_application->loggedUser = $user->username;
        }
    }

    public function logoutAction()
    {
        $this->_application->currentRole = 'guest';
        $this->_application->loggedUser = null;
    }
}

Файл-загрузчик

/** Loading application from session */
require_once 'Zend/Session/Namespace.php';
$application = new Zend_Session_Namespace('myApplication');

if (!isset($application->currentRole)) {
    $application->currentRole = 'guest';
}

/** Setting up the front controller */
require_once 'Zend/Controller/Front.php';
$front = Zend_Controller_Front::getInstance();
$front->setControllerDirectory('path/to/controllers'); 

/** Registering the Plugin object */
require_once 'Zend/Controller/Plugin/Acl.php';
$front->registerPlugin(new Zend_Controller_Plugin_Acl($myAcl, $application->currentRole));

/** Dispatching the front controller */
$front->dispatch();

3. Установка действия при ошибке “запрет доступа”

Может быть, некоторым из вас (надеюсь, никому =D) просто не нравится идея иметь действие “Доступ запрещен” в контроллере ошибок, или просто хочется назвать его как-либо иначе. Это можно сделать, вызвав метод setErrorPage плагина фронт-контроллера.

/** Setting up the front controller */
require_once 'Zend/Controller/Front.php';
$front = Zend_Controller_Front::getInstance();
$front->setControllerDirectory('path/to/controllers'); 

/** Setting default access denied action */
require_once 'Zend/Controller/Plugin/Acl.php';
$aclPlugin = new Zend_Controller_Plugin_Acl($myAcl, 'guest');
$aclPlugin->setErrorPage('goaway', 'my-error-controller', 'my-module'); 

/** Registering the Plugin object */
$front->registerPlugin($aclPlugin); 

/** Dispatching the front controller */
$front->dispatch();

Метод setErrorPage может вызываться с указанием только имени действия. В этом случае контроллер и модуль останутся “error” и “default”. Так же метод может вызываться с передачей названий действия и контроллера, либо передав все три параметра.

4. Использование помошника действий

Наконец, мы увидим один из наиболее важных частей этого предложения. До сих пор в нашем примере ДевЗоны мы видели, что мы разрешаем администраторам и авторам редактировать статьи. Но постойте, есть еще недостающая часть нашего приложения. Сейчас если я автор и имею доступ к article/edit/:id, это значит, что я имею доступ к редактированию не только своих статей, но и статей остальных авторов! Это не очень хорошо, так ведь? Итак, что мы будем с этим делать? Мы будем управлять этим используя помощник действий, а это значит, что вы сможете получить доступ к нашим ACL внутри любого контроллера, а не только во время загрузки.

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

Файл-загрузчик

/** Loading application from session */
require_once 'Zend/Session/Namespace.php';
$application = new Zend_Session_Namespace('myApplication');

if (!isset($application->loggedUser)) {
    $application->loggedUser = null;
}

/** Setting up the front controller */
require_once 'Zend/Controller/Front.php';
$front = Zend_Controller_Front::getInstance();
$front->setControllerDirectory('path/to/controllers'); 

/** Registering the Plugin object */
require_once 'Zend/Controller/Plugin/Acl.php';
$front->registerPlugin(new Zend_Controller_Plugin_Acl($myAcl, $application->currentRole)); 

/** Registering the Action Helper object */
require_once 'Zend/Controller/Action/Helper/Acl.php';
require_once 'Zend/Controller/Action/HelperBroker.php';
Zend_Controller_Action_HelperBroker::addHelper(new Zend_Controller_Action_Helper_Acl()); 

/** Dispatching the front controller */
$front->dispatch();

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

Контроллер статей

class ArticleController extends Zend_Controller_Action
{
    protected $_acl;
    protected $_application;

    public function init()
    {
        /** Get our Action Helper */
        $this->_acl = $this->_helper->getHelper('acl'); 

        require_once 'Zend/Session/Namespace.php';
        $this->_application = new Zend_Session_Namespace('myApplication');
    } 

    ...

    public function editAction()
    {
        /** Load article by id */
        $article = new Article($this->_request->id);

        /** Validate if the user is the owner or an Admin */
        if (($article->author != $this->_application->loggedUser)
             && ($this->_application->currentRole != 'admin')) {
            $this->_acl->denyAccess();
        } 

        ...
    }
}

Заключение

Некоторые любители копошиться в мусоре всю свою жизнь пытаются найти недостающее звено (и они так и умрут в поиске его) и некоторые ЗФ-еры состарятся в попытках заставить работать ACL должным образом в их MVC-окружении. Надеюсь, высказанное выше предложение, может оказаться одним из недостающих кусочков в мире ACL + MVC.

В заключении хочу дать рекомендацию. Придерживайтесь принципа “Делай проще”: если вам не нужна позарез динамическая загрузка ACL, то его загрузка и настройка вручную - совсем не грех, возможно это лучший способ действий в данной ситуации.

Для более подробного ознакомления с темой вы можете почитать следующее:
Zend_Acl & MVC Integration
и небольшой пример реализации подхода, описанного в статье:
Source Code

Итак, что не так с Zend_Acl и текущей реализацией MVC в Zend Framework? Ничего неправильного нет, просто не слишком очевидно для разработчиков, как достичь оптимальной интеграции между этими двумя важными частями фреймворка.

Во-первых, эта статья основана на следующем предложении (link), в настоящий момент находящемся в стадии Ожидания рекомендации.

Ну, как это работает? Существуют два основных компонента в этом предложении:

1. Плагин фронт-контроллера (Front Controller Plugin): этот компонент решает, имеет ли доступ текущий пользователь к открываемой странице.
2. Помощник действия (Action Helper): Этот компонент позволяет проверить, имеет ли текущий пользователь доступ внутрь контроллера.

Опираясь на эти два компонента, давайте попробуем их на примере. Давайте будем говорить о сайте, подобном DevZone.
Нам потребуется контроллер для управления пользователями и еще один контроллер для управления статьями, так же 3 типа пользователей (ролей): одну для гостей, одну для авторов статей и еще одну для утверждения статей. Итого, мы имеем:

Ресурсы:

1. Контроллер пользователей.
2. Контроллер статей.

Роли:

1. Гость (Guest).
2. Автор (Writer).
3. Администратор (Admin).

Настройка компонента Zend_Acl

После определения того, что нам нужно сделать, следующим шагом будет создание экземпляра Zend_Acl, отражающего нашу модель.

/** Creating the ACL object */
require_once 'Zend/Acl.php';
$myAcl = new Zend_Acl();

Создание ролей

Сейчас мы создадим роли в нашем экземпляре Zend_Acl.

/** Creating Roles */
require_once 'Zend/Acl/Role.php';
$myAcl->addRole(new Zend_Acl_Role('guest'))
      ->addRole(new Zend_Acl_Role('writer'), 'guest')
      ->addRole(new Zend_Acl_Role('admin'), 'writer');

Создание ресурсов

Создадим необходимые ресурсы (по одному на контроллер), а также их отношения с созданными нами ролями.

/** Creating resources */
require_once 'Zend/Acl/Resource.php';
$myAcl->add(new Zend_Acl_Resource('user'))
      ->add(new Zend_Acl_Resource('article'));

Создание привилегий

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

1. Гости не могут редактировать, добавлять и публиковать статьи.
2. Авторы не могут публиковать статьи.
3. Администраторы имеют полный доступ.

/** Creating permissions */
$myAcl->allow('guest', 'user')
      ->deny('guest', 'article')
      ->allow('guest', 'article', 'view')
      ->allow('writer', 'article', array('add', 'edit'))
      ->allow('admin', 'article', 'approve');

Создание страницы, отображаемой при отсутствии доступа

Нам нужно будет создать представление (view) и действие (action) на которое мы переадресуем всех пользователей, у которых недостаточно привилегий.
Во-первых, мы создадим новое действие в нашем контроллере ошибок:

class ErrorController extends Zend_Controller_Action
{
    ....

    public function deniedAction()
    {
    }

    ....
}

Затем мы создадим наш файл представления (/application/views/scripts/error/denied.phtml) с некоторым предупреждающим сообщением:

<h1>Error</h1>
<h2>Access denied</h2>
<p>You are trying to access an area which you have not allowed.</p>

Завершение настройки

Хорошо, мы настроили наш экземпляр Zend_Acl. Следующий шаг - регистрация плагина контроллера. Это важная часть берет созданный нами экземпляр Zend_Acl и проверяет, доступна ли текущая страница пользователю.

/** Setting up the front controller */
require_once 'Zend/Controller/Front.php';
$front = Zend_Controller_Front::getInstance();
$front->setControllerDirectory('path/to/controllers'); 

/** Registering the Plugin object */
require_once 'Zend/Controller/Plugin/Acl.php';
$aclPlugin = new Zend_Controller_Plugin_Acl($myAcl);
$aclPlugin->setRoleName($currentUserRole);

$front->registerPlugin(new Zend_Controller_Plugin_Acl($acl, 'guest')); 

/** Dispatching the front controller */
$front->dispatch();

После завершения настройки, как только пользователь войдет в наше приложение, в зависимости от его/её роли будет либо отображена запрошенная страница, либо страница с сообщением о запрете доступа.

Для более подробного ознакомления с темой вы можете почитать следующее:
Zend_Acl & MVC Integration

и небольшой пример:
Source Code

Погуглив и проведя ряд экспериментов у меня получилось вот что.

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

• “Обмен данными для документов с разных доменов“,
• “Remote JSON - JSONP“,
• “JSONP: JSON With Padding“
• и применительно к jQuery статья “jQuery и Ajax: запросы“

Итак, для отправки запросов я воспользуюсь библиотекой jQuery. С версии 1.2 эта библиотека поддерживает JSONP нативно. Вот, собственно сам код для выполнения запроса:

$.getJSON("http://server.ru/logger.php?callback=?", function(data){
    // тут обрабатываем полученные данные
});

Обратите внимание на параметр “callback=?” в адресе, на который отправляется запрос. Вместо вопроса jquery подставит название callback-функции. Эта callback-функция будет вызвана при получении ответа от сервера. Учтем это в серверной части.

<?php
    echo $_GET['callback']."({param1:'value',param2:0});";
?>

Т.е. выход скрипта должен генерировать не просто JSON, а вызов callback-функции и передачей ей параметров, которые нужно передать от сервера клиенту.

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

Мне последнее время приходится достаточно плотно заниматься разработкой на отличном javascript-фреймворке ExtJS и, в частности, много работать с таблицами. Чтобы визуально приукрасить и сделать таблицы более юзабельными я сделал для них т.н. “зебру”, т.е. чересстрочную раскраску. Далее я расскажу как это сделать.

Я не буду приводить полный код таблицы, только тот кусок, который отвечает за “зебру”:

Example.grid = Ext.extend(Ext.grid.GridPanel, {
    initComponent:function() {
        Ext.apply(this, {
            store:....,
            columns:...,
            viewConfig: {forceFit: true}
        });
        Example.grid.superclass.initComponent.apply(this, arguments);
    },
    onRender:function() {
        Example.grid.superclass.onRender.apply(this, arguments);
        this.getView().getRowClass = function(record,index) {
            return (index%2)?'odd':'even';
        }
    }
});

За создание “зебры”, собственно, отвечает код, расположенный в обработчике события “onRender”. Этот код определяет функцию “getRowClass” объекта GridView нашей таблицы. Определяемая функция должна возвращать название css-класса, которое будет присвоено текущей строке. Эта функция будет вызвана для каждой строки, а на вход ей будет переданы текущая запись и номер строки. Для зебры достаточно знать номер строки и в зависимости от четности этого номера вернуть то или иное название класса. Не забудьте определить эти классы в своем файле стилей, иначе никаких визуальных изменений не увидите.

Второй день начался с достаточно продолжительного и насыщенного доклада сотрудника Google Маркуса Бёргера (Marcus Börger) об объектно-ориентированном программировании на PHP и применении SPL. В первой части Маркус провел ликбез на тему ООП в PHP. Во второй части подробнее рассказал о SPL и её применении.

После Маркуса выступили два представителя мелкомяхких: Алексей Шуленин (Бесплатная версия SQL Server и ее использование в веб-приложениях) и Андрей Бешков (Powershell – скриптовый язык будущего). Любопытные, но бесполезные доклады.

Затем был доклад Светы Смирнова из MySQL. Рассказала о наиболее частых проблемах и их решениях. Было интересно послушать.

Потом отжигал Аксенов Андрей - автор поискового движка “Сфинкс”. С шутками и прибаутками рассказал о особенностях работы сфинкса и его оптимизации. Для меня было полезно, т.к. я работал со сфинксом и некоторые грабли уже успел словить.

Далее выступила комманда из MySQL. 4 человека отвечали на вопросы, присланные желающими.

А затем была половина доклада о XMLDB Sedna. Я с задачами работы с Native XMLDB не сталкивался, поэтому было мало интересно. Половина доклада была по причине подвоза пива. Организаторы быстренько свернули выступление, провели розыгрыш призов и отправили всех дринькать Пилснер.

Вот пожалуй и все о втором дне. Кстати, уже по прошествии месяца материалов конференции на сайте нет :(

В качестве бонуса, в блоге “С Windows XP на Ubuntu Linux” выложены больше 30 видеоуроков по Linux. Качество, правда, не очень хорошее, но полезность однозначна. А на сайте ZendFramework.RU опубликован неплохой туториал по разработке приложений на ZF 1.5 - “Построение простого сайта на базе Zend Framework“.

Это мое первое посещение PHPConf, поэтому дать оценку, стала ли конференция сильнее или нет, я не смогу. Но впечатления от первого дня остались очень положительные.

Сначала опишу мои впечатления от докладов.

• Что нового в PHP-5.3 (Дмитрий Стогов, программист Zend Technologies) — доклад состоял из перечисления нововведений в следующей версии PHP. Почти ничего нового для себя я не услышал, кроме введения новой библиотеки для работы с MySQL (пока, правда, PDO не поддерживается - только расширения mysql и mysqli) и введение технологии, аналогичной .htaccess (т.е. возможность указать директивы php в привязке к каталогу). Выступал Дмитрий хорошо, слушать было интересно, хоть и полезного вынес мало.
• Управление Данными (Data management) (Михаил Красовский, Oak Ridge National Laboratory) — доклад об организации управлением и обработкой данных. Материал доклада был в большей степени теоретическим - фактически представлял абстрактную основу для построения качественной системы управления данными. Михаилу удалось в своем докладе донести четкую схему построения систем обработки огромных массивов данных, сделал это простым и живым языком, в меру разбавляя материал примерами из своей практики. Доклад оставил отличные впечатления.
• Zend Engine изнутри (Дмитрий Стогов, программист Zend Technologies) — доклад был очень прикладным, описывал нюансы реализации ZE и примеры написания собственных расширений. Тема доклада была уж очень специфичной, лично мне пользы было мало - еще не дорос до таких вещей.
• Как сохранить данные в браузере? (Илья Кантор, автор http://javascript.ru) — доклад о принципах реализации и применении технологии BrowserPersistence (хранение на стороне клиента большого количества данных, порядок - мегабайт и более). Доклад хороший, технология интересная, но применять её стоит с осторожностью. (кстати, Илья выложил презентацию доклада, желающие забирают обновленный доклад по хранению данных в браузере)
• Оптимизация запросов в PostgreSQL (Борзов Алексей [SadSpirit], независимый разработчик, ведущий раздела PostgreSQL на PHPClub.ru) — доклад весьма информативный и полезный, жаль что не для меня. в целом, думаю, использующим PostgreSQL была несомненная польза от доклада.
• От стартапа до highload: Эволюция веб-проекта или как победить нагрузку (Антон Терехов, ведущий инженер-программист, ООО “Медиа Мир” (РБК)) — ретроспектива развития фотохостинга PhotoFile.ru: начальное состояние проекта, этапы развития, текущие архитектурные решения и их результаты. Весьма интересный и познавательный доклад. 55 файл-серверов и столько же бэкап-серверов — это впечатляет (не рекорд, конечно, но тем не менее).
• Трансляция флэш-видео (Большов Виктор, ведущий разработчик, компания “Chronopay”) — это был скорее не доклад, а мастер-класс на тему организации потокового вещания на веб-сайте. Занятно, но пока мне применить негде. В целом доклад неплох.

Далее был заявлен доклад на тему “Zend_Memory“, но его небыло. Вместо этого было два доклада: о работе с гео-данными в mysql и о построении XML-XSLT шаблонизатора. К сожалению ни точного названия докладов, ни имен докладчиков я не запомнил. Надеюсь, все презентации разместят на сайте конференции, тогда дополню этот пост. Впечатления: первый понравился и был полезным, второй не понравился.

Особо впечатлил обед - шведский стол с массой разносолов (салаты, мясная и рыбная нарезка, второе и гарниры, десерты, соки и кофе/чай). Все было вкусно. Остался очень довольным. Особенно если сравнить с организацией обедов на РИТ-е.

По сравнению с РИТ-ом, PHPConf более специализированная конференция. Она в большей степени отвечает моим профессиональным интересам.

На сегодня все. Завтра будет заметка о впечатлениях от второго дня. До встречи!

Upd:Доклад о XML-XSLT принадлежит Сергею Антонинко (компания UMISoft)

Похоже, что от индустрии веб-разработок отличается мало ;)

Мои заметки о РИТе вызвали определенный интерес и подняли количество посетителей в два раза. Кстати, я удивился когда не обнаружил ни одного поста на тему РИТа среди ленты фидов, на которы подписан. Странная ситуация.

А теперь хочу поблагодарить коллег-блогеров (и один сервис :) ):

• Пискун Юрий (<ё> YoYurec Field </ё>) — довольно интересный блог на тему веб-девелопмента,
• Поиск по блогам Яндекса (http://blogs.yandex.ru/) — много запросов о РИТе,
• Стаценко Владимир (http://www.simplecoding.org/) — коллега на ниве просвещения в области контроля версий,
• MySVN — Subversion-hosting

Эти блоги и сайты в апреле привели ко мне подавляющее число читателей. Спасибо!

К началу первого выступления мне снова не удалось подъехать, но в этот раз я опоздал всего на 5-7 минут. Проблема заключалась в транспорте — он хоть и был бесплатный, но совершенно непонятно было где его искать, единственным ориентиром было указание на метро “Тушинская”. Однако мест остановки автобусов там достаточно много, а интервал движения заявлен раз в 20 минут, было совершенно непонятно где их искать (за это “минус” организаторам). К счастью минут за 15 мне таки удалось точно отыскать место посадки. А вот находчивость ответственного за организацию доставки людей заслуживает всяческих похвал. Этот молодой человек, видя что желающих уехать много и времени уже много, а следующий автобус будет только через 20 минут, договаривается с водителями стоящих рядом маршрутных такси. После этого люди спокойно едут в “Крокус Экспо”, а не мерзнут на остановке, дожидаясь следующего автобуса (а кому-то могло и в нем не хватить мест). Могу только выразить искреннюю благодарность за хорошую работу.

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

• Модерируемые справочники (Дмитрий Котеров) — интересный доклад о методике двухуровневой модерации различных справочников. Материал по большей части теоритический, но послушать было интересно.
• Инструменты Oracle для разработки небольших web-приложений (Олег Оленин). Доклад о целесообразности применения бесплатного решения от компании Oracle, а именно о Oracle 10g XE и Oracle Application Express. Выступление носило рекламный характер — описывались плюсы именно СУБД от Oracle, развенчивались “мифы”, ну и т.п. Хотя, честно говоря, после доклада мне захотелось попробовать вернуться к использованию оракловой СУБД, благо опыт есть достаточно большой, а в ограничения бесплатной версии я упереться не должен. К сожалению, времени на доклад нехватило катастрофически (приблизительно часов 5, судя по заготовленному материалу :) ). И еще одно сожаление — на сайте нет презентации этого доклада, увы.
• Супер-доклады сделал Алексей Могилевский &mdash “Презентация IE8″ и “CSS - как делаются стандарты”. Алексей выступал очень живо, весело и интересно. Немного рассказал что сделано в IE8, что будет сделано и чего точно не будет сделано. Приоткрыл “кухню” разработки стандарта CSS, поделился планами и сроками реализации. Показал несколько “вкусностей” из грядущего через 3-4 года CSS3. Зал принял Алексея очень тепло, и часто поддавался на провокации докладчика бурными аплодисментами.

На этом, пожалуй, понравившиеся мне доклады закончились. Мастер-класс Сергея Чикуенока на тему создания анимации без использования Flash, оставил после себя недоумение. Сергей 3/4 времени описывал проблемы, связанные с особенностями Flash, и достоинства применения java-script. Оставшееся время бегло перечислил js-фреймворки, в том числе и свой собственный, и показал четыре примера анимации, реализованной с помощью JS. На мой взгляд, мастер-класс должен содержать очень много практического материала и демонстраций, чего практически небыло у Сергея. Увы.

Записи некоторых докладов уже выложили на RuTube, но пока (я надеюсь) еще не все. Найти их можно по адресу http://rutube.ru/playlists/play/42454.html. А тезисы и некоторые презентации располагаются на сайте РИТ в разделе Материалы РИТ-2008.

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

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