Несложно догадаться, что основной мотив данной конференции – вышедшая не так давно релиз-версия Symfony 2, поэтому приготовьтесь к куче чужого опыта и интересных граблей, на которые до вас уже наступили ))

Полный анонс можете посмотреть на специальной страничке, которую я создал по этому поводу – http://hudson.su/symfony-camp-ukraine/.

Enjoy!

Немного истории.

Впервые познакомился с symfony я где-то в 2007м году. Тогда меня этим фреймворком заразил один энтузиаст по имени Руслан. Сам он потом довольно быстро охладел к этой забаве, а я же, наоборот – окончательно сделал выбор между Zend framework и Symfony в пользу последнего. Потом я сменил работу и на новом месте все проекты уже делал только на symfony. 1.0, 1.1, 1.2, 1.3/1.4 версии мелькали перед глазами, только успевай за неутомимым Фабиеном и компанией )

Где-то в 2009м году я загорелся идеей сделать коммьюнити-сайт и одновременно блог для себя – о симфони, для симфонистов, да и просто получить фан для себя и плюс в карму ) Зарегистрировал домен symfony-gu.ru (по аналогии с ныне почившим java-gu.ru). На этом по большому счету все и стало. Я потыкался в популярные CMS’ки, сделал какую-то уродскую страничку… и в общем дальше дело не пошло. В то же время я начал активнее заниматься блогом hudson.su и на следующие 2 года это занятие компенсировало мне фэйл с гуру-сайтом.

Смешное: в 2010м весной домен благополучно разделегировался и удалился, а весной 2011го я также успешно его зарегистрировал вновь ))

С анонсом Symfony2 идеи о коммьюнити-сайте стали посещать меня вновь. И вот, весной я начал делать первый проект на Symfony2 (на Preview release 6) и тогда же в свободное время начал потихоньку писать код для этого проекта. Бешенная смена превью и бета релизов на время отбила у меня желание продолжать что-бы то ни было делать. Потом было лето и косметический ремонт, сделанный единолично без помощников первый раз в жизни ))) И вот к концу августа, уже после релиза Symfony 2.0 я вновь вернулся к старому коду, портировал его под релиз версию. В результате появился тот каркас, который сейчас вы можете видеть по адресу symfony-gu.ru.

О проекте.

Сейчас сайт представляет собой двуязычный блог, написанный на Symfony2 (да, да, кода там кот наплакал )).

Что я буду туда писать:

• Вероятно буду копипастить новости из официального блога симфони;
• Буду искать интересные и полезные треды в майл-листах симфони;
• В ходе разработки рассчитываю писать статьи о том какие проблемы встречал и как их решал;
• Опять же, в ходе разработки будут создаваться пакеты (bundles), которые я рассчитываю выкладывать в паблик (первые два простеньких пакета уже там));
• В перспективе я думаю буду (будем) писать и про другие web-фреймворки, технологии и т.п. Но это пока мечты;
• Ну и попробую организовать коммьюнити – тоже мечта.

Собственно велкам. Вопросы и предложения кидайте по доступным каналам связи.

Ниже приводится небольшое руководство по использованию. Вам понадобится PhpStorm 2.0 и Symfony 1.1 или более поздней версии (включая Symfony 2.0 BETA – в оригинальное руководство не входило, но мной проверено). Если у вас нет Symfony, руководство по установке вы можете найти здесь.

В первую очередь нам нужно настроить новый command line tool.

Загрузка Symfony Commands

Откройте меню Settings | Command Line Tool Support и нажмите в появившемся окне кнопку Add. Вам будет предложено три опции, выберите “Symfony”:

Затем укажите путь к файлу $Symfony_home$/data/bin/symfony. Для типичной конфигурации (из руководства симфони) путь будет следующим: $Project_root$/lib/vendor/symfony/data/bin/symfony. Описания команд Symfony будут загружены и сохранены в файл среди прочих настроек проекта. В диалоговом окне настроек это будет выглядеть следующим образом:

