Zend Framework *

О том, что такое Zend Certified PHP Engineer (ZCE) и как к нему готовиться было достаточно статей. Я опишу свое мнение о ZCE (PHP 5.5) и свой процесс подготовки за неделю (с учетом моего пятилетнего опыта практической разработки).

Взгляды на ZCE

Сама по себе сертификация, в общем и целом (за исключением нескольких вопросов), проверяет, насколько усвоенной оказалась официальная документация PHP. Может попасться пару практических вопросов, а также вопросы на знание паттернов (мне попался про Registry и его применимость), что немного радует.

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

Как грибы растут стандарты, фреймворки, развивается и становится всё слаще синтаксис, растут разнообразные инструменты.

И это здорово!

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



Попробуйте пройти несложный тест и определить — не мамонт ли Вы в мире PHP? Не грозит ли Вам, как специалисту, вымирание в ближайшее время?

Тест, разумеется, пятничный и шуточный. Но в нём всё-таки есть доля истины.

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

Ни для кого не секрет, что к многочисленным сертификациям, и к ZCPE (Zend Certified PHP Engineer) в частности, все относятся по-разному: кто-то коллекционирует их и развешивает на стенках для самолюбования, кто-то считает пустой тратой времени и денег.

Обсуждение идей и предложений для Zend Framework 3 идет достаточно давно, и вот наконец Zend решились на анонс новой версии фреймворка.

Zend Framework 3 будет эволюцией ZF2, с фокусом на три главных момента — простоту, повторное использование кода и производительность.

В первоочередные планы входит:

• выделение компонентов фреймворка в индивидуальные, версионируемые проекты (привет, Symfony!);
• особый упор будет сделан на HTTP сообщения, которые будут приведены в соответствие с PSR-7;
• существующий full stack MVC фреймворк будет обновлен и начнет зависеть от новых независимых компонентов для повторного использования и упрощения. ZF2 MVC проекты можно будет с минимальными усилиями перенести на новую версию, для чего подготовят гайд по миграции;
• использование концепции middleware, знакомой многим по Ruby / Python, а так же PHP-фреймворкам Slim Framework и StackPHP, в качестве более легкой альтернативы энтерпрайз-стеку фреймворка MVC (пример того, о чем идет речь);
• возможность использования Apigility в качестве middleware;
• оптимизация под PHP 7, при этом будет поддерживаться PHP начиная с версии 5.5;

Service Manager (SM, CM) в ZF2.

Service Manager — это один из ключевых компонентов Zend Framework 2, который существенно облегчает жизнь разрабочика избавляя его от дублирования кода и рутинных операций по созданию и настройки сервисов, позволяя их конфигурировать на максимально высоком уровне. СМ, по своей натуре, является реестром сервисов, основная задача которого — создание и хранение сервисов. Можно сказать, СМ является очень продвинутой версий компонента Zend_Registry из Zend Framework 1.
СМ реализует паттерн Service Locator. Во многих частях приложения (например, в AbstractActionController) можно встретить функции getServiceLocator(), которые возвращают класс Zend\ServiceManager\ServiceManager. Такое несоответствие названия метода и возвращаемого типа легко объясняется тем, что getServiceLocator() возвращает объект, реализующий интерфейс ServiceLocatorInterface:

Три предыдущих года я работал тестировщиком-мануальщиком в компании, которая очень успешно разрабатывает модули под Magento. За этот период я смог накопить достаточно большой список различных подводных камней, о которых тестировщику (да и программисту) никогда нельзя забывать.
Честно говоря, это не какие-то никому не известные «подводные камни», о которых никто не знает, или о которые модуль в боевых условиях никогда не споткнётся. Это скорее всем известные фичи и места самой Magento, в взаимодействии модуля с которыми всплывает очень много, кхе-кхе, багов. Причём баги эти очень даже критичны.

Если вы хотите для множества добавленных скриптов:

$this->view->headScript()->appendFile('/static/js/script1.js');
$this->view->headScript()->appendFile('/static/js/script2.js');
$this->view->headScript()->appendFile('/static/js/script3.js');

вместо этого:

<script type="text/javascript" src="/static/js/script1.js"></script>
<script type="text/javascript" src="/static/js/script2.js"></script>
<script type="text/javascript" src="/static/js/script3.js"></script>

получить вот это:

<script type="text/javascript" src="/static/cache/bff149a0b87f5b0e00d9dd364e9ddaa0.js"></script>

тогда эта статья для вас.

Небольшой гайд по созданию простейшего RESTful api с помощью Zend framework 2 (далее zf2).

Нам потребуется zf2 v2.3@dev, а так же Doctrine 2 ORM.

Итак, начнем с создания структуры директорий нашего api:

mkdir -pv zf2-api/{config/autoload,public,module/v1/{config,src/v1/{Controller,Service,Entities}}}

