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

[@zim32]

Мне показалось что вот с формами они перегнули немного. Сложновато как-то въехать даже после многочасового изучения кода

[@Fesor]

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

[@chEbba]

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

[@Fesor]

А она разве смешана?

[@chEbba]

Да, например, с точки зрения данных choice, radio, checkbox, etc — это все одно и тоже, это коллекция/массив значений. И типы различают лишь внешнее представление. Тоже самое со всеми текстовыми полями.

[@Fesor]

Но логика мэппинга данных и отображения же не связана. Во View лишь передаются опции, а то как отображать решает уже слой View. Либо я вас не понял.

[@chEbba]

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

[@chEbba]

И я еще не говорю про лейблы, html атрибуты и т.п.

[@Fesor]

Эм… напишите 'choice' как тип формы и на основе того, что хранится у вас в поле, вам выдадут нужное представление. Лабелы генерятся из названия поля, HTML атрибуты так же. При желании можно просто бахнуть свой шаблон с виджетами или перегрузить только часть из них. Как по мне довольно гибко и мало возни. Вот в Yii с этим грустно.

[@soloweb]

Как пример посмотрите формы во фреймворке onPHP (https://github.com/onPHP/onphp-framework)

тут (https://github.com/onPHP/onphp-framework/wiki/Ru%3Aformarticle)
и тут (https://github.com/onPHP/onphp-framework/wiki/Ru%3AForm)

[@Fesor]

Ну идея похожа, но в более примитивном исполнении. Тоже есть примитивные типы (email, пароль и т.д.), есть что-то вроде FormBuilder-а. В чем различие то? то что там названо примитивами — в Symfony Forms назвали FormType. Чисто идеологически все достаточно похоже. Если вы о том что явной связи с представлением нету, то тут да. Хотя по сути вы и в Symfony примерно так же. Может я что проглядел?

А вообще занятная реализация. Спасибо. Неплохой микрофреймворк.

[@Agatov]

Я сильно извиняюсь за оффтоп и разжигание межплатформенной розни, но вот почему при работе с Rails я даже никогда не задумывался о том, как там работают формы? Они просто работают и всё.

В symfony 1.x формы тоже не подарок были, но тут что-то они совсем нагородили.

[@Fesor]

По сути при работе с формами в Symfony2 вам тоже особо париться «как оно работает» не нужно. Тут просто приводятся доводы аля «зачем делать что-то еще? может одно что-нибудь доделаем вместе?».

На самом деле сложно только первое время. Мне вот после полугода активного использования формочек они дико нравятся. Проще покрывать тестами, повышается уровень абстракции, много клевых плюшек. Допустим, эллемент формы генерит JSON массив (какой-нибудь навороченный редактор чего-нибудь) и датаконвертер (через JMSSerializeBundle к примеру) делает из этого JSON объекта готовый к использованию внутри приложения объект (коллекцию объектов, какое-то дерево или мало ли что еще). Поработав немного на реальных проектах, я лично считаю что формы были реализованы довольно неплохо. И смею заметить, что это еще далеко не финал. Как и говорится в статье — что-то близкое к финальной версии появится только в Symfony 2.2.

Возможно это просто дело вкуса, но я вспоминаю как сам поначалу плевался. Сейчас же ничего проще (покрайнемере в PHP) я найти не могу.

[@ashofthedream]

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

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

[@organium]

В Rails формы, как отдельного объекта, нет и все, что должно быть в форме, находится в модели. Это и плюс и минус. Очень просто нарисовать, но сложнее менять и расширять. Симфони, насколько я понял, претендует на звание Enterprise Framework, со всем вытекающим отсюда ООП головного мозга. Так что сравнивать не очень корректно.

[@psylosss]

На мой взгляд, авторы симфони2 перехитрили сами себя. Все настолько абстрактно, независимо, подключаемо, заменяемо, что цельный фреймворк (которым я считаю, например, симфони1), рассыпался в горсть болтов, гаек, гаечных ключей и проволоки.

[@Fesor]

Так в этом же и суть, вы можете запросто использовать в своем проекте какие-то части фреймворка, или заменить какой-то слой этих гаек на свой.

[@ashofthedream]

Если людям приходиться при работе с фреймворком заменять какие-то его части… то это какой-то хреновый фреймворк

[@Fesor]

Под заменой я подразумевал расширение функционала, а не замена реализации.

[@ashofthedream]

Я сейчас не могу найти ни одного случая, когда бы мне пришлось бы расширять возможности фреймворка, без осознания того, что такой фреймворк мне уже не нужен. Когда после пары недель с момента «ну сейчас, тут допилим… и вот тут» — фреймворк выкидывался и брался другой — знаю с десяток. Два из которых ну просто клинические, к сожалению, в одном из них я был ключевой фигурой (увы, на тот момент я не мог повлиять на ситуацию): и напихав десяток кослытей все таки смог соединить две вещи, реализаця которых бы, даже самописная была гораздо быстрее и проще.

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

[@ashofthedream]

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

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

[@organium]

Если так, как Вы говорите, то это уже не фреймворк, а просто набор классов. Библиотека.

[@Fesor]

Symfony2 Forms, Doctrine2, Propel, Twig, Symfony2 Routing и много чего еще — это отдельные компоненты. Symfony2 Framework лишь объединяет их, содержит в себе какие-то общие вещи (конфигурация, взаимодействие и прочее), готовые типы форм, плюшки. Такой подход лучше, чем мессиво тесно связанных между собой компонентов, которые сложно допилить под себя (допустим этим болеет Yii. Просто — но иногда не удобно, сложнее расширять).

[@organium]

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

[@Fesor]

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

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

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

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

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

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

[@organium]

Что мешает написать виджет для визуальной составляющей и behavior для поля в модели? И то и то можно повторно использовать.

[@Fesor]

То, что расширять это уже будет не удобно.

[@organium]

куда расширять то? Вот данный, конкретный случай.

[@VolCh]

Практически все Известные мне популярные фреймворки можно разделить на две части — собственно фреймворк (каркас, «микрофреймворк») и библиотека. В symfony2 жесткие связи между каркасом приложения и библиотекой сведены к минимуму, каркас по сути лишь ещё одна библиотека, в которой связи со стандартными библиотеками могут быть легко заменены на сторонние или самописные, лишь бы интерфейс совпадал.

[@organium]

Да я понимаю, что вся эта модульность очень крута, но она порождает усложнение архитектуры, причем иногда излишнее. Я сейчас перехожу на rails после зенда и не могу не нарадоваться, что не нужно писать такое огромное количество своих костылей И что все сделано просто и очевидно, а наличие гемов позволяет сократить велосипедостроение до минимума. Так что зависит от целей. Тут как linux VS windows, когда хочется поразбираться, поковыряться, то выбираешь линукс. а когда нужно, чтобы просто работало — windows. И если зенд это уже не первый фреймворк и азарт пропал, то нет никакого желания принимать его выверты архитектуры(хотя я прекрасно понимаю и что, и как, и зачем) и отсутствия самых необходимых вещей.

[@VolCh]

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

[@organium]

А какую нишу занимает(планирует занимать) Symfony? На PHP не годится делать энтерпрайз решения, для этого же есть Java/.NET. Ну а быстро развернуть приложение, благодаря динамической типизации и прочих плюшек скриптовых языков, не получится, потому что все сделано по самым лучшим практикам из джава-ооп мира…

[@ashofthedream]

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

[@organium]

Почему единственный? Как же Yii?

[@ashofthedream]

К сожалению с yii знаком давно и был не лучшего мнения о нем, поэтому даже не смотрел на него, но если вы сейчас кинете сюда кусок кода работы с формами и бд буду благодарен (хотя бы увижу во что он превратился). Собственно к нам прилетает форма, мы ее валидируем и если все хорошо — пишем все поля из нее в базу, если нет — говорим в каком поле ошибка и возвращаем обратно

[@organium]

if(isset($_POST['User'])){
    $model->attributes=$_POST['User'];
    if($model->save()){
         $this->redirect(...);
     }
}

Вот так можно

[@aeryaguzov]

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

[@organium]

Модель содержит в себе правила валидации. Объекта формы нет как такового. Active Record.

[@ashofthedream]

Такой подход имеет право на существование если он реализован как в релсьах. Если так, как написали вы — это ужасно.

[@organium]

Не находите, что в рельсах точно так же? Yii сделан под большим впечатлением от них

[@Fesor]

Только вот Руби и PHP это совершенно разные вещи. Допустим, Post::model()->findAll() — это грустно. Это равносильно $post->findAll(). Мол каждый экземпляр имеет доступ ко всему репозиторию. В руби же все чуть сложнее, посему концепция AR там подходит идеально.

[@organium]

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

[@Fesor]

А вы в курсе что в Yii таки есть FormBuilder? Я тоже в Symfony2 могу нафигачить все в шаблоне и работать напрямую с POST данными, валидацию всеравно можно дергать для модели. Но зачем?

[@organium]

В курсе, только зачем они? Когда в модели можно провести всю валидацию?

[@Fesor]

Затем, что без использования формбилдеров реюз кода становится крайне сомтительным занятием. Реюз контроллеров вообще довольно гнилая тема, а если у вас вся логика по обработке форм там — то это грустно. Формбилдер нужен для того, что бы ваши темплейты небыли забиты вызовами методов у объекта CActiveForm. За вас это билдер сделает. И запрос обработает, и данные по полям в модели разнесет, и валидацию проведет.

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

[@aeryaguzov]

А зачем Вы тогда про формы пишете, если их нету:-)
Обрабатываете Вы запрос, а не форму в данном случае:-)

[@ashofthedream]

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

[@organium]

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

[@Fesor]

В том то и суть что контроллер это не то место, куда надо выносить обработку данных. Конечно же можно сделать через экземпляр CFormModel и там уже поставить нужные поля как unsafe, прогнать через сеттеры прописанные в модели… но это все-равно убогою

[@organium]

Форма чаще всего используется один раз. Какой смысл писать для нее целый класс?

[@Fesor]

Инкапсулировать логику по работе с данной конкретной формой в один конкретный класс, к примеру.

[@organium]

Зачем?

[@aeryaguzov]

Reusable code — не? В честь чего один раз?

У меня 100500 проектов и одна форма авторизации, которая имеет разные представления, разную модель поведения и тд

[@organium]

Мы же про формы говорим? это кусок Html и валидация? Что мешает в модель из рельсов написать has_secure_password? И вью скопировать для отображение. Представление меняем с CSS. Я сомневаюсь, что вам не придется менять форму из Zend_Form, если вы заходите изменить разметку и «модель поведения ». Так что не надо преувеличивать реюз.

[@Fesor]

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

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

Или же одна из этих сильно специфичных форм должна быть включена в родительскую, и динамически добавляться. Ну мол по нажатию на плюсик.

[@organium]

Про partials слышали?
И еще раз, хоть эта логика и вынесена, вряд ли удастся ее использовать в том же самом виде.

[@Fesor]

Ну мне как-то удается, вынося все в FormType и используя DataConverter в Symfony2. Кода выходит, как не странно, но меньше.

[@organium]

Ладно, наверное нет смысла продолжать насчет форм, потому что я работал с Zend_Form и там все довольно печально. Может в Симфони с этим делом лучше.

[@organium]

И еще один момент, допустим у вас три формы использующихся для одной модели. Некоторые поля пересекаются, как вы решите проблему дублирования? Zend_Form.
А если вся валидация в модели, то она и применится только тогда, когда это поле вообще присутствует в форме. И будет применяться всегда.

[@Fesor]

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

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

[@VolCh]

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

[@ashofthedream]

Реальный пример — дата и время, на клиенте поле в котором можно написать 150 или 2:20 или 2:20:34 или это несколько полей: календарь + две крутилки времени. В модели — таймстемп, в реальности надо сказать человеку где он ошибся. Как тут быть?

[@organium]

Выделить всю комбинацию полей отвечающих за дату?

[@ashofthedream]

Как показала практика (да и требования ui дизайнеров) — люди не всегда быстро замечают где ошибка, если допустим мы подсвечиваем три поля, а не именно то в котором ошибка.

[@organium]

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

[@Fesor]

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

[@organium]

Можно же в сообщении об ошибке указать — «Год окончания не может быть позже года начала». Ну или как-нибудь грамотнее =)