• Поле Tool Path содержит путь к CLI (php и фреймворка) и будет различаться в зависимости от фреймфорка. Для Symfony это “php  $path_to_symfony$”  и “$Zend_Framework_Tool_home$/bin/zf.bat” для Zend Framework. $PhpExecutable$ – это макрос, он заменяется на путь к исполнимому файлу CLI PHP, $ProjectFileDir$ это тоже макрос, он заменяется на полный путь к проекту. Макросы позволяют легко перемещать настройки между несколькими IDE.
• Полный Tool Path может быть очень длинным и неудобным в наборе, поэтому имеется алиас, который представляет из себя строку, которую можно использовать для вызова CLI вместо Tool Path.
• Чекбокс “Enable” поможет вам легко включать и отключать команды фреймворка из списка автоподстановки, не удаляя настройки. В данном случае чекбокс включен, таким образом команды Symfony будут отображаться в списке. Нажмите Ctrl +Shift+X или выберите в меню Tools | Run Command… и наберите алиас “s”:

Используем Symfony Command Line

Теперь создадим простой проект на Symfony c использованием Command Line Tool, как это описано в “Getting  Started” документе.

Создаем проект Symfony

Нажимаем Ctrl +Shift+X и набираем:

Команда имеет два параметра:

• Обязательный параметр “name”. Мы воспользуемся макросом $ProjectName$, который будет заменен на наименование проекта PhpStorm.
• Опциональный параметр “author”.

Перед выполнением команды макрос $ProjectName$ будет заменен на имя проекта и алиас “s” будет заменен на Tool Path. В данном случае это будет что-то типа “usr/bin/php /home/sfproject/lib/vendor/symfony/data/bin/symfony”.

Результат – будет создан проект:

Настройка доступа к базе данных

Теперь настроим доступ к БД при помощи команды “php symfony configure:database “mysql:host=localhost;dbname=dbname” root mYsEcret”

Создание приложения Frontend

Давайте создадим приложение frontend без экранирования вывода (что в общем-то сделает его менее защищенным!). Нажмите Ctrl +Shift+X и наберите:

Заметьте, что опции команд также поддерживаются. В примере выше это была опция –escaping-strategy=false.

Результат работы команды:

Права доступа к директориям

Следующим шагом является установка прав на директории cache/ и log/. Это также можно сделать при помощи Command Line Tool Support. Тул попытается выполнить команды (макросы таже доступны). Но имейте в виду, что команды “chmod” по-умолчанию нет в windows системах (если вы не используете например cygwin).

Результат:

Примечание:

Вообще говоря для установки прав можно нужно использовать команду “symfony project:permissions” // hudson@work

После этого надо настроить web-сервер, как описано в документации, и запустить его.

Тестирование

Проверьте доступ к новому приложению – откройте в браузере http://localhost:8080/index.php/ и затем проверьте доступ к dev окружению http://localhost:8080/frontend_dev.php/.

Если вы видите такую страницу, ваш проект успешно создан:

Добавляем пользовательский task.

Давайте создадим простой таск “hello”. Подразумевается что ранее вы уже настроили команды Symfony, как это описано выше и создали проект.

Нажмите Ctrl+Shift+X и выполните команду:

В директории lib/task будет создан класс “helloTask”.

Откройте класс helloTask в редакторе и выполните следующие несложные изменения в его методе “execute”:

Откройте description file для Symfony: выберите Settings |  Command Line Tool Support и нажмите кнопку “Open definition in editor”.

Добавьте описание новой команды “hello”:

Текст описания:

<command>
    <name>
        hello
    </name>
    <help>
        My first task with no parameters.
    </help>
</command>

Для проверки новой команды выполните:

Результат выполнения отобразится в консоли:

Решение проблем

Если у вас возникнут проблемы после редактирования файла описания и нужная вам команда не появится, откройте таб Validation в консоли. Этот таб показывает информацию о проблемах парсинга файла описания:

Вы также можете получить информацию о формате файла описания из схемы .idea/commandlinetools/schemas/frameworkDescriptionVersion1.1.xsd. Этот путь указан в созданном файле описания и редактор выполняет валидацию автоматически с его использованием.

Hope this hepls как говорится, ваш hudson@work

Канат Гайлимов
Web-разработчик, блогер
http://gailimov.info

Поздравляем! Изучая Symfony2, вы становитесь на правильный (истинный) путь и будете более продуктивным, всесторонним и популярным веб-разработчиком (на самом деле, 2 последних пункта на ваше усмотрение). Symfony2 построен так, чтобы вернуться к основам: разработаны инструменты, которые позволят вам разрабатывать быстрее и создавать более надежные приложения, оставаясь вне вашего пути. Symfony построен на лучших идеях многих технологий: инструменты и концепции, которые вы собираетесь изучать, представляют усилия тысячи людей, в течении многих лет. Другими словами, вы не просто изучаете “Symfony”, вы изучаете основы веб, лучшие практики разработки, и как пользоваться многими новыми, удивительные PHP-библиотеки, внутри или независимо от Symfony2. Итак, приготовьтесь.

