Symfony *

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

Предыстория:

Довелось мне не так давно выкладывать некий проект на Symfony2 на хост площадку, но, как это довольно часто бывает, на живом сервере приложение работать отказалось, и включив debug, я увидел уведомление примерно следующего плана:

Twig_Error_Runtime: An exception has been thrown during the rendering of a template
(«Warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in
/.../app/cache/prod/classes.php line ...») in "..." at line ...

Вот уже полтора года я использую Symfony 2 для разработки web-приложений. За это время я трижды начинал новый проект, еще в трех проектах работал с унаследованным кодом, а также провел ревью около 15 тестовых заданий на знание фреймворка.

Наверное, было бы здорово иметь возможность вернуться на полтора года назад и дать себе несколько советов перед стартом своего первого проекта. Увы, это невозможно. Но может быть, мои советы могут пригодятся другим начинающим разработчикам на Symfony?

У многих, равно как и у меня, периодически возникает потребность в реализации каких-то небольших задач. Например распарсить сайт/API и сохранить данные в xml/json/csv, произвести какие-либо расчеты/пересчеты, перегнать данные из одного формата в другой, собрать статистику и т.д. и т.п. Замечу, что речь о задачах не связанных с текущими проектами.



Собирать тяжелый фреймворк ради удобных фич, лень, а реализовывать в рамках кода текущих проектов как-то не эстетично. Поэтому для экономии своего времени приходится создавать скрипт, копипастить в него куски кода из предыдущих наработок, подключать разнообразные библиотеки и запускать скрипт из консоли. При этом часто требуется некоторая интерактивность работы скрипта: обработка опций/аргументов, а то и диалоговое взаимодействие. Здесь главное чтобы не было настроения, которое хорошо описывается выражением «Аппетит приходит во время еды», тогда вообще не понятно к чему приведет работа над простой задачкой =)

В такие моменты я вспоминал удобную симфоническую консоль, к которой успел привыкнуть работая с проектами на
Symfony 2. Не в обиду другим консолям (zend, yii, django, ror etc), все хороши, просто так сложилось.

Когда в очередной раз потребовалось что-то распарсить, я опять вспомнил про консоль Symfony (Console Component) и тот факт, что это независимый компонент все больше подтолкнул меня к мысли использовать ее возможности.

За пару часов получилась простая тулза, в основе которой:

• symfony/console — сама консоль
• symfony/finder — для поиска и подключения к приложению наших комманд
• suncat/symfony-console-extra — несколько плюшек для того чтобы это все работало

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

Недавно узнал о великолепном микро-фреймворке 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 в целом, к настоящему моменту стали представлять подобие оживленного городского квартала.