Почему? Или вы дублируете валидацию на фронт?

да

не дублировать выходит разве что для самых примитивных сценариев когда данные из формы отправляются 1:1 в апишку

да

Ух ... я думал юзаете серверную валидацию

Ух ... я думал юзаете серверную валидацию

это больше для того что бы фронтендер/мобильщик могли глянуть где они нафакапили

им помогает

Тоесть если какая-то валидация поменяется, то надо править всех клиентов ... например минимальное количество букв. Как бе выглядит громоздко для такой правки

Тоесть если какая-то валидация поменяется, то надо править всех клиентов ... например минимальное количество букв. Как бе выглядит громоздко для такой правки

а у тебя это часто бывает?

да и зачем тебе ограничивать минимальное количество букв? типа для пароля?

можем холивар

упрощать написание клиентов

Тоесть если какая-то валидация поменяется, то надо править всех клиентов ... например минимальное количество букв. Как бе выглядит громоздко для такой правки

можно экспоузить на клиент json схему с правилами валидации

но у меня слишком редко формы 1:1 json

или сходить с ума с обратной совместимостью при изменении требований

да и зачем тебе ограничивать минимальное количество букв? типа для пароля?

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

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

не пустая строка, зачем еще какие-то ограничения на имя?

можешь погуглить все эдж кейсы с валидацией имен

Было например 5, а потом пришел китаец у которого фамилия Lee и надо сделать на 3

Было например 5, а потом пришел китаец у которого фамилия Lee и надо сделать на 3

а потом пришел чувак у которого ни фамилии ни отчества и зовут его "ф"

или амар абдул ибан хатабыч

повторюсь - хочешь унификации правил - тебе никто не мешает компилить из правил валидации json схему

а потом пришел чувак у которого ни фамилии ни отчества и зовут его "ф"

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

ок. Вопрос к аудитории - как часто вы терпели, когда публичное апи вам на ваши запросы отвечало "Something went wrong"?

вот просто, вы юзали его долго, с болью написали клиент. А он через месяцок - 422 - Something went wrong

к примеру, air провайдер какой

было бы круто, если бы он вам нормальную мапу, что и где случилось?

повторюсь - хочешь унификации правил - тебе никто не мешает компилить из правил валидации json схему

А в чем профит, от серверной валидации? Ибо с одной стороны мимнимизация запросов на сервер, а с другой надо какйо-то конвеншнс дополнительный принимать с фронт командой, о том для какого ресурса какие правила брать.

было бы круто, если бы он вам нормальную мапу, что и где случилось?

ну вот мой же выдает нормальную мэпу)

А в чем профит, от серверной валидации? Ибо с одной стороны мимнимизация запросов на сервер, а с другой надо какйо-то конвеншнс дополнительный принимать с фронт командой, о том для какого ресурса какие правила брать.

что в чем профит? Зачем надо валидировать данные на сервере?

так это да. Но мы говорим о дублировании на клиенте логики. И о том, что "нечасто меняются требования"

что в чем профит? Зачем надо валидировать данные на сервере?

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

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

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

так это да. Но мы говорим о дублировании на клиенте логики. И о том, что "нечасто меняются требования"

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

это разная логика

она может быть похожей или даже связанной

но не обязана быть дублированием

на клиенте ты валидируешь пользовательский ввод. И пользователь у тебя - реальный человек. НА сервере ты тоже валидируешь пользовательский ввод - и пользователь тут - мобилка или spa

то есть все красиво и просто если данные на всем этом пути имеют одинаковые правила и структуру

но приходит упоротый UX дизайнер и говорит что "главное что бы пользователю было удобно"

что до нарушения обратной совместимости - тебе надо добавить новое обязательное поле - что будешь делать?

зависит от того, какой проект. Докину в схему новое поле

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

или им "flash" сообщениями показывать юзеру придётся

зависит от того, какой проект. Докину в схему новое поле

а как клиент его отрендрит? это выходит надо писать хрень которая под твой UI рендрит форму на основе json схемы

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

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

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

да. Захотят впилить "супер поле от дизайнера", будет маппер посредине. Фича -> схема

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

у нас сервер генерит json с правилами и клиент рендрит форму согласно этим правилам

и это ад и сложно

не хотят париться - будет автоматически всё

у нас сервер генерит json с правилами и клиент рендрит форму согласно этим правилам

А как у вас разделяются правила валидации? Типа на каждый урл, свой набор правил? Ибо по сущностям это плохо.

у нас сервер генерит json с правилами и клиент рендрит форму согласно этим правилам

Мы так нашу oas3-доку парсим и отдаем как правила валидации по запросу OPTIONS

Зависимость есть, фронтендщик жив

Зависимость есть, фронтендщик жив

В таком случае вы всеравно на сервер запрос отсылаете, что б получить правила. Или вы их кешируете?

В таком случае вы всеравно на сервер запрос отсылаете, что б получить правила. Или вы их кешируете?

Перед рендерингом формы клиент посылает OPTIONS-запрос, парсит правила валидации (они в формате JSON Schema, ну вы знаете, да), и проставляет у себя примитивные констрейнты (по длине, по обязательности заполнения, по регекспу и пр.). Этот запрос очень дешево нам выходит, потому мы решили не кэшировать правила валидации ни на бекенде, ни на фронтенде