[@Fesor]

Нет, вы сути не улавливаете. У вас в форме 2 поля, в модели одно, которое к тому же хранит коллекцию объектов. Валидацию вам придется делать по двум полям, тобиш использовать для этого модель уже не выйдет.

[@organium]

Вам выше написали, что если речь про Yii, то можно сделать свой сеттер, можно написать свой метод валидации и так далее. Да, это все будет в модели, ну и что?
Ну а выделяем уже то самое одно поле из модели.

[@PQR]

Читаю тред, вопрос хороший. Fesor, я так понял вы тут главный спец по Symfony 2, так дайте чёткий ответ: можно ли сделать валидацию по двум полям формы раздельно не смотря на то, что внутри модели это одно поле? Если да, укладывается ли это в архитектуру форм-моделей-валидаций в Symfony 2 или придётся извращаться?

[@organium]

И опять же джава скриптом это можно легко поправить и проверить.

[@Fesor]

Джаваскрипт это хорошо, но без валидации на серверной стороне никак увы.

[@organium]

Да, но сократит критичность сообщения об ошибке уже после отправки формы.

[@ashofthedream]

Вы когда-нибудь работали с большим количеством форм, в котором куча полей. Вот к примеру наши геймдизайнеры работали. И многие поля связанные со времеем у нас были либо в секундах по дефолту, либо в форматах: h m s | m s | s либо в 10w 3h 1d 6s — потому что это быстрее. быстрее написать 600 для 10 минут, быстрее написать 12 01 44 для 12 часов 1 минуты и 44 секунд. быстрее написать +1w для одной недели. нежели выбирать две даты из календаря.

