Сейчас, думаю вы слышали новость, Zend Framework 1.8 готов к работе. В ZF 1.8 были добавлен несколько новых компонентов, таких как: Zend_Application, Zend_Navigation, Zend_Tag_Cloud и Zend_Tool. Zend_Tool это не компонент в обычном понимании. Множество компонентов имеют базовый класс в начале пространства имен. Zend_Tool нет. Множество компонентов в основном используются внутри кода приложения упрощая исполнение задач. Zend_Tool нет. Zend_Tool более похож на framework чем на компонент — framework внутри framework-а.
Так что же такое Zend_Tool?
Инициатива началась с изучения, что необходимо сделать для создания нового поколения framework и приблизить его к RAD(Rapid Application Development). RAD как вы себе представляете, термин с очень красивым расплывчатым определением. В его обычной трактовке, это термин обозначает скорость с которой вы можете создавать ресурсы по запросу для приложений. В большинстве идеальных ситуациях, начиная разработку или на стадии загрузки проекта, он должен содержать минимум который разработчик может использовать, для дальнейшего интересного программирования. После всего, «интересное программирование» составит большую часть работы пока приложение не будет выпущено.
Таким образом если это интересное программирование, что тогда не интересное программирование. Для Zend Framework и большинства основанных на MVC framework-ах к примеру, это процесс создания и инициализации основных ресурсов для всех проектов: основная структура проекта, стартовые файлы конфигурации, стартовая раскрутка и автозагрузка кода и т.д. Это так же включает задачи по обработке ошибок, созданию контроллеров и созданию просмотров и многое другое. Так же для кого-то покажется сложными, запутанными механизмы ZF, некоторые из задач потребуют часов чтения методичек, руководств и других материалов. Ну уж точно не «быстрая» разработка.
Zend_Tool как Framework
Мы создали систему целью которой является создание базовых ZF приложений. Основанная на командной строке и генерации рабочего(точного) кода, а так же целостности существующего кода, система является гибкой и охватывает все возможные стороны касательно разработчика. Zend_Tool спроектирован для облегчения создания абстракций во всех возможных точках где по нашему мнению разработчики захотят расширить систему. К примеру, мы имеем CLI(Call Level Interface) клиента, framework-инструмент разработанный как RPC(remote procedure call) система дающая возможность разрабатывать non-CLI клиентов. Пока мы имеем базовых поставщиков (совместимых с системой), интерфейс для создания новых поставщиков остается легким для расширения и понимания.
Zend_CodeGenerator & Zend_Reflection
В процессе разработки, мы открыли пару проблемных мест не имеющих единого решения. Генерация кода одно из таких мест. Как правило, когда идет речь о генерации кода, обычно подразумевается подход основанный на шаблонах. Сгенерированный код, как правило, получаем из файла содержащего шаблон чаще всего написанный не по правилам, неверно сформированный(по отношению к стандарту языка). Подход на шаблонах так же демонстрирует риск выхода разработчиков за пределы стандартов кодирования и возможность генерировать плохой код(плохой код, в смысле источник плохо сформированного кода) Таким образом мы немедленно реализовали компонент который предоставил объектно-ориентированный интерфейс на подобии PHP's Reflection API для генерации хорошо отформатированного и хорошо сформированного объектно-ориентированного коды. Так же мы хотим сказать что компонент Zend_CodeGenerator может использоваться отдельно от Zend_Tool. Этим мы хотим сказать, что если в найдете часто повторяющиеся генерирование кода, посмотрите в сторону Zend_CodeGenerator.
Zend_CodeGenerator не только пишет код, но и имеет возможность читать существующий код, модифицировать его и генерировать новый код. Это его основное назначение от других компонентов рожденных в Zend_Tool, Zend_Reflection. Zend_Reflection это не изобретение колеса, как факт, он расширяет PHP's Reflection API позволяет добавлять расширения созданные пользователями, docblock reflection (и аннотации tags веутри docblocks), а так же file-based reflection. Компонент может быть использован как drop in replacement когда необходимо получить новые возможности.
Zend_CodeGenerator и Zend_Reflection имеют похожие API. Объект Zend_Reflection чтение структуры кода, объект Zend_CodeGenerator писать структуры кода. Вместе эти два компонента дают возможность просто воспроизводить и писать код в процессе разработки приложения. Zend_Tool Command Line Client et. al.
CLI RAD очень ожидаем ZF разработчиками. Как упоминалось ранее, процесс установки начальных ресурсов проекта может быть утомителен. Множество разработчиков отдают предпочтение взаимодействию с средой разработки через терминал или командную строку, таким образом это место естественно, мы уверенны, будет наиболее предпочтительным для разработки клиента в Zend_Tool. Это не значит, что это будет единственный клиент, как говорилось выше, функциональность Zend_Tool клиента абстрактна и может быть разработан новый клиент для взаимодействия с Zend_Tool. IDE и текстовые редакторы имеют возможность перехватывать вызовы клиента и отправлять команды к своему интерфейсу. Две потенциальных точки расширения включены в мои любимые инструменты. Zend Studio и Textmate — возможности практически безграничные. Другие клиетны могут запустив PHP эффективно делая надстройки над Zend_Tool для своих задач.
Zend_Tool_Project
Since разработка проекта это интерактивный процесс, уравнению со стороны инструментария так же необходимо содержать следы в истории. Что мы имеем ввиду история содержит следы действий которые вы совершили: что вы создали, где это лежит в структуре проекта, и что такое контекст проекта? Как пример, после создания проекта вы захотите создать контроллер. Со всеми намерениями и замыслами, контроллер это обычный файл с классом внутри. Как окружения инструментария знает разницу между обычным файлом и файлом контроллера?
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 среды выполнения, вы получите framework или платформу для разработки инструментальной системы. Любой проект может использовать Zend_Tool_Framework для построения инструментов которые необходимы.
Таким образом, имея все это в виду. Что оно может сделать прямо сейчас? Вместо того чтобы говорить о нем, посмотрим несколько скриншотов.
Что возможно в настоящее время
Помощь
Ошибка
Создаем проект
Создаем контроллер
Создаем действие
Что дальше
К тому что есть сейчас в версии 1.8, несколько новых возможностей уже находятся в разработке. Некоторые из этих возможностей являются бета версиями или все еще находятся в стадии проектирования. К примеру, с Zend_Application мы окончательно решили какую «модель» будем использовать, даже если мы говорим только о том какое имя должно быть. Так же, с версией 1.8 мы закончили опубликование структуры проекта по умолчанию. Для проекта который имеет очень прочную основу в пространстве «библиотеки компонентов» эти огромные шаги для Zend Framework.
Дополнительно к поддержке модели, мы планируем добавить «module» модульную поддержку (для построения приложений из компонентов), соединение с БД, и Zend_Db_Table генератор файлов. Все это можно увидеть в следующих выпусках. Дополнительно Zend_Tool станет еще более расширяем, новые (more beta) возможности могут быть распространены за проекты и которые встраиваются непосредственно в Zend_Tool.
Создание проекта это только начало, пока смысла в этом мало, а в будущем может будет скаффолдинг нормальный, тогда симфонисты не смогут им хвалиться :)
лично меня заинтриговал факт что кодогенератор работает не на шаблонах а на рефлекшенах, нужно будет поковырять, не совсем понимаю как они это сделали поэтому интереснее вдвойне :)
Должно быть все достаточно просто, как всегда исключая некоторые ньюансы.
К примеру, создают в коде не текст а объект класса IndexController
class IndexController extends Zend_Controller_Action {
public function indexAction() { }
}
, а потом через Reflection PHP 5 создают текстовое представление. Это позволяет, теоретически, не менять класс генерации при изменении класса IndexController или любого другого класса.
А вот если бы был текст, тогда при каждом изменении IndexController вам бы автоматически пришлось бы меняить и Zend_Reflection.
Сейчас, думаю вы слышали новость, Zend Framework 1.8 готов к работе. В ZF 1.8 были добавлен несколько новых компонентов, таких как: Zend_Application, Zend_Navigation, Zend_Tag_Cloud и Zend_Tool. Zend_Tool это не компонент в обычном понимании. Множество компонентов имеют базовый класс в начале пространства имен. Zend_Tool нет. Множество компонентов в основном используются внутри кода приложения упрощая исполнение задач. Zend_Tool нет. Zend_Tool более похож на framework чем на компонент — framework внутри framework-а. 
З.Ы. Переводчику спасибо за материал.
Интересно узнать мнение со стороны и посмотреть на взгляд другого человека.
«кодогенератор работает» — Где? Я не заглядывал внутрь. Вы имели ввиду Zend_CodeGenerator?
не, чукча не писатель
До чукчи далеко, но вот если честно как насчет статейки о Zend_Reflection?
Должно быть все достаточно просто, как всегда исключая некоторые ньюансы.
К примеру, создают в коде не текст а объект класса IndexController
class IndexController extends Zend_Controller_Action
{
public function indexAction()
{
}
}
, а потом через Reflection PHP 5 создают текстовое представление.
Это позволяет, теоретически, не менять класс генерации при изменении класса IndexController или любого другого класса.
А вот если бы был текст, тогда при каждом изменении IndexController вам бы автоматически пришлось бы меняить и Zend_Reflection.