Комментарии 56
Хорошо бы указать, что предпочтительнее создавать формы-классы, создание форм в контроллере — не лучшая практика. Формы-классы проще в тестировании и переиспользуемы. Об этом кстати описано в официальной документации.
Не могли бы вы привести ссылку или показать пример? В документации, даже в разделе о формах в «best practices», формы создаются как в статье:
public function newAction(Request $request)
{
    $post = new Post();
    $form = $this->createForm(PostType::class, $post);
    // ...
}

код взят с http://symfony.com/doc/current/best_practices/forms.html
Так ведь в данном переводе форма так и создается, через формы-классы, или я не прав? Я совсем недавно начал разбираться с symfony, так что возможно я что-то упускаю
This example shows you how to build your form directly in the controller. Later, in the «Creating Form Classes» section, you'll learn how to build your form in a standalone class,
which is recommended as your form becomes reusable.
извиняюсь. не заметил что пост обновили. в начальной версии поста использовался билдер в контроллере.
(PostType::class, $post);

Вся форма на самом деле задается внутри PostType.

Да, я уже разобрался, просто я читал эту статью в той версии, в которой она сейчас и прочитав комментарий maximkou подумал, что есть более предпочтительный способ, чем тот который описан в статье.
Несколько небольших изменений
Конструкцию
$this->redirect($this->generateUrl('BloggerBlogBundle_contact'));

лучше заменить на
$this->redirectToRoute('BloggerBlogBundle_contact');

, а проверку
$request->getMethod() == 'POST'

лучше заменить на
$request->isMethod($request::METHOD_POST)
Кто тоже считает, что Симфони слишком сложный, вам сюда:
http://blog.kpitv.net/article/frameworks-1/

Кто не считает, можете тоже сходит.
Статья изменит вашу точку зрения на фреймворки.
Не изменила. Фреймфорк это инструмент, как хочешь, так и пользуй. Никто не запрещает его изменять. И никто не запрещает писать свой инструмент. Главное, чтоб нравилось.
А толку с инструмента, который не рабочий?
Вы покупаете молоток в магазине, а потом дорабатываете его и половину выбрасываете? :)
Рабочий.

Беря молоток в руки, не означает, что гвоздь сам забьется. Вы же хотите, от фреймворка, функционал CMS, но фреймворки не об этом.
Фреймворк — это отдельно купить брусок и отдельно держание? :)
О да, это сильно :)
Инструментом либо умеешь пользоваться, либо пилишь молотком.
Нас е**т, а мы крепчаем
— это про вас.
Вас минусуют за пиар своей статьи, а вы все равно вставляете ссылку на нее в каждом посте, который как-то связан с веб-разработкой.
Минусуют не за пиар статьи.
А из-за того, что у людей когнитивный диссонанс, они не могут понять, как можно обойтись без фреймворков.
Минусуют и комменты без ссылок.
А ссылку я вставляю только в постах, связанных с фремворками.
Лично мне без разницы, используете вы фреймворки или нет. Ваше дело.

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

Я против пропаганды фреймворков среди неокрепших умов.
Я навязываю идеологию KISS. :)
А что именно неубедительно? :)
Фреймворки не панацея, согласен. И говнокод порой встречается.

Но реалии бизнеса таковы, что, как правило:
  1. Стартовать нужно в сжатые сроки, а иногда даже вчера. Всем пофиг что вы уже полгода пишете крутое ядро. Бизнесу нужен результат.
  2. Нужны некие стандарты и документация, дабы любой разработчик быстро сориентировался в проекте

Это как минимум. Со всем этим фреймворки справляются неплохо, при этом позволяют поддерживать код в поддерживаемом состоянии.

Раз уж вы заговорили о принципе KISS, то одним из его важных составляющих является сохранение методов/классов маленькими и простыми. Этого я не увидел в коде, который показал нам MetaDone

А что именно неубедительно? :)

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

Например:
При выпуске новых версий как правило отсутствует обратная совместимость. Программисты на фреймворках никогда не останутся без работы.

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

