Ну в любом случае проще сделать так, что бы у каждого фото было 3 точки со скрытыми ивентами (удалить, открыть оригинал, сделать фотом альбома) Ну и всё, пользак нажал на «сделать фотом альбома» и внутри этого экшона присвоил айдишник

Это тривиальная проблема. Не вижу сложности

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

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

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

А FormBuilder как с ним взаимодействует? Я пока не видел. Типа, вот так же, только одно поле приходит и оно же записывается? $form = $this->createForm(AlbumFormType::class, $album); $form->handleRequest($request);

Всем привет! Не очень понимаю, как реализовать следующую логику (или так делать вообще не стоит?). Есть сущность Album. У данной сущности есть свойство thumbnail, представляющее собой ManyToOne с сущностью Photo. Есть форма редактирования альбома. В ней есть поле "Обложка", где отображается ссылка на текущую обложку в виде URI (например https://localhost:3000/photo/Fotografiya-1). Чтобы изменить обложку, нужно, соответственно, просто открыть нужную фотографию, скопировать ссылку и вставить в это поле. Собственно, что мне непонятно. Как правильно обработать юзер-инпут в этом поле? Сперва в buildForm сделал getter и setter для этого поля. В сеттере проверял, что юзер-инпут - это ссылка, парсил её, и пытался найти соответствующее фото. Если репозиторий возвращал не null (фото существует), то всё ок - сущность Photo сохраняю в поле thumbnail. Если нет, то ничего не делаю. Но это как-то криво, нужна же валидация, чтобы пользователь понимал, в чём дело? Ок, сделал валидатор IsPhotoUri. Но затупил и не подумал о том, что значение-то валидируется после того, как маппится в сущность. Получается, нужно дважды валидировать сперва в сеттере, затем в валидаторе? Короче что-то не могу найти конец, за который потянуть, чтобы эту ситуацию распутать. Подскажите, пожалуйста.

Хз, как-то так #[Route(path: '/api/album/{id}', methods: ['PATCH'])] public function update(Request $request, Album $album): Response { $dto = new UpdateAlbumDTO(); $form = $this->createForm(AlbumType::class, $dto); $form->handleRequest($request); if (!$form->isSubmitted() || !$form->isValid()) { return $this->render('album/index.html.twig', [ 'form' => $form, ]); } $updateResult = $album->updateAlbumSettings($dto); return $this->render('album/update.html.twig', [ 'form' => $form, 'errors' => $updateResult->errors(), ]); }

Куда передать?

Вернее, как юзер его передаст?

Найми джсера на фрилансе, он тебе за банку пива сделает

Просто выберет фото, кликом.

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

ты давно видел просто админку?)

Сонату видел

ну там тоже, если тебе нужно что-то чуть более сложное чем стандартный курд - уже танцы

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

Сама симфа не важна, просто инструмент. В основном любые реальные задачи это 2 вещи: 1) укладывание бизнес задач в виде кода, алгоритма 2) решение пазла в виде встраивания нового кода в существующий код. То что касается фреймворков то: Научись быстро и чисто разделять логику между контроллером, сервисом, сущностью и репозиторием - вот 4 основных класса которые ты будешь постоянно трогать. Научись составлять запросы сначала чистые, потом через qb. Потестируй свой код через phpunit (постестируй как и юнит/интеграционными, так и функциональными тестами)

Сама симфа не важна, просто инструмент. В основном любые реальные задачи это 2 вещи: 1) укладывание бизнес задач в виде кода, алгоритма 2) решение пазла в виде встраивания нового кода в существующий код. То что касается фреймворков то: Научись быстро и чисто разделять логику между контроллером, сервисом, сущностью и репозиторием - вот 4 основных класса которые ты будешь постоянно трогать. Научись составлять запросы сначала чистые, потом через qb. Потестируй свой код через phpunit (постестируй как и юнит/интеграционными, так и функциональными тестами)

