Архитектура форм в Symfony2

Она разделена в реализации, но логически оно связано: меня «заставляют» делать выбор как будет отображаться форма в том месте, где мне на это наплевать. Вот именно, что во вью должно решаться отобразить select, radio или checkbox; textarea или input: «я не хочу ничего решать, я хочу string»!

В Yii форм билдер вообще убогое зрелищие, он подходит только для однотипных формочек. Как минимум не хватает контроля за данными, предсказателей типов, все завязано на класс CModel и т.д.

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

Если не брать в расчет реализацию JS (тут в любом случае время константно) а брать только время реализации виджета, классов и прочего… Минут за 30 я сделаю и конвертеры данных, и формтайп, и вьюшку (делал, цифры не из головы).

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

        ...
        ->add('address', 'location')

А теперь предложите мне сносный вариант. что бы не пришлось затрагивать CActiveForm например, или CForm, реализовать это в Yii? Знаю что можно, но выходит не так красиво.

Топик всё-таки про symfony, а не Zend. А я вот пишу PoC-прототипы на rails, а потом реализую их на symfony. Конечно хотелось бы использовать один инструмент и для того, и для другого с одинаковым удобством, но, увы, не получается, а если выбирать что-то одно, то это будет symfony даже по независящим от меня причинам.

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

Это ужасно. Во первых это ужасно потому, что не факт что все что у меня есть в форме у меня есть в модели, к примеру у меня некоторые поля в модели могут быть разделены на 2-3 поля в форме. Да и это не главное, как мне юзеру выдать то, что у него во втором поле ошибка а не просто «форма неправильная, давай заново».

$em = $this->getDoctrine()->getManager();
$form = $this->createForm(new MyFormType(), new Entity());
if ('POST' == $this->getRequest()->getMethod()) {
      if ($form->bind($this->getRequest)->isValid()) {
           $entity = $form->getData();
           $em->persist($entity);
           $em->flush();
           // редиректы, flash сообщение и все что нужно
      }
}

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

Повторяю вопрос: сколько строк кода мне придется написать для того, что бы перекинуть один объект моей модели в объект ZF? 50? 150? 250 для большей модели? В остальных фреймворках порядка 4-5.

Потому что они понимают, что если написано int — то надо хотя бы проверить на то, что это интовое значение, а не «Привет я Вася».

Да это понятно что там Zend_Config везде, так что можно хоть в бинарном формате ему скормить описание (я и такое делал), но по дефолту они везде в описаниях пихают ini. Что собственно распростанило это более чем прекрасный формат для простых конфигов (простых, а не иерархичных!) на множество проектов.

Вы когда-нибудь пробовали изменить рендеринг форм? У нас вот форма должна была рендериться в представление extjs (почему было именно так — долгая история), а вот красивняшка ZF жестко завязана на htmlююю