Symfony *

Компания Сиклум не перестает радовать самыми разными конференциями и семинарами с участием междунарожных специалистов. 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.

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

Редактирование древовидных структур — довольно частая задача в веб-разработке. Это очень удобно пользователю, поскольку дает ему возможность создавать любые иерархии у себя на сайте. Естественно, что после перехода на Symfony2, одной из первых задач стало создание такого иерархического списка страниц и написание админки к нему. А так как в качестве админки я использую SonataAdminBundle, то задача сводилась к настройке его для редактирования деревьев.

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



Обзор больше теоретический и включает следующие разделы:

• Админгенераторы
• Пользователи
• Импорт/экспорт xls
• API и OAuth 2.0
• Меню/навигация
• Мультимедиа
• Формы
• Поиск
• Пагинация
• Файловая система
• HTTP клиент

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

Собственно говоря, встраивается этот WYSIWYG редактор “легким движением руки”. Необходимо лишь загрузить его javascript код на страницу админки и добавить класс “ckeditor” к необходимому textarea полю. Но есть и один нехороший подводный камень, о котором я и написал в посте.

Разрабатывая проекты на базе нового, но уже ставшего очень популярным фреймворка Symfony2 невольно сталкиваешься с кусками кода, которые с минимальными изменениями, а то и вовсе без них кочуют из одного проекта в другой. Собрав несколько таких «кусков» воедино я создал ShtumiUsefulBundle, об использовании которого хочу рассказать.

В шестой части серии, мы научимся использовать компонент HttpKernel.

• Часть 1
• Часть 2
• Часть 3
• Часть 4
• Часть 5
• Часть 6

В пятой части серии мы поговорим о контроллерах.

• Часть 1
• Часть 2
• Часть 3
• Часть 4
• Часть 5
• Часть 6

В базовой поставке Symfony 2 предусмотрен только минимальный функционал создания CRUD интерфейса. Для реализации административного интерфейса разработан ряд бандлов, в частности SonataAdminBundle.

• Часть 1
• Часть 2
• Часть 3
• Часть 4
• Часть 5

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

<?php
 
// example.com/web/front.php
 
require_once __DIR__.'/../src/autoload.php';
 
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
 
$request = Request::createFromGlobals();
 
$map = array(
    '/hello' => 'hello',
    '/bye'   => 'bye',
);
 
$path = $request->getPathInfo();
if (isset($map[$path])) {
    ob_start();
    extract($request->query->all(), EXTR_SKIP);
    include sprintf(__DIR__.'/../src/pages/%s.php', $map[$path]);
    $response = new Response(ob_get_clean());
} else {
    $response = new Response('Not Found', 404);
}
 
$response->send();

Оглавление

• Часть 1
• Часть 2
• Часть 3
• Часть 4
• Часть 5

До сих пор наше приложение было довольно простым, поскольку содержало только одну страницу.
Что бы немного все усложнить, добавим другую страницу, говорящую «goodbye»:

    <?php

    // framework/bye.php

    require_once __DIR__.'/autoload.php';

    use Symfony\Component\HttpFoundation\Request;
    use Symfony\Component\HttpFoundation\Response;

    $request = Request::createFromGlobals();

    $response = new Response('Goodbye!');
    $response->send();

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

Оглавление

Часть 1
Часть 2
Часть 3
Часть 4
Часть 5

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

• Я не буду говорить об очевидных преимуществах использования фреймворков при работе с большими приложениями и с более чем несколькими разработчиками; в сети уже множество хороших ресурсов по этой теме.

Оглавление

• Часть 1
• Часть 2
• Часть 3
• Часть 4
• Часть 5

Symfony2 это набор автономных, многократно используемых библиотек, не завязанных на друг-друге, которые решают часто встречающиеся задачи в веб-разработке.

Вместо того что бы использовать низкоуровневые компоненты, вы можете использовать полномасштабный фреймворк который базируется на этих компонентах — Symfony2… Или, вы можете написать свой собственный. Эта серия статей о последнем.

Зачем вам нужен собственный фреймворк? (Why would you like to create your own framework?)

Во-первых, почему вы хотите создать собственный фреймворк? Ведь, если посмотреть, все вам скажут, что не стоит изобретать велосипед, а использовать уже готовое решение. И в большинстве случаев они будут правы, но есть несколько причин что бы начать разработку своего фреймворка:

1. Что бы изучить низкоуровневую архитектуру современных веб-ориентированных фреймворков, в частности Symfony2 и ее компонентов.
2. Что бы создать фремворк «под ключ» для ваших специфических нужд. (Только прежде убедитесь, что ваши нужды действительно специфические)
3. Для эксперимента ради удовольствия ( научился и забил )
4. Для рефакторинга уже существующих приложений, которые нуждаются в более современных и устоявшихся практических решениях.
5. Что бы доказать что вы это можете (… пусть и с небольшой помощью)

Здравствуйте.

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

В Symfony 2, есть отличные инструменты по созданию форм из сущностей, а так же, что более интересно — объединенные формы.

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

В второй Symfony, мы можем присоеденить бихейверы (behaviours) к нашим моделям используя расширения от Doctrine. Один пакет (bundle), StofDoctrineExtensionsBundle, даёт возможность использовать следующие бихейверы: Sluggable, Translatable, Timestampable, Loggable и Tree.

Вышеописанные расширения позволяет превратить обычные ссылки в удобочитаемые (sluggable), осуществлять простую поддержку интернационализации (translatable), организовывать контроль версий (loggable), создавать и автоматически заполнять дату создания и обновления сущности (timestampable), и организовывать древовидную структуру хранения данных (tree).

Цель данной статьи — рассказать об организации нестандартной аутентификации для проектов на базе Symfony 2.0.

Зачем это может понадобится?

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

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

class DefaultController extends Controller
{

    /**
    * Dashboard page.
    * @Permissions(perm="dashboard_view")
    * @Route("/", name="ITEDashboardBundle_index")
    * @Template()
    * @return array
    */
    public function indexAction()
    {.......

Прошло уже 3 месяца с тех пор, как я, в качестве хобби, начал писать проект на новом Symfony 2. Далее в статье я постараюсь поделиться с хабрасообществом проблемами, с которыми может столкнуться разработчик. Статья ориентирована на людей уже знакомых с архитектурой Symfony и Doctrine.

Автор рассказывает об устройстве бандла Security (на мой взгляд, самого трудного в понимании для symfony-новичков) и разбирает пример его применения. Статья будет особенно полезна для тех, кто желает знать, как работает их инструмент: Symfony2 Security в общем и FOSUserBundle в частности — однако не подходит для первого знакомства с фреймворком, поскольку требует знания некоторых из его компонент.
Статья была опубликована 21 марта 2011 года, когда ещё не вышла финальная версия symfony2.0, однако принципы работы бандла не изменились.

Оригинальная статья — «Symfony2 Blog Application Tutorial Part V: Intro to Security» — часть цикла обучающих статей на примере создания блога.
Есть прямое продолжение/дополнение статьи — «Symfony2 Blog Application Tutorial Part V-2: Testing Secure Pages», где даётся пример тестирования «закрытых» частей приложения.