Некоторые фреймворки ориентированы на аннотации (комментарии) — это тихий ужас.

А мне нравятся аннотации. Очень удобно, например, описать роут рядом с обработчиком(экшеном). Субъективно? Да.
>Стартовать нужно в сжатые сроки, а иногда даже вчера.

Зачем брать фреймворк и мудохаться с ним, если можно взять CMS?

>Всем пофиг что вы уже полгода пишете крутое ядро.

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

>Бизнесу нужен результат.

Бизнесом, как правило, управляют те еще стратеги. :)

>Нужны некие стандарты и документация, дабы любой разработчик быстро сориентировался в проекте

Мои 50 КБ можно изучить за день :)
Стандарты должны быть логичными. Если стандартов слишком много и они не логичны — на них всем начхать.

KISS.
Это кусок контроллера.
Я не вижу смысла разбивать функцию на мелкие функции, если не будет повторного использования.
Зачем плодить абстрации?

>семантическое версионирование

Какая разница, какое версионирование?
Вон Битриксы все совместимы.

>А мне нравятся аннотации.

Аннотации могут нравиться, но это путанье мух с котлетами по факту. )
Зачем брать фреймворк и мудохаться с ним, если можно взять CMS?

А cms же у нас конфетка, точно.

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

А пишете вы его дома в свободное время?

Мои 50 КБ можно изучить за день

Ну действительно, зачем документация нужна.

Я не вижу смысла разбивать функцию на мелкие функции, если не будет повторного использования.

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

Вон Битриксы все совместимы.

Вон Вася спился. Давай и я тоже сопьюсь.

Аннотации могут нравиться, но это путанье мух с котлетами по факту. )

Вы считаете что аннотации — ужас. Я считаю, что это удобно. Получается, что ваше мнение субъективно, верно? Субъективно — значит применимо к одному субъекту.
>А пишете вы его дома в свободное время?

А Вы сапожник без сапог? :)

>Ну действительно, зачем документация нужна.

А я и не говорю, что не нужна :)

>чтобы не читать весь код, а увидеть суть

Большинство ИДЕ имеет сворачивание кода.

>Вон Вася спился. Давай и я тоже сопьюсь.

Я ж приводил позитивный пример.

>Субъективно

При чем тут субъективно — не субъективно? Это мешание в кучу мух и котлет.
Пока нигде потому что:
1. Это пока ноу-хау.
2. Я не хочу распространять код, если он будет труднообновляем. Нужно будет завернуть все в композитор, или как. У меня проблем с обновлениями моих сайтов пока нет, поэтому руки не доходят. :)
3. Я бы еще хотел как-то заработать на этом коде. :) Скорее всего не прямо. Возможно что-то вроде расширенной версии, как у нгинкса. :) В композиторе можно использовать сторонние репозитории с ключем доступа?
4. Как решают проблему конфликта классов сущностей другие? То есть какое-то расширение поставляет с собой какие-то сущности. Как обойти конфликты? Пользовательские сущности выносить в неймспейсы?
5. Перед выпуском в паблик стоило бы подчистить немного легаси код, там пару методов ядра.
6. Нужно написать документацию.
7. Я не знаю, как систему встретят, будут ли пользоваться. Если не будут, то смысла как бы и нет выкладывать. :)
Обойтись без фреймворков — это каждый раз собирать молоток для того, чтобы забить гвоздь? Причем молоток не проверенный годами и сотнями забитых гвоздей из дерева и металла, а из ДСП и пластика, который вот-вот сломается, возможно при первом же ударе по гвоздю :)
1. Меня уровень проверки качества фреймворков не устроил.
Они как китайские молотки, как бренды-пустышки (слышал, у Бугатти днище гниет за 2 года :) ). :)
Почему берут фрейворки? Чтобы быстрее (якобы еще дешевле) состряпать продукт.
В результате выходит черти что.
Использовать фреймворк — это использовать кувалду, где нужен средний молоток.
2. Каждый раз собирать молоток не нужно при грамотном подходе. Можно, конечно, мудохаться и в самописи, каждый раз переизобретая ранее собой же изобретенный велосипед, но это тупо.
Какой уровень проверки вы считаете приемлемым? Если это проект на Гитхабе, то его уровень можно посмотреть по количеству открытых/закрытых задач, покрытию тестами и отклику сообщества по тем или иным задачам и вопросам. Или вы что-то другое имеете в виду?
На то они и фреймворки. Некоторые, как Symfony, можно разобрать на отдельные компоненты и взять только то, что нужно. И всё.
А из-за того, что у людей когнитивный диссонанс, они не могут понять, как можно обойтись без фреймворков.

