Логика в том, что если нет продукта, то добавляется поле новое. Это бизнес логика.

это после приёма данных формы проверяется, сама форма может быть вообще любой, хоть с плейсхолдерами

создаваться может разная форма же, это никак не связано с действиями, которые по её отправке выполняются

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

форма данные генерирует, не принимает

Принимает, валидирует и сохраняет

на чьей стороне валидирует, куда сохраняет?

если нужно добавить клиентскую валидацию - что происходит?

Читай документацию

мне пример в документации кажется диким смешением слоёв

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

Смешение чего с чем? Форма динамическая, как ты непосредственно требования укажешь?

формируешь конфигурацию, что в результате нужны поля a,b,c,d таких-то типов, а как с этим будет работать фронтенд - его личное дело

Ну вот, форма и формирует это

там еще слой интерфейса примешивается, как ни крути, плюс сам термин "форма" намекает

первый форич не нужен

Как он примешивается? Что намекает?

Хотя, первую часть, можно было бы и оставить, наверное

не поленился сходить в исходники, вот же с view слоем интеграция

Ну она по любому будет интеграция, как иначе )

Еще вопрос, если добавить @ORM\UniqueEntity(fields={"webinar", "user"}), то при добавлении сущности по уже существующему совпадению вебинар-юзер, будет ошибка или просто её проигнорит? Или ->contains метод сам не пропустит такое?

не будет, если это реально генерация требований к данным на выходе

А откуда тогда html возьмется?

spa приложение нарисует, мобильное приложение или что либо еще на фронтенде

А где оно данные будет брать?

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

запросит нужные сущности отдельным запросом, вытащит из кеша, слетает за ними на луну

а на бекенд данные придут в том виде, который он указал в требованиях

А если требования динамические?

фронтенд тоже не из дерева сделан, приняли json с описанием того что нужно - сгенерировали интерфейс с учетом требований, текущей страницы и фазы луны

Короче, завязывай клей нюхать

ок, расскажи тогда, как будешь интегрировать такие формы со spa на react/мобильным приложением

и что будешь делать, приложение с нуля писать, если потребуется полноценный фронтенд, но с динамическими формами?

а то что было - выкинешь или будешь переписывать?

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

Бизнес код останется тот же. Переписать нужно будет взаимодействие с фронтендом

ну вот судя по тому, что ты в точности не уверен, как поступить при замене фронта - это не так

Судя по тому, что ты несешь ерунду, ты гонишь

ну вот судя по тому, что ты в точности не уверен, как поступить при замене фронта - это не так