[@organium]

что мешает указать ошибку в сообщении? Допустим у вас три поля отвечают за дату. Если выделить их красным и русским языком написать в чем ошибка, то будет непонятно?

[@ashofthedream]

Будет но как вы в моделе определите в каком поле ошибка, если по сути это все перегоняется в два инта и потом уже сравнивается?

[@organium]

вы же при проверке будете знать в чем ошибка? А значит и сообщение напишете соответственное. Ну а выделите все три =)

[@Fesor]

$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-ы, или же (например для хэширования паролей, загрузки файлов на сервер) используются либо хэндлеры, либо листенеры событий. Можно конечно и в контроллере, но мне лично так делать не нравится.

[@aeryaguzov]

C чего Вы решили, что Zend_Form хуже?

[@ashofthedream]

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

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

[@aeryaguzov]

Я поэтому и спросил, что сам с ними очень долго работал и ничего лучше еще не встречал.

Там есть проблемы с предметной областью, например валидацией и фильтрацией не «там, где надо», потому что форма у них != view для модели, но в остальном компонент шикарен!

Zend_Form с моделями вообще никак не связана, потому что моделей в ZF нету:-)
Ошибки валидаторов переводятся в одном файле с передовом для конкретного языка, подключается к приложению одной строчкой:-)
Вы не поверите, но конфигурация тоже построена на Zend_Config, который умеет понимать все форматы:-)