Оставаясь верной философии Symfony2, эта глава начинается с объяснений основных концепций, общих для веб-разработки: HTTP. Независимо от вашего происхождения или языка программирования, эта глава обязательна к прочтению для всех.

HTTP это просто

HTTP (для гиков Hypertext Transfer Protocol) – текстовый язык, позволяющий двум машинам общаться между собой. Вот и все! Например, когда мы проверяем последний xkcd комикс, осуществляется следующая (приблизительно) беседа:

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

Symfony2 построен вокруг этой действительности. Понимаете ли вы это или нет, HTTP, это то, что вы используете каждый день. С Symfony2 вы узнаете как справляться с этим.

Шаг1: клиент посылает запрос

Каждое общение в сети начинается с запроса. Запрос – текстовое сообщение, созданное клиентом (например браузер, приложение iPhone и т.д.) в специальном формате, известном как HTTP. Клиент посылает запрос серверу, и затем ожидает ответа.

Давайте взглянем на первую часть взаимодействия (запрос) между браузером и веб-сервером xkcd:

В синтаксисе HTTP, этот запрос на самом деле будет выглядеть так:

GET / HTTP/1.1
Host: xkcd.com
Accept: text/html
User-Agent: Mozilla/5.0 (Macintosh)

Это простое сообщение содержит данные о том, какой именно ресурс запрашивается клиентом. Первая строка HTTP-запроса очень важна: она содержит две вещи: URI и метод HTTP.

URI (например, /, /contact, и т.д) это уникальный адрес или место нахождения, идентифицирующее ресурс, который запрашивает клиент. HTTP-метод (например GET) определяет, что вы хотите делать с ресурсом. HTTP-методы являются действиями (глаголы) запроса, и определяют несколько общих способов, которыми вы можете воздейсвовать на ресурс:

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

DELETE /blog/15 HTTP/1.1

Примечание.

Фактически существует девять HTTP-методов, определяемых спецификацией HTTP, но многие из них не используются столь широко или не поддерживаются. В действительности, многие современные браузеры, не поддерживают методы PUT и DELETE.

В дополнение к первой строке, HTTP-запрос содержит другую информацию, называемой заголовками HTTP-запроса. Заголовки могут предостовлять широкий диапазон информации, такую как, запрашиваемый Host, формат ответа принимаемый клиентом (Accept) и приложение используемое клиентов для выполнения запроса (User-Agent). Существует много других заголовков, которые можно найти в Википедии.

Шаг2: сервер возвращает ответ

Как только сервер получил запрос, он знает, какие именно ресурсы требуются клиенту (посредством URI) и что клиент хочет делать с ресурсом (посредством метода). Например, в случае с запросом GET, сервер подготавливает ресурс и возвращает его в виде HTTP-ответа. Рассмотрим ответ от веб-сервера xkcd:

В переводе на HTTP, ответ отправленный обратно в браузер будет выглядеть примерно так:

HTTP/1.1 200 OK
Date: Sat, 02 Apr 2011 21:05:05 GMT
Server: lighttpd/1.4.19
Content-Type: text/html
 
<html>
    <!-- HTML for the xkcd comic -->
</html>

HTTP-ответ содержит запрошенный ресурс (в данном случае HTML контент), а также другую информацию о запросе. Первая строка особенно важна и содержит код статуса HTTP-ответа (в данном случае 200). Код статуса сообщает общий результат запроса обратно клиенту. Был ли запрос успешен? Были ли ошибки? Существуют другие коды статуса, которые указывают на успех, ошибку или то, что хочет клиент (например редирект на другую страницу). Полный список можно найти в Википедии.

Как и запрос, HTTP-ответ содержит различную информацию, известную как HTTP-заголовки. Например, один из важнейших заголовков HTTP-ответа это Content-Type. Тело того же ресурса, может возвратиться в нескольких разных форматах включающих HTML, XML или JSON. Заголовок Content-Type сообщает клиенту в каком формате возвратился ответ.

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

Запросы, ответы и веб-разработка

Общение запрос-ответ – фундаментальный процесс движущий все взаимодействия в сети. И как и все важное и значительное, оно до безобразия просто.

