Комментарии 87
Статья хорошая, но я хотел бы добавить к этой статье ссылку на перевод книги «Полное руководство по symfony». Поможет, если останутся вопросы.
Там не самый полный перевод. Вот я тут ссылочек немного собрал, там есть полнее переводы.
Добавил раздел "Ссылки по теме".
по вашей ссылке не "полное руководство" а только первые четыре главы.
а здесть шесть глав, и перевод мне кажеться более "правильным"
http://developer.co.ua/posts/view_tag/sy…
а здесть шесть глав, и перевод мне кажеться более "правильным"
http://developer.co.ua/posts/view_tag/sy…
А может научимся по ссылкам ходить? Вот самый полный вариант перевода...
спасибо, отличная статья; слипаются глаза, почти 3 ночи, а я сижу устанавливаю =))
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Автору - респект и уважуха. Читал посты людей об их любимых фреймворках, а сам все думал - неужели никто про Симфони не слышал?! А вещь - более чем перспективная. Сам я начинающий, пока в стадии прочтения их книги и степ-бай-степ приложения.. Вообще круто, автор, пиши еще!
Собственно, гордитесь, своё дело вы сделали... помогли мне с выбором первого фреймворка :) буду изучать что есть фреймворк начиная с Symphony.
P.S. Плюсик поставил ;)
P.S. Плюсик поставил ;)
fxposter, да и все кто здесь, може привести примеры проектов организованных с помощью Symfony?
Русскоязычных проектов на ней очень мало. Я вообще смотрю, что в Рунете про Symfony вообще практически ничего не говорят. А зря...
А ссылки вот: Applications Developed With Symfony и Symfonians.
А ссылки вот: Applications Developed With Symfony и Symfonians.
НЛО прилетело и опубликовало эту надпись здесь
у меня сайт в профиле на симфони например ;) Сначала плевался от сложности системы шаблонов - партиалы, компоненты, слоты ... Но потом стало понятно, что 1. благодаря этому можно очень гибко курочить структуру шаблона от модуля к модулю (а не тупо menu, content). 2. система шаблонов и кусков кода рассчитана на ajax, при его использовании сразу становится понятно, зачем там только нагородили с шаблонами.
А у вас там отдельный сервер или обычный хостинг?
Я делал один проект на симфони - на локальной машине все ок было, на хостинговой - 6-12сек простейшие страницы грузились((
Я делал один проект на симфони - на локальной машине все ок было, на хостинговой - 6-12сек простейшие страницы грузились((
Сервер. На локалке он у меня работает раз в 20 медленнее - сказывается видимо ноутбучный винт, винда, отсутствие APC.
APC установлен на хостинге? Propel генерирует вагон php-кода и этим сильно тормозит симфони (видно в dev environment по потреблению памяти, да и по скорости), так что без кешера сложно.
APC установлен на хостинге? Propel генерирует вагон php-кода и этим сильно тормозит симфони (видно в dev environment по потреблению памяти, да и по скорости), так что без кешера сложно.
Странно, у меня на 1.2г ноуте то же самое за 100-200мс грузилось, без ускорителей. С уск. еще быстрее.
На том долбанном хостинге такого ничего нет, и не предвитится. Проблема в том, что у клиента на том хостинге 10 сайтов стоит, почта так же, поэтому на переезд он не соглашался. Я пытался сам скомпилить какой-ниб ускорятель (о, там был Зенд Оптимизер, но симфони он кажется никак не поможет), но там небыло никаких средств компиляции и стояла солярка. Я уж и в гугл-групс спрашивал, но ничего не помогло.
6-12 сек. грузилось после удаления кеша,
4-8 сек. - в обычном режиме.
Оба замера - в продуктивном окружении...
Скорей придется в чистом пхп переписывать.
На том долбанном хостинге такого ничего нет, и не предвитится. Проблема в том, что у клиента на том хостинге 10 сайтов стоит, почта так же, поэтому на переезд он не соглашался. Я пытался сам скомпилить какой-ниб ускорятель (о, там был Зенд Оптимизер, но симфони он кажется никак не поможет), но там небыло никаких средств компиляции и стояла солярка. Я уж и в гугл-групс спрашивал, но ничего не помогло.
6-12 сек. грузилось после удаления кеша,
4-8 сек. - в обычном режиме.
Оба замера - в продуктивном окружении...
Скорей придется в чистом пхп переписывать.
Ecли у вас на странице много объектов (пару сотен), то их hydration из sql тоже может подтормаживать. + Кеширование в симфони достаточно навороченное - можно кешей наделать.
В общем, не знаю :( У меня строго обратная ситуация, на локалке я плакалЪ, глядя на timer, залил на сервер - успокоился.
В общем, не знаю :( У меня строго обратная ситуация, на локалке я плакалЪ, глядя на timer, залил на сервер - успокоился.
НЛО прилетело и опубликовало эту надпись здесь
Что-то линк "съелся"
jobterra.com - поиск работы и подбор персонала
jobterra.com - поиск работы и подбор персонала
Такое впечатление будто на сайте просто решили показать возможности Symfony... ничего больше.
Этот комментарий предназначался пользователю zakon и был примером простого проекта на symfomy (этот проект, кстати, позволит ознакомиться с возможностями symfomy и Вам тоже). Почему простого? Потому, что наиболее посещаемые сайты для поиска работы изобилуют функциями, использование которых может поставить в тупик пользователей с низкой квалификацией. Указанный проект - желание сделать сложные вещи проще. Я осознано не стал "раздувать" меню и "накачивать" страницы графикой. Небольшое число ссылок позволяет пользователю быстро найти нужную функцию, а минимум графики - экстремально повышает скорость загрузки страниц (результаты сравнительных тестов можно найти в блоге).
symfony - мощный и сложный framework. Не зря считается, что в него довольно тяжело "входить". Если у читателей возникнут вопросы по symfony, буду рад на них ответить.
symfony - мощный и сложный framework. Не зря считается, что в него довольно тяжело "входить". Если у читателей возникнут вопросы по symfony, буду рад на них ответить.
Из интересного: Yahoo! Bookmarks и LionPages
НЛО прилетело и опубликовало эту надпись здесь
Перенес статью в блог Symfony.
Замечание:
"Все модели хранятся в одном (или нескольких) YAML-файлах. К написанию моделей привыкаешь за 3—4 дня. Из YAML модель с помощью одной комманды преобразуется в автоматически сгенерированные базовые классы ORM (Propel или Doctrine). Всё быстро, просто и аккуратно."
Насколко я понял тут вы говорите о схемах, а не о модели. Уровень модели не может быть в YAML'е, так как модель это выполняемый код. Наверное не стоит говорить, что под моделью нужно всё-таки понимать всё то, что хранится в lib/model/
А за статью спасибо. Полгода работаю с Симфони, и знаете, так приятно увидеть на Хабре знакомое слово :)
"Все модели хранятся в одном (или нескольких) YAML-файлах. К написанию моделей привыкаешь за 3—4 дня. Из YAML модель с помощью одной комманды преобразуется в автоматически сгенерированные базовые классы ORM (Propel или Doctrine). Всё быстро, просто и аккуратно."
Насколко я понял тут вы говорите о схемах, а не о модели. Уровень модели не может быть в YAML'е, так как модель это выполняемый код. Наверное не стоит говорить, что под моделью нужно всё-таки понимать всё то, что хранится в lib/model/
А за статью спасибо. Полгода работаю с Симфони, и знаете, так приятно увидеть на Хабре знакомое слово :)
НЛО прилетело и опубликовало эту надпись здесь
Сравнение Cake, Solar, Symfony, Zend:
http://paul-m-jones.com/blog/?p=238
Тесты CodeIgniter, Symfony, ROR, Django:
http://www.alrond.com/ru/2007/jan/25/rez…
http://paul-m-jones.com/blog/?p=238
Тесты CodeIgniter, Symfony, ROR, Django:
http://www.alrond.com/ru/2007/jan/25/rez…
НЛО прилетело и опубликовало эту надпись здесь
Субьективно, Symfony - это лучшее из того, что я видел на данный момент из PHP-фреймворков. По скорости - средний (но офигенная система кеширования должна этот недостаток вполне себе скрыть). По гибкости - настроить тут можно практически всё, причем настраивать можно как на уровне приложений, так и на уровне отдельных модулей и даже action'ов.
Пробовал я CodeIgniter и CakePHP. CI хорош тем, что быстрый (хотя опять же - это дело поправимое) и легкий в изучении. Я сам Symfony где-то год назад для себя открыл, попробовал, и... сказал себе - "нет, это не для меня. слишком сложно...". Прошел год, многое поменялось, я немного повысил свою квалификацию :))) и теперь мой выбор - Symfony.
Пробовал я CodeIgniter и CakePHP. CI хорош тем, что быстрый (хотя опять же - это дело поправимое) и легкий в изучении. Я сам Symfony где-то год назад для себя открыл, попробовал, и... сказал себе - "нет, это не для меня. слишком сложно...". Прошел год, многое поменялось, я немного повысил свою квалификацию :))) и теперь мой выбор - Symfony.
НЛО прилетело и опубликовало эту надпись здесь
Я смотрю, вы постоянно сравниваете с Django, видимо раньше пользовались им?
Symphony нравится больше или просто захотелось попробовать что-то другое?
Я пока пользовался только cakephp и Zend framework. Сейчас в раздумьях, что попробовать следующим: Джанго или симфони. Или вообще рэилз...
Symphony нравится больше или просто захотелось попробовать что-то другое?
Я пока пользовался только cakephp и Zend framework. Сейчас в раздумьях, что попробовать следующим: Джанго или симфони. Или вообще рэилз...
Скажем так - я его изучал (Django). Реальных каких-то приложений делать не пришлось. А с Symfony я потому, что работаю PHP-программистом, поэтому и выбирал исключительно из PHP-фреймворков.
Насчет того, что выбрать - если нет ограничений на язык - я бы попробовал Django или RoR (конкретнее - лучше выбирай сам, тут уже кому что нравиться). Если же желательно всё же остаться на PHP - можешь попробовать Symfony, но при этом про ZF не забывай.
Насчет того, что выбрать - если нет ограничений на язык - я бы попробовал Django или RoR (конкретнее - лучше выбирай сам, тут уже кому что нравиться). Если же желательно всё же остаться на PHP - можешь попробовать Symfony, но при этом про ZF не забывай.
Советую людям, пишушим на симфони, внимательно присмотреться к Doctrine в качестве замены Propel.
Пропел на сложных моделях (большое количество связей многие-ко-многим, сложные джойны, сложные условия) сильно затрудняет разработку, вместо того, чтоб ее облегчать. Doctrine со своим языком DQL гораздо более гибок.
Посмотрите хотя бы на Propel Criteria builder. Там в качестве примера в форму уже вставлен не очень сложный запрос — однако в виде Criteria он занимает 11 (!!) строк кода. По-моему, это неприемлимо.
Doctrine — куда более зрелый ORM, чем Propel. У него есть нормальная документация, он поддерживает кэширование (в том числе через memcached), наследование (4-мя разными способами), шаблоны классов, транзакции — те вещи, которые в Пропеле не реализованы вообще или реализованы совсем слабо.
Кстати, интересно заметить, что Doctrine - PHP-клон Hibernate (ORM на Java), Propel - клон Apache Torque (тоже ORM на Java). Насколько мне известно, люди, пишушие на яве, в основном пользуются Hibernate-ом, что тоже о чем-то говорит.
Пропел на сложных моделях (большое количество связей многие-ко-многим, сложные джойны, сложные условия) сильно затрудняет разработку, вместо того, чтоб ее облегчать. Doctrine со своим языком DQL гораздо более гибок.
Посмотрите хотя бы на Propel Criteria builder. Там в качестве примера в форму уже вставлен не очень сложный запрос — однако в виде Criteria он занимает 11 (!!) строк кода. По-моему, это неприемлимо.
Doctrine — куда более зрелый ORM, чем Propel. У него есть нормальная документация, он поддерживает кэширование (в том числе через memcached), наследование (4-мя разными способами), шаблоны классов, транзакции — те вещи, которые в Пропеле не реализованы вообще или реализованы совсем слабо.
Кстати, интересно заметить, что Doctrine - PHP-клон Hibernate (ORM на Java), Propel - клон Apache Torque (тоже ORM на Java). Насколько мне известно, люди, пишушие на яве, в основном пользуются Hibernate-ом, что тоже о чем-то говорит.
По-моему, это неприемлимо.
Вполне приемлемо. Не передергивай. :)
Да и вообще - слишком рано ты затронул эту тему. Это отдельный и довольно долгий разговор. Вот здесь я немного писал о Propel'е и сравнивал его с Doctrine'ой... Да, Доктрина гибче, функциональнее, но и... тормознее.
Вполне приемлемо. Не передергивай. :)
Да и вообще - слишком рано ты затронул эту тему. Это отдельный и довольно долгий разговор. Вот здесь я немного писал о Propel'е и сравнивал его с Doctrine'ой... Да, Доктрина гибче, функциональнее, но и... тормознее.
Есть и еще причины выбрать именно Propel - лучшая интеграция с Symfony, наличие очень многих дополнений (в частности, Behavoir'ы), а также то, что большая часть плагинов Symfony ориентирована именно на Propel...
По поводу Behavior-ов: в Доктрине есть реализация Nested Set, а также Class Templates с набором готовых шаблонов. Ну, плагины, ориентированные на пропел - да, тут сложно поспорить. Хорошо, что хотя бы sfGuard портирован. Остальные в общем-то не так уж и нужны (либо не используют пропел).
Ну вообще еще хотелось бы Blog и Forum плагины... SimpleCMS, насколько я помню, уже существует...
Есть и еще один бок - официальная поддержка. Многие плагины работают совсем не так, как хотелось бы. Некоторые вообще имеют явные баги... Вот если бы Symfony полностью перешла на doctrine - я бы был ОЧЕНЬ рад, а пока - использую Propel.
PS. Еще одно - у меня на хостинге проектном нет PDO_MySQL... ПОэтому Propel'овская Creole пришлась весьма кстати.
Есть и еще один бок - официальная поддержка. Многие плагины работают совсем не так, как хотелось бы. Некоторые вообще имеют явные баги... Вот если бы Symfony полностью перешла на doctrine - я бы был ОЧЕНЬ рад, а пока - использую Propel.
PS. Еще одно - у меня на хостинге проектном нет PDO_MySQL... ПОэтому Propel'овская Creole пришлась весьма кстати.
По ссылке в блоге написано почти то же самое, что и я написал :)
А 11 строк кода, чтобы реализовать запрос в полторы строчки я не знаю как еще охарактеризовать, по-моему, "неприемлимо" — вполне подходит :)
На самом деле проблема Propel-а (ну и Apache Torque тоже, соответственно) в том, что они пытаются совершенно абстрагироваться от базы данных, чтобы программист работал только с объектами. А такой подход работает только для простых моделей, потому что реляционные БД и ООП - это все-таки сильно разные вещи.
Тормознутость доктрины (что, впрочем, спорно, я сам никаких сведений на эту тему не имею) компенсируется поддержкой кэширования, например.
А 11 строк кода, чтобы реализовать запрос в полторы строчки я не знаю как еще охарактеризовать, по-моему, "неприемлимо" — вполне подходит :)
На самом деле проблема Propel-а (ну и Apache Torque тоже, соответственно) в том, что они пытаются совершенно абстрагироваться от базы данных, чтобы программист работал только с объектами. А такой подход работает только для простых моделей, потому что реляционные БД и ООП - это все-таки сильно разные вещи.
Тормознутость доктрины (что, впрочем, спорно, я сам никаких сведений на эту тему не имею) компенсируется поддержкой кэширования, например.
Ну не знаю, у меня в проекте пока таких длинных работ с Criteria делать не приходилось.
Hint: у Criteria реализован chaining: $c-add()->add()... И никаких 11 строк не будет.
Насчет тормознутости: получите и распишитесь. :)
Hint: у Criteria реализован chaining: $c-add()->add()... И никаких 11 строк не будет.
Насчет тормознутости: получите и распишитесь. :)
Если ты еще не понял - я не спорю, что доктрина сама по себе лучше (хотя и прилично тормознее, опять же). Я спорю с тем, что она лучше в использовании с Symfony.
Согласно вышеприведенной ссылке разница в быстродействии с Пропелом незначительная — 6-7 против 9 — это даже не в два раза разница. То есть если скорость работы ORM станет ограничивающим фактором при быстродействии, то замена Доктрины на Пропел не спасет совершенно, придется применять какие-то радикальные меры, вроде кэширования.
Вот, и учитывая, что деньги, сэкономленные на времени разработки при использовании Доктрины, явно перевешивают деньги, затраченные на небольшое замедление работы, зачем спорить, что Доктрина лучше с Симфони? :)
Вот, и учитывая, что деньги, сэкономленные на времени разработки при использовании Доктрины, явно перевешивают деньги, затраченные на небольшое замедление работы, зачем спорить, что Доктрина лучше с Симфони? :)
Посмотри вторую ссылку. И ты поймешь, что там не "незначительно", там отрыв пропела в 1.5-2 раза, причем если работать с большими обьемами данных Doctrine еще и жутко просаживается вплоть до отказов.
> зачем спорить, что Доктрина лучше с Симфони?
Затем, что Propel быстрее, и затем, что куча плагинов заточена именно под Propel.
> зачем спорить, что Доктрина лучше с Симфони?
Затем, что Propel быстрее, и затем, что куча плагинов заточена именно под Propel.
Если так рассуждать - кодеигнитер вообще в разы быстрее чем симфони с пропелом. Почему же ты тогда все равно выбрал симфони?
Я хочу сказать, что скорость исполнения не всегда должна быть решающим фактором при выборе инструмента. В каких-то случаях это оправдано, конечно (во всяких системах с высокой нагрузкой), но чаще выгоднее использовать инструмент, экономящий время разработки и потом уже при необходимости оптимизировать скорость (кэшированием, акслераторами и т.п.)
Я хочу сказать, что скорость исполнения не всегда должна быть решающим фактором при выборе инструмента. В каких-то случаях это оправдано, конечно (во всяких системах с высокой нагрузкой), но чаще выгоднее использовать инструмент, экономящий время разработки и потом уже при необходимости оптимизировать скорость (кэшированием, акслераторами и т.п.)
> Doctrine — куда более зрелый ORM, чем Propel
Как же он может быть зрелым, если еще осенью там ничего толком не было кажется, одни беты и to do. Не понимаю.
Как же он может быть зрелым, если еще осенью там ничего толком не было кажется, одни беты и to do. Не понимаю.
Я на свой первый проект ставил Doctrine, но работать довелось с Пропелом. Согласен, основыне минусы Propel - отсутствие PDO, длинный код, неудобные запросы через критерии (каждый раз при сложном запросе нужно смотреть в справочник), кеширование объектов я писал сам.
А вообще чтоб полностью и безболезненно перетйти на Доктрину нужно дождаться пока разработчики добавят промежуточный ORM-уровень. В задачах для Google Summer Code это есть, и я надеюсь у них получиться.
А вообще чтоб полностью и безболезненно перетйти на Доктрину нужно дождаться пока разработчики добавят промежуточный ORM-уровень. В задачах для Google Summer Code это есть, и я надеюсь у них получиться.
Большое спасибо, ценный материал. Как раз собираюсь с CakePHP переходить на что-то более разумное.
Хотелось бы увидеть сравнение с Zend Framework. Я сейчас его использую.
По поводу разделени проект/приложение.
По поводу разделения на проект / приложение хочу сказать что проект это вовсе не обязательно один сайт! Это может быть многосайтовый движок работающий на одной базе. В этом случае для каждого сайта разумно делать отдельный frontend-application а вот backend-application лучше наверное сдлеать один.
По поводу модулей.
> … содержат в себе контроллер с действиями и представления (т.е. MV из MVC),
VC вообще-то.
По поводу скаффолдинга - мне лично непонятно зачем генерить CRUD на начальных стадиях развития проекта, по мне так лучше сразу юзать Symfony admin generator.
А так, в целом, статья понравилась. Всё грамотно, коротко и по делу.
По поводу разделения на проект / приложение хочу сказать что проект это вовсе не обязательно один сайт! Это может быть многосайтовый движок работающий на одной базе. В этом случае для каждого сайта разумно делать отдельный frontend-application а вот backend-application лучше наверное сдлеать один.
По поводу модулей.
> … содержат в себе контроллер с действиями и представления (т.е. MV из MVC),
VC вообще-то.
По поводу скаффолдинга - мне лично непонятно зачем генерить CRUD на начальных стадиях развития проекта, по мне так лучше сразу юзать Symfony admin generator.
А так, в целом, статья понравилась. Всё грамотно, коротко и по делу.
Ошибся, там MVC, а не MV.
по мне так лучше сразу юзать Symfony admin generator.
А потом всё пытаться подстроить так, как нужно? Времени уйдет больше, чем разрабатывать с нуля.
по мне так лучше сразу юзать Symfony admin generator.
А потом всё пытаться подстроить так, как нужно? Времени уйдет больше, чем разрабатывать с нуля.
> Ошибся, там MVC, а не MV.
Если быть совсем уж точным, то в модулях содержится часть View и часть Controller.
Но это не принципиально. А по поводу скаффолдинга - я всего лишь высказал своё мнение потому как мне так удобней.
Если быть совсем уж точным, то в модулях содержится часть View и часть Controller.
Но это не принципиально. А по поводу скаффолдинга - я всего лишь высказал своё мнение потому как мне так удобней.
>...по мне так лучше сразу юзать Symfony admin generator.
>А потом всё пытаться подстроить так, как нужно? Времени уйдет больше, чем разрабатывать с нуля.
Не согласен, уж очень мощно настраивается генератор админки в симфонии.
Необходимо потратить время на изучение всех опций, которые в книге описаны далеко не все.
Конечно же не каждый функционал админки можно привязать к той или иной табличке БД.
Но и в этом случае ИМХО стоит воспользоваться генератором, хотя бы ради каркаса.
>А потом всё пытаться подстроить так, как нужно? Времени уйдет больше, чем разрабатывать с нуля.
Не согласен, уж очень мощно настраивается генератор админки в симфонии.
Необходимо потратить время на изучение всех опций, которые в книге описаны далеко не все.
Конечно же не каждый функционал админки можно привязать к той или иной табличке БД.
Но и в этом случае ИМХО стоит воспользоваться генератором, хотя бы ради каркаса.
sfproject.ru лежит уже неделю как минимум
Symfony - достаточно интересный и гибкий инструмент. Но что за этим скрывается? - Тормоза.... Время для генерации элементарных страниц достигает катастрофических величин. К тому же, господа, если вы хоть на секунду задумываетесь об енкодинге(криптовании) своих php проектов такой утилитой как ZendGuard к примеру, то забудьте о Symfony. Она в криптованом виде работать не в состоянии. А все из за ее дибильного php кэша :). Без которого она воще работать не может, даже если его отключить.
Так что удачи Симфонисты.... А вот ZF зря опускали, очень рульная вещь, но конечно телодвижений надо делать побольше, и хотя он и молодой фреймворк, но объектная модель уж куда покруче чем симфони.
Так что удачи Симфонисты.... А вот ZF зря опускали, очень рульная вещь, но конечно телодвижений надо делать побольше, и хотя он и молодой фреймворк, но объектная модель уж куда покруче чем симфони.
НЛО прилетело и опубликовало эту надпись здесь
> Время для генерации элементарных страниц достигает катастрофических величин
Первый запуск, когда все-все-все конфиги парсятся, а не тянутся из кэша, когда незакешированы темплэты это конечно да, жесть. Но возможности улучшение производительности очень существенны - в книге целая глава об этом написана. Ну и самое главное - реальный практический пример двух проектов Yahoo, написанных на Symfony.
Первый запуск, когда все-все-все конфиги парсятся, а не тянутся из кэша, когда незакешированы темплэты это конечно да, жесть. Но возможности улучшение производительности очень существенны - в книге целая глава об этом написана. Ну и самое главное - реальный практический пример двух проектов Yahoo, написанных на Symfony.
Спасибо большое за статью.
Сейчас стою на распутье и решаю какой фрейморк выбрать. Вот думаю с симфони и останусь, сообщество большое, написано много про него, плагины и прочие полезности.
Еще раз спасибо.
Сейчас стою на распутье и решаю какой фрейморк выбрать. Вот думаю с симфони и останусь, сообщество большое, написано много про него, плагины и прочие полезности.
Еще раз спасибо.
два приложения: frontend и backend (для русскоязычной аудитории термин «админка» в данном случае будет более уместен).
Забавно… а я то думал что fronted это всякие там шаблоны (вывод страниц, то что видно в браузере), а backend это скрипты… к примеру вычисление того что выдать в качестве контента в fronted…
Документация по Symfony 3 на русском
symfony.com.ua
symfony.com.ua
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Symfony: как начать