Мы как-то дискутировали с вами, и выяснилось что у вас просто далеко не те проекты, где нужны фреймворки уровня симфони. "бложики" на симфони писать как-то сильно оверхэд.


А вот опыта с проектами того уровня, где фреймворки спасают у вас попросту видимо нет. Так что ваше мнение не заслуживает внимания.

А для каких же проектов стоит использовать фреймворки и почему?
Какие у вас есть такие проекты?

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


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


Бизнес-аналитики накидывают мне юзкейсы/юзерстори (или менеджеры, или я сам их накидываю себе в виду фичаспек по результатам обсуждения), из которых формируется представление о том как что делается. Например краиугольным камнем нашего продукта являются платежи.


Что я делаю, я пишу на PHP (никаких фреймворков пока) сущности, примерно как у нас вышло при декомпозиции задачи. Причем только в рамках той фичи которую я сейчас делаю. Частенько я делаю это дело по TDD. Если мне нужна какая-то функциональность вроде "послать email со счетом" я не бросаю все и пишу очередной мэйлер, а просто делаю интерфейс штуки, которая будет для меня это все делать.


В результате через пару-тройку часов у меня есть вся бизнес логика этой фичи. Как только она готова, и я покрыл тестами все интересующие меня моменты, можно браться за инфраструктуру. Прикручивать базы данных (доктрина, она полностью абстрагирует меня от слоя хранения данных, очень быстро подобные штуки пилить), писать контроллеры для HTTP API (симфони, по сути только то что нужно для http, никаких форм, только валидация запросов + реквесты/респоны, обработка ошибок), реализую сервисы для отправки нотификаций (какие-то библиотеки поставленные через composer + реализация интерфейса который я написал как заглушку для тестов).


Нужно прикрутить авторизацию? пара десятков минут и у меня уже прикручена авторизация через JWT. Нужно сделать запись всех запросов — не проблема, ставим бандл, 15 минут и готово. Нужно гибко управлять правами — symfony/security предоставляет механизм воутеров, с которыми я могу описать даже ооочень сложную логику разграничения прав на раз-два.


Любая стандартная задача — меньше часа с учетом чтения доки и "сходить за кофе". Если внезапно приходит хотелка от клиента "ну мы хотим сделать меганестандартную аутентификацию через 10 разных сервисов" — оке, просто делаю свою реализацию аутентификатора реализующего стандартный интерфейс, предоставляемый мне symfony. Он достаточно гибкий что бы сделать практически все что угодно. А даже если внезапно по каким-то причинам его будет не хватать — не вопрос, делаем полностью свою систему аутентификации сверху нашего приложения, симфони предоставляет мне и такую возможность.


Если мы бложики пишем — симфони скорости разработки нам не добавит в сравнении с фреймворками вроде laravel или просто plain php + composer пакеты. А вот если мы интернет магазин пилим — то существенно ускоряется как написание MVP проекта, так и сопровождение значительно дешевеет.


НО!


Все это хорошо работает потому что я с Symfony и Doctrine работаю уже почти 5 лет, знаю их на очень хорошем уровне изнутри. Так же я стараюсь писать код так, что бы он небыл слишком сильно завязан на фреймворк (инверсия зависимости и все такое). Это происходит естественным образом поскольку я начинаю проектировать систему с бизнес логики а не контроллеров.