Важный факт во всем этом: независимо от того, какой язык вы используете, приложение какого типа вы создаете (веб, мобильное, JSON API) или какую философию разработки исповедуете, конечная цель приложения это всегда понимание каждого запроса, создание и возврат соответствующего ответа.

Symfony спроектирован так, чтобы соответствовать этой действительности.

Примечение.

Чтобы узнать больше о спецификации HTTP, прочтите оригинальную HTTP 1.1 RFC или HTTP Bis статьи, которые отлично разъясняют исходную спецификацию. Великолепным инструментом для проверки заголовков запроса и ответа в браузере, является расширение для Firefox Live HTTP Headers.

Запросы и ответы в PHP

Итак, как вы можете взаимодействовать с “запросом” и создавать “ответ” используя PHP? В действительности PHP абстрагирует вас от этого процесса:

<?php
$uri = $_SERVER['REQUEST_URI'];
$foo = $_GET['foo'];
 
header('Content-type: text/html');
echo 'The URI requested is: '.$uri;
echo 'The value of the "foo" parameter is: '.$foo;

Как ни странно это звучит, это маленькое приложение фактические берет информацию из HTTP-запроса и использует его для создания HTTP-ответа. Вместо разбора сообщения HTTP-запроса, PHP подготавливает суперглобальные массивы, такие как $_SERVER и $_GET, в которых содержится вся информация запроса. Аналогично, вместо возвращения текстового сообщения в формате HTTP, вы можете использовать функцию header() для создания заголовков ответа и просто вывести контент, который будет содержанием части сообщения ответа. PHP создаст настоящий HTTP-ответ и вернет его клиенту:

HTTP/1.1 200 OK
Date: Sat, 03 Apr 2011 02:14:33 GMT
Server: Apache/2.2.17 (Unix)
Content-Type: text/html
 
The URI requested is: /testing?foo=symfony
The value of the "foo" parameter is: symfony

Запросы и ответы в Symfony

Symfony предоставляет альтернативу подходу PHP, посредством двух классов, которые позволяют вам взаимодейстовать с HTTP-запросом и ответом более простым путем. Класс Request – простое объектно-ориентированное представление сообщения HTTP-запроса. С ним, в ваших руках имеется вся информация запроса:

use Symfony\Component\HttpFoundation\Request;
 
$request = Request::createFromGlobals();
 
// the URI being requested (e.g. /about) minus any query parameters
$request->getPathInfo();
 
// retrieve GET and POST variables respectively
$request->query->get('foo');
$request->request->get('bar');
 
// retrieves an instance of UploadedFile identified by foo
$request->files->get('foo');
 
$request->getMethod();          // GET, POST, PUT, DELETE, HEAD
$request->getLanguages();       // an array of languages the client accepts

В качестве бонуса, класс Request выполняет множество черновой работы в фоновом режиме, так что вы можете не беспокоиться об этом. Например, метод isSecure() проверяет три различных значения в PHP, которые указывают установил ли пользователь защищенное соединение (т.е. https).

Symfony также предоставляет класс Response: простое PHP представление сообщения HTTP-ответа. Он позволяет вашему приложению использовать объектно-ориентированный интерфейс для построения ответа, который должен быть возвращен клиенту:

use Symfony\Component\HttpFoundation\Response;
$response = new Response();
 
$response->setContent('<html><body><h1>Hello world!</h1></body></html>');
$response->setStatusCode(200);
$response->headers->set('Content-Type', 'text/html');
 
// prints the HTTP headers followed by the content
$response->send();

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

Примечание:

Классы Request и Response – часть автономного компонента включенного в Symfony и называемого HttpFoundation. Этот компонент может быть использован полностью независимо от Symfony и также предоставляет классы для обработки сессий и загрузки файлов.

Путешествие от запроса к ответу

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

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

Symfony создан для решения этих проблем, так что вы не должны иметь их.

Front Contoller

Традиционно, приложения строятся так, что каждой страницей сайта, является его физический файл.

• index.php
• contact.php
• blog.php

В этом подходе имеется несколько проблем, в том числе негибкость URL’ов (что, если вы захотите сменить blog.php на news.php без потери всех ваших ссылок?) и тем, что каждый файл должен вручную включить некоторый набор ключевых файлов, так что безопасность, соединение с базой данных, и “взгляд” сайта могут остаться последовательными.

Наилучшее решение – это использование front controller’а: единственного PHP-файла, который обрабатывает каждый запрос, входящий в ваше приложение. Например:

Примечание:

С использованием модуля mod_rewrite веб-сервера Apache (или его эквивалента в других веб-серверах), URL’ы могут быть сокращены до /, /contact и /blog.

Теперь каждый запрос будет обрабатываться одинаково. Вместо отдельных URL’ов, выполняющих отдельные PHP файлы, front controller выполняется всегда, и маршрутизация различных URL’ов производится внутри него. Это решает обе проблемы оригинального подхода. Все современные приложения работают по такому принципу, включая такие приложения, как WordPress.

Оставайтесь организованным

Но как вы узнаете внутри вашего front controller’а, какая страница должна быть отрендерена и выведена? Так или иначе, вы должны проверить входящий URI и выполнить различные части вашего приложения, в зависимости от его значения. Это можно сделать ужасно быстро:

// index.php
 
$request = Request::createFromGlobals();
$path = $request->getPathInfo(); // the URL being requested
 
if (in_array($path, array('', '/')) {
    $response = new Response('Welcome to the homepage.');
} elseif ($path == '/contact') {
    $response = new Response('Contact us');
} else {
    $response = new Response('Page not found.', 404);
}
$response->send();

Решение этой проблемы может быть затруднительным. К счастью, это имено то, для чего создана Symfony.

Выполнение приложения Symfony

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

Входящий запрос интерпретируется роутером и передается методам контроллера, возвращающим объекты Response.

Каждая страница вашего сайта определяется в файле конфигурации роутинга, который направляет различные URL’ы различными PHP функциям. Работой каждой функции вызываемой контроллером, является использование информации из запроса, наряду с другими инструментами Symfony делающими доступными создание и возвращение объекта Response. Другими словами, контроллер, это то, где проходит ваш код: место, где вы интерпретируете запрос и создаете ответ.

Это так просто! Давайте рассмотрим:

• Каждый запрос выполняется в файле front controller’а;
• Система роутинга определяет, какая PHP функция будет выполнена, основываясь на информации из запроса и конфигурации роутинга, созданного вами;
• PHP функция будет корректно выполнена тогда, когда ваш код создаст и вернет соответствующий объект Response.

Symfony Request в действии

Давайте рассмотрим этот процесс в действии без погружения в детали. Пускай вы хотите добавить в ваше Symfony приложение страницу /contact. Сперва начнем с добавления записи в ваш конфигурационный файл роутинга.

contact:
    pattern:  /contact
    defaults: { _controller: AcmeDemo:Main:contact }

Примечание:

В этом примере, для объявления конфигурации роутинга используется YAML

Когда кто-нибудь посетит страницу /contact, маршрут совпадет и выполнится специфичный контроллер. Как вы узнаете в главе маршрутизация, AcmeDemo:Main:contact это сокращение, указывающее на метод contactAction внутри класса MainController:

class MainController
{
    public function contactAction()
    {
        return new Response('<h1>Contact us!</h1>');
    }
}

В этом очень простом примере, контроллер просто создает объект Response с HTML содержимым “<h1>Contact us!</h1>”. В главе контроллер вы узнаете, как контроллер может вывести шаблон, позволяющий вашему “презентационному” коду (т.е. всему, что может быть в HTML) находиться в отдельных файлах шаблона. Это позволяет заботиться только о сложным вещах: взаимодействию с базой данных, обработкой поступивших данных или отправкой email сообщений.

Symfony2: стройте ваши приложения, а не инструменты

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

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

Автономные инструменты: Компоненты Symfony2

Итак, что такое Symfony? Во первых, Symfony2 коллекция свыше двадцати независимых библиотек, которые могут быть использованы внутри любого PHP проекта. Эти библиотеки, называющиеся компонентами Symfony2, содержат что-то полезное практически для любой ситуации, независимо от того, как разработан ваш проект. Перечислим некоторые:

• HttpFoundation – содержит классы Request и Response, также как и другие классы для обработки сессий и загрузки файлов;
• Routing – мощная и быстрая система маршрутизации, позволяющая вам указывать специфичный URI (например /contact) некоторой информации о том, как будет обработан запрос (например выполнить метод contactAction());
• Form – полнофункциональный и гибкий фреймворк для создания и обработки форм;
• Validation – система создания правил для данных, а затем проверки представленных пользователем данных на следование этим правилам;
• ClassLoader – библиотека автозагрузки, позволяющая вызывать классы без непосредственного подключения;
• Templating – инструмент для рендеринга шаблонов, поддерживает наследование шаблонов (т.е. шаблоны оборачиваются в лайауты) и выполняет другие общие задачи;
• Security – мощная библиотека для поддержки всех видов безопасности внутри приложения;
• Translation – фреймворк, для перевода текста в вашем приложении.

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

Итог: Symfony2 Framework

Итак, что же такое фреймворк Symfony2? Фреймворк Symfony2 это PHP библиотека, выполняющая две основные задачи:

• Предоставление выбора компонентов (т.е. компонентов Symfony2) и сторонних библиотек (например Swiftmailer для отравки почты);
• Предоставление удобной конфигурации и “клея”, связывающего библиотеки друг с другом.

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

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

• Создание маршрута:
  Маршрут определяет URI (например /about) для вашей страницы, а также контроллер (PHP функция), который Symfony2 должен выполнить, когда URI входящего запроса совпадет шаблоном маршрута;
• Создание контроллера:
  Контроллер – это PHP функция, которая принимает входящий запрос и трансформирует его в объект Response (ответ).

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

Страница “Hello Symfony!”

Давайте начнем с классического приложения “Hello World!”. Когда мы закончим, пользователь будет иметь возможность получить персональное приветствие, перейдя по следующему URL:

http://localhost/app_dev.php/hello/Symfony

Вы также сможете заменить “Symfony” на другое имя и получить новое приветствие. Для создания этой страницы мы
пройдем простой путь из двух шагов.

Данное руководство подразумевает, что вы уже скачали Symfony2 и настроили ваш вебсервер. URL, указанный выше, подразумевает, что localhost указывает на web-директорию вашего нового Symfony2 проекта. Если же вы ещё не выполнили этих шагов, рекомендуется их выполнить, прежде чем вы продолжите читать.

  php app/console init:bundle "Acme\StudyBundle" src

$loader->registerNamespaces(array(
    'Acme'                         => __DIR__.'/../src',
    // ...
));

// app/AppKernel.php
public function registerBundles()
{
    $bundles = array(
        // ...
        new Acme\StudyBundle\AcmeStudyBundle(),
    );
    // ...
    return $bundles;
}

// src/Acme/StudyBundle/Controller/HelloController.php
 
namespace Acme\StudyBundle\Controller;
use Symfony\Component\HttpFoundation\Response;
 
class HelloController
{
    public function indexAction($name)
    {
        return new Response('<html><body>Hello '.$name.'!</body></html>');
    }
}

  http://localhost/app_dev.php/hello/Ryan

// src/Acme/StudyBundle/Controller/HelloController.php
 
namespace Acme\StudyBundle\Controller;
 
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
 
class HelloController extends Controller
{
    public function indexAction($name)
    {
        return $this->render('AcmeStudyBundle:Hello:index.html.twig', array('name' => $name));
 
        // render a PHP template instead
        // return $this->render('AcmeStudyBundle:Hello:index.html.php', array('name' => $name));
    }
}

// web/app.php
require_once __DIR__.'/../app/bootstrap.php';
require_once __DIR__.'/../app/AppKernel.php';
 
use Symfony\Component\HttpFoundation\Request;
 
$kernel = new AppKernel('prod', false);
$kernel->handle(Request::createFromGlobals())->send();

// app/AppKernel.php
public function registerBundles()
{
    $bundles = array(
        new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
        new Symfony\Bundle\SecurityBundle\SecurityBundle(),
        new Symfony\Bundle\TwigBundle\TwigBundle(),
        new Symfony\Bundle\MonologBundle\MonologBundle(),
        new Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle(),
        new Symfony\Bundle\DoctrineBundle\DoctrineBundle(),
        new Symfony\Bundle\AsseticBundle\AsseticBundle(),
        new Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle(),
        new JMS\SecurityExtraBundle\JMSSecurityExtraBundle(),
 
        // register your bundles
        new Acme\StudyBundle\AcmeStudyBundle(),
    );
 
    if (in_array($this->getEnvironment(), array('dev', 'test'))) {
        $bundles[] = new Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();
    }
 
    return $bundles;
}

// src/Acme/TestBundle/AcmeTestBundle.php
namespace Acme\TestBundle;
 
use Symfony\Component\HttpKernel\Bundle\Bundle;
 
class AcmeTestBundle extends Bundle
{
}

// app/AppKernel.php
public function registerBundles()
{
    $bundles = array(
        // ...
 
        // register your bundles
        new Acme\TestBundle\AcmeTestBundle(),
    );
 
    // ...
 
    return $bundles;
}

php app/console init:bundle "Acme\TestBundle" src

  http://localhost/app_dev.php/hello/Ryan

  http://localhost/app.php/hello/Ryan

  rm -rf app/cache/*

// app/AppKernel.php
public function registerContainerConfiguration(LoaderInterface $loader)
{
    $loader->load(__DIR__.'/config/config_'.$this->getEnvironment().'.yml');
}

В ходе разбора полетов решил уяснить, работает ли eAccelerator c php-cli. Собственно с подсказки @ibulatenko забрел на страницу http://eaccelerator.net/wiki/Faq, на которой черным по вебу написано в самом низу страницы:

Is eAccelerator working with php-cgi or php-cli?
This is not yet supported and it won’t be supported in the near future. However FastCGI is supported.

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

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

Итак, расслабьтесь, и внимайте.

./app/console_dev assets:install web --symlink

namespace SensioHelloBundleController;
use SymfonyBundleFrameworkBundleControllerController;
class HelloController extends Controller
{
    // ...

// config/ProjectConfiguration.class.php
public function setup()
{
    $this->enableAllPluginsExcept(array(/* some plugins here */));
}

