Symfony *

Недавно узнал о великолепном микро-фреймворке Silex, и примерно столь же недавно о модели ORM. Туториал будет полезен тем, кто хочет связать одно с другим.

Несмотря на то, что внедрение зависимостей в сущности считается плохой практикой с точки зрения DDD, существуют ситуации в которых это очень удобно. Правомерность использования такого подхода, а ровно как и сравнение его с альтернативами (двойная диспетчеризация, события) не является темой данной статьи. Я хочу рассказать о технической реализации — об интеграции Symfony Dependency Injection Component (далее DIC) с Doctrine для автоматического внедрения зависимостей в загружаемые сущности. Используемые версии Symfony и Doctrine — 2.*.

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

Цифры

Что я могу сказать о новом релизе? Как и планировалось, Symfony 2.2 заняла 6 месяцев и состоит из 711 pull requests содержащих 2,035 коммитов, представленные 44 разработчиками (47191 добавлений и 13,512 удалений), документация получила 1312 коммитов от 41 автора (13038 добавлений и 3,336 удалений).

В итоге получилось 2035 коммитов и 711 pull requests за 6 месяцев, то есть в среднем, по 11 коммитов и 4 pull requests каждый день.

Сегодня вышел Symfony 2.2.

Список нововведений из официального блога:

• Console: Автозавершение в командной строке;
• Console: Прогресс-бар для длинных заданий;
• Console: Скрытие паролей в режиме командной строки;
• Console: Предложение пользователю выбрать из списка возможных вариантов;
• Finder: Фильтрация по пути;
• Finder: Поддержка синтаксиса glob в методе in();
• Finder: Увеличение скорости на некоторых платформах;
• HttpKernel: Новый под-фреймворк для управления фрагментами ресурсов;
• HttpKernel: Улучшен вид вывода фатальных ошибок;
• HttpKernel: Логирование устаревших вызовов;
• Process: Получение промежуточных результатов выполняющихся процессов;
• Process: Перезапуск процесса;
• Process: Получение статуса исполняющегося процесса;
• Routing: Поддержка URL-хостов при маршрутизации;
• Routing: Относительные URL для схемы и пути;
• Security: Интересные утилиты безопасности;
• Validators: Валидаторы относящиеся к платежным системам;
• FrameworkBundle: Улучшение производительности для функциональных тестов;
• FrameworkBundle: Кэширование статических страниц.

Также в Symfony 2.2 из существующего кода были выделены два компонента:

• PropertyAccess;
• Stopwatch.

Далее — более подробно о некоторых изменениях.

Собственно, вчера (24-го февраля) вышла Symfony 2.2 RC3. Если верить Фабиену, на этой неделе должны выпустить финальную версию (он написал в блоге). Рекомендую всем проверить проекты на совместимость.

Касательно графика обновлений SF2.2: Schedule Update

Также учтите, что в конце апреля 2013 прекращается поддержка Symfony 2.1, так что пора бы задуматься об обновлении (пусть даже тестовом).

Основная задача SonataAdminBundle – создание конфигурируемого интерфейса для редактирования сущностей ORM/ODM-модели. Однако, в какой-то момент может понадобиться создать произвольную страницу в административном интерфейсе, не связанную с какой-либо сущностью, чтобы дизайн новой страницы полностью вписывался в дизайн страниц SonataAdminBundle и, соответственно, разместить ссылку на неё на главной странице.

Для опытного Symfony 2 разработчика задача не представляет особой сложности, новичкам же – может доставить немало хлопот (как это было в моём случае).

В данной статье приводится пример создания простого сайта-блога с использованием паттерна Dependency Injection. Применяется подход с внедрением зависимостей во все возможные компоненты Symfony: контроллеры, doctrine-репозитории, формы.

Для упрощения статьи сократим число страниц сайта до двух:

• Добавление нового поста (/add)
• Отображение списка всех постов (/list)

Финальная архитектура приложения будет выглядеть следующим образом:

Symfony2cheatsheet — это прекрасный, полезный, а главное очень удобный ресурс, для тех кто постоянно работает с фреймворком Symfony2. На сайте указана версия 2.1.*, но в большенстве случаев подойдет и для 2.0.*.
Ну и как сказано на сайте: «Symfony2 руководство, сделает вашу работу легче»

 

В данной статье я бы хотел поделиться знаниями о том, как устроены, для чего нужны и что из себя представляют packages(далее пакеты) в Fuelphp. Прошу помочь сравнить реализацию и возможности пакетов Fuelphp с аналогами из других фреймворков. Думаю всем будет интересно узнать мнение адептов Simfony2 и Yii по этому поводу, милости просим, кидайте свои выкладки в комменты. Далее в примерах будет рассмотрен пакет fuel-ninjauth