А доделывать Ваши = кастомные компоненты действительно приходится, потому что они Ваши!
Плюс Zend_Form в том, что делаются они тривиально.

Так Вы с ними правда работали?)

[@ashofthedream]

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

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

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

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

[@aeryaguzov]

$form->populate($model->toArray()) в простейшем случае — 1 строчка

Кастомная логика — you're welcome: $form->fromModel(Model $model) — писать надо будет самому.
Если есть «телепатический» фреймворк, который сам решит, что я хочу, расскажите о нем:-)
В остальных фреймворках, всегда костыли, поверьте пробовал много.

Отлично меняется рендеринг, если использовать паттерн декоратор(Zend_Form_Decorator) — хоть в brainfuck, если нужно: $el->addDecorator('brainfuck');

[@VolCh]

Имхо, Symfony 2 лучше других (правда ZF2 ещё не оценивал) подходит для создания расширяемых пользователем коробочных продуктов класса CMS. Вернее даже серии таких продуктов. Другими словами, Symfony 2 платформа для создания специализированных CMF на PHP, которые как работают из коробки и управляются «мышкой», так и предполагают возможность практически неограниченной кастомизации. Ещё можно сказать, что Symfony 2 лучше других подходит на роль инструмента для создания инструментов для веб-мастеров и веб-студий — продукты на базе Symfony 2 будут (если получится преодолеть консерватизм рынка) конкурировать с традиционными CMS/F типа Wordpress, Drupal, Bitrix.