А подавляющая масса новичков начинает делать дела с фреймворками даже не прочитав документацию к фреймворку. А ведь если все делать методом тыка — то эффективности фреймворки при разработке не добавляют. То есть что бы фреймворки приносили пользу, их нужно знать хотя бы на базовом уровне. В случае Symfony нужно знать хотя бы те компоненты, которые вы используете повседневно (в моем случае это 5-6 компонентов на самом деле из десятков). То есть нам нужно инвестировать свое время в изучение инструмента что бы его использование начиинало окупаться.


Если без этого… разницы как бы нет, с фреймворком или нет — скорее всего получится неподдерживаемый трэшачек.

Не первый раз вижу ссылку на эту статью. Более того, прочитал несколько раз и попытался осмыслить ее с нейтральной точки зрения. В этом свете возник вопрос — можно ли увидеть код (полностью или часть его) Вашего «ядра», о котором Вы упоминали? Ибо у меня складывается впечатление, что Ваше «ядро» не что иное, как еще один фреймворк.
Я его не называю таким замараным словом, как фреймворк.
И оно легко для понимания, в отличии от фрейморков.
Содержит всего 50Кб.
У меня используются нативные функции языка, а не так, что каждый фреймворк по сути является новым языком.
А пишущие на фреймворках не умеют самостоятельно строить архитектуру.
Также не мое ядро дергает пользовательский код, а пользовательский код дергает ядро.
Это замечательно. А можно все-таки пример увидеть, не часть кода, вырванного из контекста, а целостную картину (git репозитарий, листинг на сайте или др.)?
1. Код пока ноу-хау.
2. Там ничего как бы особенного нет:
автолоадинг
события
работа с языками
кеширование

Просто сделано ради решения задач самым простым способом, а не чрезмерно академически.
Ядро в чем-то божественный объект. Но это оправдано, как и в случае с jQuery, нету лишних сущностей.
Фреймворки привносят очень много своих сущностей в разработку.

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

Знаете, у вас в вашем блоге (в разделе IT) много чего занятного, не только по теме данной статьи. Там можно долго обсуждать и комментировать многие темы:


  • Почему я не использую тесты кода
  • Методологии разработки говно
  • ООП говно
  • Почему я не использую Twitter Bootstrap

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


  • бОльшая часть негатива адресована Yii. Видимо, потому что там наибольший опыт. Но Yii (особенно 1) — не самый лучший пример фреймворка, да простят меня разработчики, которые используют его.
  • вы часто делаете выводы из частного на общее. Например, пример плохого кода из приложения, которое написано с помощью какого-то фреймворка — не сам код фреймворка, а именно приложения! — для вас является показателем качества первого (фреймворка)

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


вот немногое


  • методологию
  • тестирование
  • метрики кода
  • знание инструментов
  • возможности языка
  • алгоритмы
  • и т.д.

Если по каким-то пунктах вы уходите так сказать в сторону и у вас появилось раздражение или плохие результаты (невозможность применять инструмент как хочется я также отношу к плохим результатам), это не значит что что-то из этого говно. Это значит, что где-то в применении подхода появился изъян. Важно, что тут речь о практике, а не о теории. И не надо всё месить в кучу. Надо "отдебажить" подход и посмотреть что из набора у вас работает не так как вы хотели и почему.


Может вам ЯП надо поменять или какой-то инструмент. Но в любом случае это напрямую зависит от задачи, которую вы решаете в данный момент. Инструменты разные же для разных целей. Если вам для склеивания фарворовой кружки не полошел молоток или скальпель — это необязательно потому что они — говно. Просто для склеивания надо использовать другое!


А вообще я согласен с мыслью, что фреймворки не надо использовать, но в том смысле, что так или иначе он у вас есть (50 КБ своей гордости), просто надо выбирать лучший, а лучший — это который помогает, а не мешает. В идеале вы его со временем просто не будете замечать.

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

