Symfony Слияние форм, созданных динамически (т.е. без ... extends AbstractType)

[Никита_Харьков]

Доброго времени суток честному народу программистов! Жду совета, товарищи, ибо уже достало читать всё мыслимое и немыслимое... Может, конечно, я как всегда невнимателен, но...

Итак:
Есть форма, созданная createFormBuilder:

$checkForm = $this->createFormBuilder()
->add('someField', ChoiceType::class, [//someOptions])
...(много add)
->getForm();
$filterForm = $this->createFormBuilder()
->add('someField', ChoiceType::class, [//someOptions])
...(много add)
->getForm();

Вопрос: как их слить в одну форму?

Я много копал и во всех случаях показывают только возможность с помощью someEntityType или просто какой-то TYPE, т.е. всё равно меня каждый раз заставляют использовать этот Type. У меня же фильтры и чекбоксы будут для каждой страницы (а у меня достаточно много) делаться разными и я не хочу выносить это каждый раз в класс, унаследованный от AbstractType.
Я пытался сделать с помощью CreateForm, но всё равно неудача. Всё время одна и та же ошибка:

Expected argument of type "string, integer or Symfony\Component\Form\FormBuilderInterface", "Symfony\Component\Form\Form" given

т.е. когда я пытаюсь передать вместо someType готовую форму, он всё время ругается. Подскажите, может кто что знает...

 

[keltanas]

Потому что готовые формы не надо объединять.
Формы стоит делать в виде классов (как раз и будут нужные *Type)
При билдинге вместо типа поля можноуказать тип формы (если она сделана отдельным классом) и это будет работать.
И самое главное - не надо пользоваться формами.

 

[WMix]

function addCheckForm(FormBuilder $fb){
  $fb->add('someField', ChoiceType::class, [//someOptions])
  ...(много add);
  return $fb;
}

function addFilterForm(FormBuilder $fb){
  $fb->add('someField', ChoiceType::class, [//someOptions])
  ...(много add);
  return $fb;
}

$fb = $this->createFormBuilder();
addCheckForm($fb);
addFilterForm($fb);
$fb->getForm();

 

[Никита_Харьков]

Вариант @WMix меня не устраивает по причине того, что мне надо отрисовать форму по отдельности. Но интересный вариант, приму к сведению.

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

При билдинге вместо типа поля можноуказать тип формы (если она сделана отдельным классом) и это будет работать.

Можно привести пример того, о чём ты говоришь?

И самое главное - не надо пользоваться формами

Ну и конечно не могу не спросить, что ты имеешь ввиду

 

[keltanas]

@Никита_Харьков, вот тут есть пример http://symfony.com/doc/current/cookbook/form/form_collections.html

Но...

Я имею ввиду, что удобнее и быстрее форму верстать вручную, не полагаясь на модуль форм симфони. Да и вообще рендерить форму на фронтенде.
На бекенде подготовить rest-ообразные маршруты для CRUD.
Потом эту форму на js сериализовать в json и отправить на rest-api соответствующим методом.
Backboneами и Angularами это делается не сложно.

Правила валидации, прописанные в сущностях проверяются валидатором (без форм: $errors =$this->get('validator')->validate())

 

[Никита_Харьков]

вот тут есть пример http://symfony.com/doc/current/cookbook/form/form_collections.html

В этом примере я должен передать экземпляр интерфейса FormTypeInterface, а у меня передаётся объект formBuilderInterface, поэтому этот пример не подходит. Может я чего не понимаю, тогда напиши какой-нибудь простой пример.

А на счёт валидации с помощью сущностей - для меня откровение! Это очень хорошая идея. Но только вот как быть в моём случае, когда у меня нет такой сущности, которая с чекбоксами вся, т.е. для выбора полей? Создать её?.. Или как?

Я даже по-другому спрошу: как бы ты решил данную задачу? Как твоё видение? Ибо ты всё-таки более продвинутый, так или иначе

P.S.: ничего что я на ты? Я просто всегда думаю, что так проще...

 

[keltanas]

@Никита_Харьков, вот тут в буке пример, как правила прописываются на поля сущности и потом валидируются.
В твоем случае это не нужно, т.к. поля никуда не сохраняются (только если ты не будешь вести логирование всех запросов на отчет).

у меня передаётся объект formBuilderInterface

Наверное, надо изменить код так, чтобы передавался FormTypeInterface
Описывать формы в контроллере - плохая затея. Как я уже и писал, создавай на каждую форму отдельный *Type класс. Далее, можно создать другую форму, в которую вместо полей можно указывать другие формы, и так сколько хочешь (формы и поля форм реализуют один и тот же интерфейс). Я формы уже давно не использовал, лень вспоминать все нюансы. Главное, что я помню, получается тормозной монстр от которого хочется ругаться матом. Так что не хочу помогать стрелять себе в ногу.

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

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

Есть статья по этому поводу, но не советую этим заниматься, крайне не советую. Сам мучился с этим пару лет назад. Проблем много и профит получается не оправдан.

 

[Вурдалак]

На бекенде подготовить rest-ообразные маршруты для CRUD.
...
Правила валидации, прописанные в сущностях проверяются валидатором (без форм: $errors =$this->get('validator')->validate())

Как альтернатива, можно использовать JSON RPC и валидировать команды.