Ну "худшее" - вопрос, на них и соната, и изиадмин. Просто они довольно не тривиальны и чтобы их использовать прям мощно, надо в них ковыряться. Всякие кастомные js прикручивать, темы. Но это не новичковая тема.

попробуй на тестовом проекте потрогать валидаторы, сериализаторы, ивенты и symfony messenger. валидаторы - хз, я их не использую но могут быть полезны сериализаторы - все воротят от них нос, но они по всюду ивенты - тоже повсюду symfony messenger - тоже повсюду, особенно когда начинаешь в обработку на заднем фоне и увеличение надёжности, производительности Но так, чисто потрогай. Их потом будет много, но пока выштуди основной стержень в виде: 1) контроллеры и роуты 2) сущности и репозитории 3) сервисы и di контейнер 4) как работает конфигурация, что за compile time у симфы

спасибо. Раньше прост с wordpress работал, и тут небо и земля, конечно. Как будто ничего не знаю и учусь всему заново

Ну чисто субъективно, худшее с чем я работал, эти админки тоже не огонь

пока работал с первыми двумя, ВРОДЕ знаю, что это. 3 и 4 вообще не знаю, валидаторы, сериализаторы, ивенты и symfony messenger это тоже. Это база для любой mvc или чисто симфа?

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

пока работал с первыми двумя, ВРОДЕ знаю, что это. 3 и 4 вообще не знаю, валидаторы, сериализаторы, ивенты и symfony messenger это тоже. Это база для любой mvc или чисто симфа?

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

попробуй на тестовом проекте потрогать валидаторы, сериализаторы, ивенты и symfony messenger. валидаторы - хз, я их не использую но могут быть полезны сериализаторы - все воротят от них нос, но они по всюду ивенты - тоже повсюду symfony messenger - тоже повсюду, особенно когда начинаешь в обработку на заднем фоне и увеличение надёжности, производительности Но так, чисто потрогай. Их потом будет много, но пока выштуди основной стержень в виде: 1) контроллеры и роуты 2) сущности и репозитории 3) сервисы и di контейнер 4) как работает конфигурация, что за compile time у симфы

Несколько абстрактынй вопрос задам. По поводу стержня: какой уровень необходим для работы в нормальном проекте в качестве джуна? Суметь сделать какой-нибудь сайт клуба владельцев африканских ежей будет достаточно? Или нужно прям понимать, как это всё внутри работает?

Несколько абстрактынй вопрос задам. По поводу стержня: какой уровень необходим для работы в нормальном проекте в качестве джуна? Суметь сделать какой-нибудь сайт клуба владельцев африканских ежей будет достаточно? Или нужно прям понимать, как это всё внутри работает?

Если вы хотите всё делать один, то определённый бекграунд конечно же ЖЕЛАТЕЛЬНО иметь. Вцелом нужно иметь какое-то подобие чувства кода, уметь проектировать вещи и понимать как работать с бд. Всё, можете хоть всё в контроллере писать на чистом sql. Дальше соответственно развиваться Если вы будете в команде, то просто нужно остроумие

Понимание общих принципов есть (по традиции и свой фреймворк делал, как и все)), опыт работы с очередями (симфони мессенджер, насколько я понял, это они и есть?). Но сейчас ковыряю Симфони и объем такой, что, как и товарищ выше, не понимаю, где та граница, когда можно на что-то рассчитывать.

Но судя по твоим словам, можно уже пытаться в собесы) Спасибо за пост выше!

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

Несколько абстрактынй вопрос задам. По поводу стержня: какой уровень необходим для работы в нормальном проекте в качестве джуна? Суметь сделать какой-нибудь сайт клуба владельцев африканских ежей будет достаточно? Или нужно прям понимать, как это всё внутри работает?

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

А разве бандлы это про модульность?

Сейчас бандлы это про пакеты. В допотопные времена бандлы это реально было про модули Сейчас чтобы сделать независимый модуль гораздо овладеть искусством инверсии зависимости и в целом всё.