[@organium]

Вот и получается — фреймворк для создания фреймворков, а не веб-приложений…

[@VolCh]

Подменяете понятия full stack framework и content managment framework. Для создания первых есть Symfony Components, для вторых — Symfony Framework.

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

[@RusMikle]

8й drupal на symfony 2 пишется, с чего им конкурировать?

[@Fesor]

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

[@second_pilot]

Надеюсь он проще в использовании, чем Zend_Form. Последний внушал мне мысли о суциде

[@Fesor]

Ну не уверен что сильно проще, с непривычки все же сложновато, но приятнее как минимум.

[@aeryaguzov]

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

P.S. ЗАЧЕМ переходить на неймспейсы, если все классы по прежнему содержат приставку-неймспейс (почему .../Form/FormErrors, а не .../Form/Errors)?

[@ashofthedream]

Потому что Errors — не самое лучшее название для класса. В нормальных языках работа с неймспейсами прозрачна. В яве вообще пишут com.companyname.productname.someshitname.forms.BlablaForm, но кого волнует в каком пакете это все лежит если нормальная иде номально все импортит

[@organium]

А в для PHP разве есть автоимпорт?
На джаве то понятно. Там хоть и все ООП`шно и сложно, но там IDE за тебя пишет половину кода.

[@ashofthedream]

Если в IDE в которой вы пишите нет автоимпорта… то я бы вам советовал выбрать другую IDE. Скорость написания кода на PHP и так гораздо меньше нежели на другом нормальном языке (из за многих факторов), а если меня еще и самого заставят импорты прописывать…

[@organium]

Просто не писал на PHP на фреймворках с неймспейсами, поэтому не в курсе таких фишек.

[@aeryaguzov]

Если они реально думали, что «давайте назовем классы так, потому что блин хреново импортят IDE и автокомплит у пацанов адский», то я считаю надо было либо ждать пока IDE научатся обрабатывать use, либо оставаться на PEAR Conventions.

Считаю, что в таком переходе на неймспейсы нет никакого смысла.

Вообще видится бредом, ибо всем не нравились длинные имена классов, как в PEAR, а теперь всем не нравятся короткие, потому что слишком все одинаково, не коммьюнити, а хипстеры какие-то:-)

[@nick4fake]

Так IDE работают с use (PHPStorm, например)

[@Fesor]

Да уже пару лет как

[@chEbba]

А чтобы не было 100500 классов с одинаковыми короткими названиями. Короткие имена должны быть информативными. Я искренне проклинаю разработчиков, когда мне на InvalidArgumentException в автокомплите вываливается десяток классов из разных неймспейсов.
Но это очередная тема для холивара…

[@ashofthedream]

Что это за болезнь, для каждого пакета делать свои исключения. Люди, которые так делают, разве ниразу не работали с исключениями что бы понять, что в 97.22% случаев в кэтче будет либо Throwable, либо Exception, еще в 1.93% там будет попытка обработать какое-нибудь не самое приятное исключение, а в остальном — какой-нибудь треш жуниора

[@Fesor]

ну например:

try {
    $service->foo();
}catch(\My\AcmeBundle\Exception\InvalidParameterExteption $e) {
  // обрабатываем ислючение, выкинутое нам каким-то определенным сервисом в ответ на заданные параметры
}
catch(\My\FooBundle\Exception\InvalidParameterExteption $e) {
  // обрабатываем ислючение, выкинутое нам каким-то определенным сервисом в ответ на заданные параметры
}

Это позволяет разграничивать исключения. Я сам как бы не в восторге, и приведенный пример абстрактен и реально я нигде такого не видел.

[@ashofthedream]

Да понятно почему это делается. Но кому это нужно. Кто этоим занимается. Кому такое может придти в голову?

[@VolCh]

Ну, в Form может быть ещё и, например, FieldErrors.

[@Fesor]

Наткнулся на ваш перевод уже тогда, когда оставался один абзац. Жалко было бросать.