А как у вас разделяются правила валидации? Типа на каждый урл, свой набор правил? Ибо по сущностям это плохо.

я ж вроде уже писал что валидирую сам запрос и потому логично что правила привязаны к конкретному экшену апишки

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

Перед рендерингом формы клиент посылает OPTIONS-запрос, парсит правила валидации (они в формате JSON Schema, ну вы знаете, да), и проставляет у себя примитивные констрейнты (по длине, по обязательности заполнения, по регекспу и пр.). Этот запрос очень дешево нам выходит, потому мы решили не кэшировать правила валидации ни на бекенде, ни на фронтенде

хм .. экономия от серверной валидации если все данные ввели верно с первого раз никакой. Хотя, идея интересная

хм .. экономия от серверной валидации если все данные ввели верно с первого раз никакой. Хотя, идея интересная

никакой говоришь?

Тоесть в вашем случае, сервер никогда не возвращает ошибки? А если есть сложная валидация?

Тоесть в вашем случае, сервер никогда не возвращает ошибки? А если есть сложная валидация?

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

есть валидация примитивная - типа поле не пустое или ты забыл чего написать, и есть валидация бизнес ограничений в духе "ты не можешь покупать чаще чем раз в 5 минут"

никакой говоришь?

Ну да, в серверной валидации +1 запрос, (если ввели данные не верно с первого раза), что там на options

хм .. экономия от серверной валидации если все данные ввели верно с первого раз никакой. Хотя, идея интересная

У нас просто кейсы были такие, где надо было валидировать данные на лету. Есть формы с тучей полей и поля с ограничением в 65к символов. Согласитесь, не очень удобно, когда вы получаете ошибку после нажатия кнопки "отправить" для больших форм. Или когда заполняете поле на 70к символов, а там можно только 65к.

Ну да, в серверной валидации +1 запрос, (если ввели данные не верно с первого раза), что там на options

с точки зрения пользователя разница есть

есть валидация примитивная - типа поле не пустое или ты забыл чего написать, и есть валидация бизнес ограничений в духе "ты не можешь покупать чаще чем раз в 5 минут"

Я не про бизнес валидацию, я про валидацию введенных данных.

Тоесть в вашем случае, сервер никогда не возвращает ошибки? А если есть сложная валидация?

Бекенд всегда валидирует данные.

ERROR: S client not available

ему не надо ждать дополнительно 200-300ms (или до секунды в херовых сетях) что бы узнать что он накосячил

а вот options запрос он даже не заметит

ему не надо ждать дополнительно 200-300ms (или до секунды в херовых сетях) что бы узнать что он накосячил

Но он те же 200-300 мс будет ждать перед рендером.

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

Но он те же 200-300 мс будет ждать перед рендером.

не обязательно

а вот options запрос он даже не заметит

Почему, OPTIONS обладает магией? )

нет, просто ты можешь отрендрить, отправить options и применить правила валидации

за секунду среднестатистический пользователь успеет только осознать что от него хотят

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

но будет создаваться впечатление что все быстро

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

фрактал мне лично нравился идеея инклудов

композиция респонсов

я сильно его переделал под себя впоследствии

ps. фрактал внутри дикое говнище

)))

у меня инклуды делались подзапросами на экшены контроллеров и потом склеивались + поддержка batch запросов что бы невилировать N+1 проблему

так у меня выходила очень модульная система

@fes0r @terron Хм .. да действительно с схемой круче получается.

)))

собственно по сути - по этой же причине мне нравится graphql и потому я медленно но верно пилю свою реализацию под симфони

Привет всем, подскажите, пожалуйста. Есть сущность, в ней есть /** * @var \DateTime * @Gedmo\Timestampable(on="create") * @ORM\Column(type="datetime") */ private $createdAt; Как я могу сделать что-бы Timestampable срабатывал только если поле пустое? А если с значением - Timestampable игнорировался.

Привет всем, подскажите, пожалуйста. Есть сущность, в ней есть /** * @var \DateTime * @Gedmo\Timestampable(on="create") * @ORM\Column(type="datetime") */ private $createdAt; Как я могу сделать что-бы Timestampable срабатывал только если поле пустое? А если с значением - Timestampable игнорировался.

предлагаю ход конем - убрать это нахер и делать это явно в конструкторе

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

предлагаю ход конем - убрать это нахер и делать это явно в конструкторе

А, стоп, в конструкторе, я сначала прочел в контроллере.

Действительно, добавить одно условие в конструктор будет проще всего.

Спасибо.

что за условие?

Если значение не пустое, не перезаписывать дату

я конечно не синиор

но $this->createdAt = new DateTime(); в конструкторе и без таймстемпабл совсем не вариант?

Да, так и сделаю

Где вы вызываете $entityManager->flush() ? Видел презентацию, где делали отдельный мидлвер для flush, в рабочих проектах постоянно вижу, что flush вызывается прям в репозиториях. Как мне кажется, перечёркивается весь смысл Data Mapper, с другой стороны не возникнет ситауции, когда вызвали persist, но потом забыли вызвать flush