Я часто пишу «статьи» не целенаправленно, а в результате участия в холиварах :)
Статьи постепенно дополняются.

>адресована Yii. Видимо, потому что там наибольший опыт

На всех работах с фреймворками использовался именно он.
А в статьях он потому, что я его использую на работе сейчас

>часто делаете выводы из частного на общее

Иногда это примеры :)

>для вас является показателем качества первого

Ну. например, возможность sql-инъекций — это к фреймворку, ибо говорится, что он от них спасает. :)

>это не значит что что-то из этого говно. Это значит, что где-то в применении подхода появился изъян.

Фреймворки очень сложны и это плата за их универсальность.
Мне такая универсальность не нужна.
А местами не логичны.

>Может вам ЯП надо поменять или какой-то инструмент.

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

>так или иначе он у вас есть

Рад, что поняли :)
НЛО прилетело и опубликовало эту надпись здесь
>MVC это архитектура
Я бы сказал, это здравый смысл.

Жирные модели — это все равно, что у курятника будет 10-метровый фундамент… :)

>Делается наследование от класса
Наследование увеличивает сложность, не универсально.

>Думаю это основная причина вашей неприязни фреймворков.
Да :)

>В случае с Yii ни когда не испытывал проблем с документацией.
Она написана как будто для идиотов. Вот именно в Yii. Для создания хоумпаджей. А иногда просто phpdoc

>А страницы не авторизованных пользователей грузятся 5-1мс. Грамотное использование имеющихся механизмов кеширования.
Закешировать страницу целиком — это не совсем грамотно. Да и в 1-5мс я не верю как-то :)

>Nginx прекрасно с этим справляется.
Ну да, нгинкс веб-сервер :)

>Статичная страница на Yii создается 10 строчками кода.
А хедер/футер у такой странички будет?

>По вашему ORM не нужен?
1. Я писал не об ОРМ, а о конструкторах запросов, вроде andWhere/orWhere
2. Но да, я против ОРМ, это лишняя абстракция.

>В роутинге прописывается все достаточно легко. Дальше зависит от ваших рук и головы.
Удалил этот пункт :)

>Точно так же нужные фичи реализуются во фреймворке
Во фреймворках желательно же реализовывать фичи на АПИ самого фреймворка. А часто это усложнено, так как АПИ не предусматривает такого.

>По сути CMS, они есть, см. github.
Интерфес добавления пунктов меню должен быть одинаков.
Каждая CMS на разном фреймворке скорее всего реализует это по своему.

>Виджеты есть.
Я имел в виду программный интерфейс.

>Между 5 и 7й версией PHP тоже не идеальная совместимость.
У меня было только 2 проблемы с 5.2 на 7:
удаленные функции split и mysql_

>Например внутри Yii 1.x с совместимостью все хорошо.
А хотелось бы и 2 с 1. :)
Как в Битриксе.
Да, это сложно.

>Yii::app()->clientScript->registerCssFile(Yii::app()->request->baseUrl. '/css/style.css?'.md5_file(Yii::app()->basePath.'/../css/style.css'));
У меня на работе аутсорсеры, от которых достался код, просто прописали
/>

md5 файла тяжелая ф-я, лучше filemtime()…

>Безопасность и гибкость.
Откуда безопасность?
А гибкость зачастую не нужна.
Понятней обычные массивы GPCS.
MVC это архитектура

Model2 это архитектура (то что используется в Yii по сути), MVC это прием для уменьшения связанности приложения и GUI. Причем не используется активно уже лет 20 и является самой бесполезной аббривиатурой так как люди вкладывают туда самый разный смысл.


Symfony же (что бы вернуться к текущему посту) это request/response фреймворк и его хоть и можно подогнать под Model2 но нет смысла.


Делается наследование от класса, где реализуете алгоритм нужных вам настроек.

композиция лучше наследования, но ладно


По вашему ORM не нужен?

справедливости ради — далеко не всегда он нужен.


Например внутри Yii 1.x с совместимостью все хорошо.