// app/AppKernel.php
public function registerBundles()
{
    $bundles = array(
        new SymfonyBundleFrameworkBundleFrameworkBundle(),
        new SymfonyBundleTwigBundleTwigBundle(),
        // ...
        new SensioHelloBundleHelloBundle(),
    );

    return $bundles;
}

// app/autoload.php
$loader = new UniversalClassLoader();
$loader->registerNamespaces(array(
    'Symfony'                        => __DIR__.'/../vendor/symfony/src',
    'Sensio'                         => __DIR__.'/../src',
    // ...
));

# app/config/routing.yml
hello:
    resource: @HelloBundle/Resources/config/routing.yml

Имеем цикл по получателям, который чанками (страницами, как вам будет удобнее) обходит всех наших потенциальных получателей. Каждый чанк формирует свою партию писем посредством Swift_Mailer::batchSend(). И вот допустим ситуацию, когда враги сожгли родную хату… нет не так, враги заменили несколько email на нечто, не соответствующее требованиям RFC. Что произойдет? А то и произойдет – Swift вызовет исключение и

а) процесс рассылки вообще упадет, если try ... catch у вас нет

б) чанк выпадет из рассылки, если try ... catch у вас есть.

Обе ситуации мне лично не нравятся. Поэтому я решил произвести валидацию адреса до фактического попадания его в чанк.

