Ну если многа параметров как он написал видимо много придется мапить там

А в чем проблема передать риквест в репозиторий?

Думал об этом. Чёт не нравится то что репозиторий будет напрямую с http реквестом работать.

лучше сделать какой нить объект Filter че то типа $repo->find(Filter::create($request));

А что этот Filter::create() будет возвращать? Массив?

Работай с параметр багом

Если понадобится в другом месте, сделаешь параметр баг вручную

Ну или фильтр как сказали. С ним удобнее будет потому что типизированные свойства

А что этот Filter::create() будет возвращать? Массив?

Нет это статический метод который вернет фильтр

Filter::createFromRequest($request)

Фабричный метод

Репозиторий из фильтра должен создать SQL запрос?

Он должен использовать фильтр и квери билдер

А что он вернет я не знаю что тебе надо

А если создать простую DTO чтобы мапить ГЕТ параметры и поля сущности? Что то вроде такого. $company_query = new CompanyQuery(); $company_query->whereStatus = true; $company_query->whereNameLike = $input->name; $company_query->page = $input->page; $company_query->sort = $input->sort; $company_query->order = $input->order; $companies = $repository->findByQuery($company_query);

А что такое инпут

парам баг отвалидированный и нормализованный

Я не все прочитал, но на своем проекте создал фильтр через chain of responsibility, если нет фильтра то отдает всё

А на вход можно передавать гет массивом фильтр

Я не все прочитал, но на своем проекте создал фильтр через chain of responsibility, если нет фильтра то отдает всё

Заморочка что много классов но это же хорошо

Я вообще на каждую букву создаю класс

И класс строки содержит класс на каждую букву

)

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

А кто их юзает?

А кто их юзает?

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

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

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

Ну и форму можно рассматривать как слой ДТО который мапит данные в модель

Там же можно какую-то логику прописать и т.д.

Ну и форму можно рассматривать как слой ДТО который мапит данные в модель

А как можно валидировать и собирать ошибки без форм?

Да спокойно

Валидатором

Формы все равно делегируют валидатору

Сложность без формы с рилейшенами

Формы автоматически это дело обрабатывают

Спасибо)

А кто их юзает?

Ну я использовал, и нормально) по моему удобно. Пробовал делать что то типа как в ларе, через аргумент резолвер с валидацией. Но как ты заметил, со связями не все так просто будет, но тоже не проблема) а вообще ща пытаюсь вникать в bloc и mobx😂 но это уже другая история..

Подскажите пожалуйста, как правильно валидировать в sf5 в роуте сырые гет параметры? Нп. GET /api/endpoint?param=value /** * @Route("/api/endpoint", methods={"GET"}, requirements={"param":"true|false"}) */ Аннотация не проверяет requirements, если параметр не участвует в определении урла. Вручную валидатором проверять?

Обязательные параметры гет, это что то странное... Нельзя так. Может просто значения по умолчанию?

Обязательные параметры гет, это что то странное... Нельзя так. Может просто значения по умолчанию?

согласна, более логично, спасибо)

Добрый вечер) Есть вопрос в продолжение вопроса https://t.me/symfony_ru/32085 Если опциональный параметр в урле является одним из фильтров полей сущности, то правильно ли валидировать этот фильтр используя argument resolver и DTO?

Делаете ДТО с аннотациями

Сериалайзером мапите данные

Вадидатором валидируете

Делаете ДТО с аннотациями

у меня просто внутреннее противоречие, что зачем мне ДТО, сериалайзер и маппинг на чтение, а не на запись (т.е. когда ты планируешь записывать данные, то такой подход понятен, а когда не пишешь, а только валидируешь и идешь дальше делать выборки, то неочень)

Задача отвалидировать запрос я так понимаю

Какая разница выборка там или чтение

Ну можно упороться немного и сделать свой риквест листенер, свою аннотацию, и смотреть в листенере контроллер какой, получать аннотации и валидировать

Но лучше мне кажется дто

Ну можно упороться немного и сделать свой риквест листенер, свою аннотацию, и смотреть в листенере контроллер какой, получать аннотации и валидировать

нет, это ту мач) дто и резолвер кажутся понятнее

Группами валидации можно разделить что именно валидируется

Плюс дто можно наследовать

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

у меня просто внутреннее противоречие, что зачем мне ДТО, сериалайзер и маппинг на чтение, а не на запись (т.е. когда ты планируешь записывать данные, то такой подход понятен, а когда не пишешь, а только валидируешь и идешь дальше делать выборки, то неочень)

Валидируешь ты запрос. Пользовательский ввод.

нет, это ту мач) дто и резолвер кажутся понятнее

Это два часа работы.

Группами валидации можно разделить что именно валидируется

Группы валидации - злое зло.

потому что проще сделать для разных роутов сделать разные ДТОшки чем придумывать универсальный который умеет всё

Вопрос, а кто-то валидирует фильтры?

Тоже хотел бы узнать)

Парни, привет. Подскажите пожалуйста. Репа бандла приказала долго жить. Я всю папку скопировал в src. пытаюсь использовать бандл, получаю ошибку не "не могу подгрузить класс из неймспейса"

копировал всю папку "vendorname/bundleName"

Вопрос, а кто-то валидирует фильтры?

Зачем? )

Добрый вечер) Есть вопрос в продолжение вопроса https://t.me/symfony_ru/32085 Если опциональный параметр в урле является одним из фильтров полей сущности, то правильно ли валидировать этот фильтр используя argument resolver и DTO?

Зачем ты валидируешь фильтр?

Парни, привет. Подскажите пожалуйста. Репа бандла приказала долго жить. Я всю папку скопировал в src. пытаюсь использовать бандл, получаю ошибку не "не могу подгрузить класс из неймспейса"

config/bundles.php

https://symfony.com/doc/4.4/bundles/best_practices.html

Зачем ты валидируешь фильтр?

А как иначе вернуть юзеру ошибку, что он невалидные данные в фильтр передает?

А как иначе вернуть юзеру ошибку, что он невалидные данные в фильтр передает?

А как он может невалидные данные ввести?

Необычный фильтр какой то?

А как он может невалидные данные ввести?

В рест апи он может написать /endpoint?filter=whatever, когда обращается к серверу, и надо это контролировать

В рест апи он может написать /endpoint?filter=whatever, когда обращается к серверу, и надо это контролировать

Юзер через инпуты все вводит же

а по апи что ли только юзеры работают?

Юзер через инпуты все вводит же

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

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

Ну они же по доке будут все делать

Ну они же по доке будут все делать

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

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

Валидировать формат даты? Зачем, если он и так отвалидируется при преобразовании.

Ну кропные конторы валидируют фильра

К примеру если сделать запрос с билибердой то в ответ прийдет именно ошибка валидации фильтра

Типо значение фильтра неаалидно

О каком тут ДДД говорить, если люди задаются вопросом зачем пользовательский ввод валидировать 😅

😆

Можно говорить только о ДДТ