Формы – в Symfony2 один из самых мощных инструментов, они представляют множество возможностей. Много секретов работы с Symfony2 описано в Книге рецетов. Хочу представить вам перевод одного рецепта работы с формами, в Symfony 2 – использование дата трансформеров.
Часто возникает необходимость преобразовывать данные, введенные пользователем в форму в другой формат для использования в вашей программе. Можно легко сделать это вручную в контроллере, но как поступить, если вы хотите использовать эту форму в разных местах? Скажем, у вас есть объект «Task» (задачи) связанный соотношением кодин-к-одному с объектом «Issue» (проблемы), для каждой «Task» моможет быть указана опционально «Issue», которую она решает. Если в форму редактирования задач «Task», добавить выпадающий список из проблем «Issue», то нам будет очень тяжело в нем ориентироваться. Можна добавить текстовое поле вместо, выпадающего списка и вводить просто номер «Issue».
Вы можете попробовать сделать преобразование в контроллере, но это не самое лучшая идея. Было бы намного лучше, если бы номер «Issue» автоматически преобразовался объект «Issue». В этом случае в игру вступают «Data Transformers» (трансформеры данных).

В Symfony 2 появился совершенно новый компонент для работы с формами, который, насколько я знаю, легко заменит большинство подобных библиотек для PHP и по функционалу, и по возможности в расширении оного (конечно, если не брать в расчет небольшие недостатки при работе с JavaScript). Разработка этого компонента заняла более двух лет, хотя думать над ним я начал еще где-то в 2009-ом году или даже раньше. С каждой новой версией этот компонент становится все более и более стабильным, а полностью стабильная версия ожидается с выходом Symfony 2.2.

Данный пост приурочен к выходу Zend Framework 2 Form RFC, так как мне кажется, что его разработчики, по сути, сделали много того, что уже было сделано нами. Конечно же всем ясно, что Zend Framework 2 должен обладать прослойкой для работы с формами, который полностью учитывает особенности компонентов, поставляемых с фреймворком. Целью данного поста является попытка показать, что Symfony2 Forms прекрасно подходит под эти требования. Функционал, присущий Symfony2, может быть легко убран: код для обработки форм и все уровни абстракций полностью независимы. Привязать же поддержку особенностей компонентов Zend-а так же не составит труда.

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

Уже вот-вот выйдет версия Symfony 2.1, а в сообществе до сих пор нельзя реализовать «без костылей» полноценный REST, и, по-моему, здесь что-то не так. Недавно вышла статья с громким названием REST API’s with Symfony2: The Right Way, но, по существу, она лишь подтверждает мои слова. Вся проблема упирается в сериализацию и десериализацию объектов. Казалось бы, простейшая задача и решений должно быть много, но, к сожалению, нет. Давайте обо всем по порядку.

Пост навеян вот этим вопросом. Будем использовать стандартные эвенты Symfony для переопределения вывода контроллера. Итак, как, в общем, всё это будет работать:

1. Создадим аннотацию Ajax для обработки типа контента контроллера
2. Будем обрабатывать эту аннотацию через эвенты
3. Будем переопределять тип контента в соответствии с выбранным типом в аннотации

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

Создание REST API это нелегкая задача. Нет, серьезно! Если вы хотите написать API правильно, вам придется о многом подумать, решить, быть прагматиком, или API маньяком. REST это не только GET, POST, PUT и Delete. На практике, у вас могут быть взаимодействия между ресурсами, нужно перемещать ресурсы куда-то еще (к примеру внутри дерева), или вы захотите получить конкретное значение ресурса.

В данной статье собрано все, чему я научился реализуя различные API сервисы, используя для этих целей Symfony2, FOSRestBundle, NelmioApiDocBundle и Propel. К примеру сделаем API для работы с пользователями.

Данный пост является переводом не статьи, как принято, а доклада+презентации, поэтому текст поста достаточно вольный.

Думаю, всем хорошо известно и очевидно, что PHP — один из самых популярных языков программирования, на котором написано множество веб-проектов, начиная с персональных homepage-страниц и заканчивая мастодонтами типа Facebook, Vimeo, WordPress и даже YouPorn.

PHP появился в 1995 году, при этом полноценная поддержка ООП была реализована только в PHP5, который вышел в 2005 году. За это время было написано большое количество кода, как хорошего, так и плохого, а точнее сказать сильно устаревшего и тяжело сопровождаемого.

Многие проекты, как и экосистема PHP в целом, к настоящему моменту стали представлять подобие оживленного городского квартала.

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

В этот раз мы приглашаем PHP и Web специалистов в наши офисы в Одессе 6 июля и в Киеве 10 июля на встречу с опытным веб разработчиком Лукасом Смиттом. Тема обсуждения: Exploring Symfony2 by Code. Внимание! Доклад и обуждение будут проходить на английском языке без перевода.

О докладе:

В рамках доклада вы не увидите стандартных слайдов и презентаций. Мы будем вместе изучать элементы кода в эдиторе, вызывать команды в CLI и смотреть на получнный результат в браузере, подробно обсуждая все происходящее. Мы увидим как Symfony2 обрабатывает запрос от начала до самого конца. В ходе обсуждения станет понятно, как устроен Symfony2, каковы приемущества и основные недостатки использованных подходов. Будут также рассмотрены некоторые примеры опен-сорс решений, расширяющих стандартные возможности фрэймворка. По окончании мероприятия каждый вынесет для себя суть философии Symbony2, плюсы и минусы в использовании и общие конфепции. Вы можете просмотреть файлы заранее на github ->

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

Выбор LAMP
Вначале мы выбрали общий стек технологий. Здесь было просто: ведь наиболее распространённый выбор технологий для веб-порталов — это LAMP (Linux, Apache, MySQL, PHP). Мы не хотели изобретать велосипед, писать все с нуля, так как это и дорого и долго. Нам нужно было максимально быстро создать портал с использованием каких-либо библиотек/фреймворков, возможно CMS/E-commerce систем. Если LAMP технологии наиболее распространены — то значит, мы сможем найти большое количество различных open-source решений, а из них сможем выбрать что-то подходящее для «фундамента» своего портала.

Готовые E-commerce системы
Как только мы выбрали PHP и все, что с ним связано, мы начали смотреть, что уже есть готового по нашей тематике. Конечно же, мы сразу начали думать про готовые E-commerce системы, например, набирающую популярность Magento. Нашли нескольких партнеров Magento, которые занимаются кастомизацией и внедрением этой системы. Попросили сделать примерную оценку того, во сколько нам обойдется «заточить» Magento под все наши требования, включая оптимизацию быстродействия, с которым у Magento, как оказалось, есть сложности, особенно у бесплатной версии. Наши расчеты показали, что по стоимости работ и дальнейшей поддержке в краткосрочном периоде — это будет даже дороже, чем, если бы мы писали все с нуля на чистом PHP. Мы посмотрели другие E-commerce решения: osCommerce, ZenCart, PrestoShop. Здесь ситуация была примерно такая же, а может даже хуже. Таким образом, мы вернулись в исходную точку поиска.

Фреймовики и библиотеки
Тогда мы решили смотреть в сторону более общих решений: фреймворков и библиотек. Мы решили остановиться на выборе 3-ех наиболее популярных фреймворков: Zend 1.11, Symfony 2 и Yii. Здесь у нас был более технологичный подход к выбору: мы хотели полную поддержку PHP 5.3, причем, желательно, чтобы сам код фреймворка предполагал стиль написания PHP 5.3, а именно как можно больше ООП, ведь нам же это все еще поддерживать потом. От Zend отказались сразу. Он очень монструозный, а нам нужно процентов 20 от его функциональности. К тому же ожидаемый 2.0 тогда был еще в форме идей на сайтах основных разработчиков. Yii был еще очень свежий на тот момент (осень 2011 года), а мы знаем, чем бывают чреваты эти «горячие пирожки» (как показало время – версия Yii 2.0 с полной поддержкой PHP 5.3 пишется до сих пор). И мы решили не рисковать и взять наиболее готовый и стабильный продукт – Symfony 2.

ORM решения
Итак, у нас были выбраны и платформа и фреймворк: LAMP + Symfony2. Нам также нужно было решить проблему с уровнем хранения и представления данных в нашем портале. Наверное, хорошо написать что-то специфическое для себя – это и работает быстрее и меньше кода. Однако основная наша проблема была в том, что мы делали свой продукт, и у нас не было четкой и постоянной спецификации. Улучшения же (читай: частые изменения) в сущностях, их взаимосвязях и бизнес-логике, требовали какого-то гибкого решения, которое мы могли бы быстро изменять и не бояться получить массу regression багов. В данном случае мы пошли хорошо проторенной дорогой. Сейчас большую популярность набирают различные ORM решения. Это не зависит от стека технологий или домена приложения. Посему после недолгих рассуждений мы выбрали ORM Doctrine 2. Тем более что она входит как стандартный модуль в Symfony 2. К тому же, мы понимали, что с ростом объемов данных и взаимосвязей между сущностями при работе на портале, мы перейдем к использованию нереляционной СУБД, например, MongoDB, а с выбранной ORM – Doctrine это также просто реализуется.

Итого у нас получился интересный набор технологий:

LAMP + Symfony 2 + Doctrine 2.

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

С момента релиза php 5.4 уже прошло некоторое время, и мы решили поэкспериментировать с трейтами (traits), оценить их практическое применение. Как их можно использовать вместе с объектами Doctrine2?

Трейты

Трейты в php — это набор свойств и методов, которые можно добавить в класс.
Они реализованы на уровне интерпретатора и являются абсолютно прозрачными для Doctrine.

Трейты спроектированы для горизонтального повторного использования и идеально подходят для добавления общего поведения в несколько объектов.