у симфони еще лучше)

Тут похоже опечатка, рендерится некорректно

<form action="{{ path('BloggerBlogBundle_contact') }}" method="post" {{ form_start(form, { 'attr': {'class': 'blogger'} }) }}


Нужно просто

{{ form_start(form, { 'action': path('BloggerBlogBundle_contact'), 'method': 'POST', 'attr': {'class': 'blogger'} }) }}

method у форм по умолчанию POST и поэтому его явно указывать не нужно.


Ну и обработку формы можно оптимизировать


$form = $this
    ->createForm(EnquiryType::class, $enquiry)
    ->handleRequest($request);

if ($form->isValid()) {
    // отправка письма
}

Нет необходимости проверять запрос на POST, это сделает автоматически компонент форм

по оформлению форм в шаблоне, правильней всего так:


{{ form_start(form, {action: path('BloggerBlogBundle_contact'), attr: {class: 'blogger'}}) }}
{{ form_widget(form) }}
<button type="submit">Submit</button>
{{ form_end(form) }}
Несколько замечаний:
  • Symfony best practices рекомендует использовать аннотации для описания роутов.
  • Валидаторы сущности лучше тоже делать через аннотации. По крайней мере это наглядней.
  • Хоть это и не описано в best practices, но если вы протестируете свой проект в SensioLabsInsight, то выясните что все формы должны находится в директории src/Blogger/BlogBundle/Form/Type/.
  • Параметры приложения принято описывать в файле parameters.yml, а не config.yml.
  • Конфиги бандла принято подглючать через DI extension, а не через app/config/config.yml.

Symfony2 автозагрузчик будет искать необходимые файлы в директории src


В Symfony нет автозагрузчика. Symfony использует для автозагрузки Composer.
Он использует расширение .txt.twig. Первой частью расширения, .txt определяется формат файла для генерации. Общие форматы включают, .txt, .html, .css, .js, XML и .json. В последней части расширения определяет, какой движок шаблона использовать, в данном случае Twig. Расширение .php использовало бы PHP для отображения шаблона.


Расширение .html.twig это только рекомендации к наименованию расширения. Расширение файлов ни как не влияет на работу шаблонизаторов. Можно указать любое расширение, хоть .foo.bar.

Вместо
$this->container->getParameter('blogger_blog.emails.contact_email')


можно использовать getParameter
$this->getParameter('blogger_blog.emails.contact_email')


Вместо
$this->get('session')->getFlashBag()->add('blogger-notice', 'Your contact enquiry was successfully sent. Thank you!');


можно использовать addFlash
$this->addFlash('blogger-notice', 'Your contact enquiry was successfully sent. Thank you!');


Несколько мелких замечаний по оформлению:
  • В сущностях рекомендуется описывать реальные типы, а не писать везде mixed.
  • В сущностях рекомендуется указывать значение по умолчанию. Например email всегда должен быть строкой и не когда не должен становится null-ом.
  • В setter-ах рекомендуется возвращать ссылку на текущий объект $this чтобы можно было использовать цепочки вызовов.
  • В классе формы рекомендуется использовать цепочку вызовов для конфигурирования формы.
  • В форме метод configureOptions не обязательный и если он пустой, то лучше его вообще не указывать.


PS: В целом статья хорошая. Спасибо за проделанную работу. Хотя лучше писать качественный код чтобы новички не перенимали плохое.
PSS: Не сочтите за рекламу. Несколько полезных сервисов для тестирования проекта:

и еще. В PHPStorm с установленным плагином Symfony можно указать в начале шаблона комментарий


{# @controller BloggerBlogBundle:Page:contact #}

и тогда в шаблоне автокомплит будет видеть все параметры передаваемые контроллером и по щелчку Ctrl+Mouse Left Click мы перейдем в контроллер, а при аналогичном щелчке по ссылке на шаблон перейдем в сам шаблон


return $this->render('BloggerBlogBundle:Page:contact.html.twig', array(
    'form' => $form->createView()
));
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.