Загружаем композер

curl -sS https://getcomposer.org/installer | php

Так же нам потребуется создать composer.json с такими зависимостями и установить их.

"require": {
        "php": ">=5.4",
        "zendframework/zendframework": "2.*@dev",
        "doctrine/doctrine-orm-module" :"0.*"
    }

Задача:

1. Иметь метод, разбирающий на составляющие строку содержащую URL. Строка может содержать как абсолютный, так и относительный URL, и оба эти варианты должны быть правильно разобраны.
2. Причём в стоке допустим «неправильный» формат абсолютной ссылки — без «http://». Далее по тексту ссылки «неправильного» формата будем называть неполными абсолютными ссылками.
3. Реализовать поддержку «РФ» доменов.

Это третья (последняя?) часть статьи, посвященной разработке простого приложения при помощи Zend Framework 2. В первой части я рассмотрел структуру ZendSkeletonApplication, во второй части привел пример разработки простого модуля. Эта часть посвящена работе с пользователями, а также я прикручу к проекту шаблонизатор Twig.

Работа с пользователями

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

Zf Commons

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

Среди множества разработчиков модулей выделяется команда ZF Commons, ребятами из этой команды разработан ряд очень полезных модулей, которые мы будем использовать в этом проекте: github.com/ZF-Commons. Рассмотрим некоторые из них, которые необходимы нам на данном этапе.

Это вторая из трех частей статьи, посвященной разработке простого приложения при помощи Zend Framework 2. В первой части я рассмотрел структуру ZendSkeletonApplication, а в этой части приведу пример разработки простого модуля. Третья часть будет посвящена работе с пользователями и шаблонизатором Twig.

Установка и настройка дополнительных модулей

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

1. добавляем соответствующую строчку в composer.json, чтобы сообщить Композеру о новом модуле,
2. выполняем команду php composer.phar update, чтобы Композер загрузил новый модуль и при необходимости перегенерировал автолоад файлы,
3. добавляем новый модуль в список modules в файле config/application.config.php,
4. при необходимости, размещаем конфигурационный файл модуля (обычно пример такого файла находится в папке config модуля) в config/autoload и делаем в нем необходимые правки.

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

Давайте начнем с установки простого, но полезного модуля Zend Developer Tools.

В последние несколько лет моя работа связана с использованием CMS Drupal, но на досуге я изучал и just for fun запускал проекты на питоновских фреймворках Django, Flask и Twisted. Сейчас я решил освоить основы двух-трех популярных PHP-фреймфорков и первыми я решил изучить Zend Framework 2 и Yii.