Первая инкарнация использовала sfValidatorEmail (ну конечно, он предназначен для использования в формах, но если немного попрыгать с бубном и добавить к этому try ... catch – получается более менее юзабельно (clean() в sfValidatorRegex тоже кастует исключение, ага). Тем не менее тестирование выявило несостоятельность такого подхода, так как sfValidatorEmail в некоторых случаях не отлавливал несоответствия RFC.

Логично в этом месте воспользоваться встроенным в Swift механизмом валидации. Ан не тут то было. Публично доступного валидатора я не нашел, греп по коду выявил что валидация происходит в недрах класса Swift_Mime_Headers_AbstractHeader (да, абстрактного класса), ну или если ближе к народу, то в Swift_Mime_Headers_MailboxHeader (кстати загляните в реализацию – на мой вкус и цвет это самый большой регэксп на email который я когда либо видел!).

Итого, вот сниппет валидации:

<?php
...
// энкодер - нужен для инициализации MailboxHeader
$encoder = new Swift_Mime_HeaderEncoder_Base64HeaderEncoder();
...
// цикл по получателям в текущем чанке
foreach( ... )
{
  try
  {
    // собственно валидация. обязательно используйте try/catch
    $header = new Swift_Mime_Headers_MailboxHeader( 'To', $encoder );
    $header->setNameAddresses( array( $email ) );
    // если тут не упали с исключением, адрес валидный - добавляем в нашу пачку получателей
    ...
  }
  catch( Exception $e )
  {
    // email невалидный - следующая итерация
    continue;
  }
}
...

Дочитали до этого места? Прониклись значимостью идеи? А теперь забудьте его… страшненько оно как-то смотрится!

p.s. если знаете более цивилизованный способ валидации по версии Swift – напишите пожалуйста )