В процессе ознакомления с Zend Framework 2 я изучил туториал с официального сайта (http://framework.zend.com/manual/2.2/en/user-guide/overview.html), просмотрел документацию фреймворка (http://framework.zend.com/manual/2.2/en/index.html), прочитал книгу Michael Romer “Web development with Zend Framework 2” и собрал собственное тестовое приложение.

Переварив всю эту информацию, я пришел к мысли, что официальный туториал к фреймворку суховат:

• в нем не рассказывается о работе с пользователями, сессиями и правами доступа,
• лишь вскользь рассматривается такая основополагающая часть фреймворка как ServiceManager,
• в качестве интерфейса с базой данных безальтернативно используется паттерн Table Gateway (и соответствующая его реализация в фреймворке),
• используется встроенный в фреймворк шаблонизатор, который после питоновского Jinja 2 кажется совершенно неудобным и примитивным,
• и т.д.

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

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

• в качестве шаблонизатора будет использоваться Twig,
• для работы с БД — Doctrine ORM,
• для авторизации/аутентификации и распределения прав доступа я буду использовать существующие модули ZfcUser и BjyAuthorize,
• также я рассмотрю вопросы разработки собственных валидаторов форм, View плагинов и другие.

Пожалуй, это был один из самых муторных челленжей для меня за последнее время.

Итак. Мы занимаемся технически сложными проектами, потенциально рассчитанными на высокие нагрузки (highload). Так получилось, что среди систем управления контентом пока победил Битрикс. Его хотят клиенты. Судя по нашему опыту — highload на Битриксе — очень даже реальная задача, если делать все аккуратно.



Обычно в проектах, где много форм, личных кабинетов или какая-то сложная логика — мы предлагали на выбор клиенту реализацию на Zend Framewok или на Битрикс. Минус ZendFramework был в том, что на нем нужно писать админку. Минус Битрикса — он плохо приспособлен под проекты со сложной бизнес-логикой: там толком нет MVC и местами отвратительный код и API. Маркетинговые байки-балалайки про ядро D7, которым уже 2 года — мы в расчёт не берем:

«Talk is cheap. Show me the code» (Linus)

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

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

Элемент Captcha имеет более одного поля, которые рендерятся друг за другом. Встроеный генератор изображений каптч (Zend\Captcha\Image.php) использует свой собственный хелпер (Zend\Form\View\Helper\Captcha\Image.php) для создания изображения. Так-же, в Zend\Captcha\Image.php находится метод 'getHelperName'. Этот метод передает имя хелпера для рендеринга изображения каптчи. По умолчанию 'getHelperName' передает 'captcha/image' — экземпляр класса Zend\Form\View\Helper\Captcha\Image.php. Если углубиться с помощью дебаггера, можно увидеть, что в свойстве экземпляра phpRenderer::__helpers, в invokablesClasses располагается хелпер 'captchaimage'. Это и есть Zend\Form\View\Helper\Captcha\Image.php, упомянутый ранее. Грубо говоря — вы просто создаете изображение, а всё остальное делает за вас рендерер используя хелпер, хотя такое положение вещей устраивает не всех.

/////////

Привет, читатели!

Многие разработчики начали изучать Zend framework 2 и, скорее всего, столкнулись с проблемой использования постоянного адаптера для базы данных. Я хотел бы поделиться с вами интересной статьей, которая помогла мне решить этот вопрос.

Написание статьи навеяно habrahabr.ru/qa/34735 и habrahabr.ru/qa/32135 вопросами, в качестве ответов на которые не смог найти полной и подробной информации, чего очень не хватало. Я надеюсь, что она будет полезна и другим.

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

На этом, думаю, прелюдию можно закончить и перейти к самому интересному.

Здравствуйте дорогие хабражители.
Совсем недавно вышел в свет Zend Framework 2. Однако его изучение у многих усложняет отсутствие русской документации и единого сообщества. Так же во второй ветке этого фреймворка появилось множество нововведений и плюшек, про который обычный PHP программист раньше даже не слышал. Но их можно изучить особо не потея. А вот понять, как работает ZF2 без понимания логики работы его MVC системы достаточно затруднительно. Поэтому решил сделать перевод с официального сайта именно этого раздела.И так приступим.

MVC в Zend Framework 2

Zend\Mvc представляет собой совершено новую реализацию MVC системы для Zend Framework 2. Основное внимание было уделено производительности и гибкости.

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

1. Zend\ServiceManager — Zend Framework предоставляет набор различных сервисов, определенных в Zend\Mvc\Service. ServiceManager создает и настраивает экземпляр вашего приложения и рабочего процесса.
2. Zend\EventManager – MVC является событиями. Данный компонент используется повсеместно. Для начальной загрузки приложения, возврата ответов (response) и запросов (request), настройки и получения маршрутов (routes), а так же для обработки (render) скриптов вида (views).
3. Zend\Http – особый объект запросов (request) и ответов (response). Используется с Zend\Stdlib\DispatchableInterface. Все контроллеры представляют собой объекты «dispatch».

В MVC слое используются следующие вспомогательные компоненты:

1. Zend\Mvc\Router – содержит классы, обеспечивающие маршрутизацию запросов. Другими словами, перенаправляет запросы к нужным контроллерам.
2. Zend\Http\PhpEnvironment – предоставляет набор декораторов объектов HTTP запросов и ответов, обеспечивающих инъекцию запросов в текущую среду (включая GET и POST параметры, HTTP заголовки).
3. Zend\Mvc\Controller – набор абстрактных классов контроллеров с базовой функциональностью, такой как создание событий, диспетчеризацией действий и т.д.
4. Zend\Mvc\Service – набор ServiceManager фабрик и определений по умолчанию для различных процессов приложения.
5. Zend\Mvc\View – предоставляет стандартные возможности визуализации скриптов вида, регистрации помощников и многое другое. Так же предоставляет различные слушатели, которые «связывают» рабочий процесс MVC, обеспечивая такие функции, как автоматическое разрешение имен шаблонов, автоматическое создание модели вида и инъекций, т.д.

Ваш сайт все более популярен, рекорды посещаемости бьются еженедельно. Вы подключаете кеширование, разбираетесь в нюансах настроек, оптимизируете. Но наступает момент когда одного сервера уже никак не достаточно, а переход на самую классную в мире железяку не находит полного понимания у начальства. Ах да, ID пользователя Вы храните в Сессии PHP в файле, и вроде бы уже морально готовы положить все в базу данных, как рекомендует Интернет… Но что-то Вас останавливает.

Перевод статьи Zend Framework: XSL and self-serializing Views
Автор: Pascal Opitz

Я давно утверждал, что фраемворки MVC должны использовать стили XSL вместо встроенного PHP кода и прочего. Вот почему я постучал вместе немного доказательство концепции Zend Framework, где представления файлов в виде XSL шаблона, а представление сериализует себя в XML для рендеринга.