я отдельно и делаю, там несколько каскадов валидации

самый первый - схема, далее айдишники и все такое прочее

@catamorphism надо ваять экзампл, походу :) И вИдение там отразить

оба можно делать в ValidationT ErrorType m a, где ErrorType это что-то предсказуемо сериализуемое в ошибку

@astynax ну я так то в курсе что документации нифига нет, руки так и не дошли

надо конечно

Может я экзампл накатаю - на скучных докладах в Минске себя займу :)

ну а что у тебя приходит в функцию которая таки "делает" что-то? рекорд или жсон с шематиками вашими?

Рекорд

смотри, в сервантохендлер приходит изоморфное json значение со схемой типе

JsonRepr MySchema

ну вот, она лезет в базу и узнает что айдишника такого и нет. и как она рапортует? Ей значит нужно знать как поля именуются

на нем прогоняется валидация для схемы, далее кастомная валидация, далее конвертится во все что угодно(последние два пункта можно в любом порядке и там it depends)

у вас логика же не в хендлерах

у меня требование такое: я хочу чтобы ошибки в ответе json-овом соответствовали тоже определенной схеме

поэтому мне важно получить по результату валидации что-то 1) предсказуемо сериализируемое 2) соответствующее схеме 3) по возможности красивое(это сложнее, где-нибудь какой-нибудь show в поле да проскакивает)

я в итоге сделал кучу ADT с конструкторами в стиле HuitaUserIdDoesNotExit | HuitaTargetSomethingInBadState. фронтендер один чёрт это игнорирует и сам валидирует :(

в общем два мотивирующих юзкейса для validationt это 1) валидация крупных форм и запросов, где хочется агрегировать весь список проблем по ключам/jsonpath/xpath 2) валидация непосредственно схем, которая по сути как п.1, но без доменно-специфичных проверок

полиморфизм можно как то описать в математической нотации?

кванторами всеобщности

@catamorphism ну, по моему мнению, валидашка форм и запросов будет без IO. А потом проверки в проблемной области уже будут стучать в бд.

ну и валидашка форм суть парсинг

по сути полиморфизм это множество отображений из полиморфных типов в некоторый тип?

я так и делаю в принципе

иначе не отделить механизм RPC от логики

ValidationT ErrorMapWhatever Identity a

а следующий либо в m каком-то, либо в ValidationT ErrorMapWhatever m a

единственный бонус тут в том что ошибки покрасивее, не то что Aeson выдаст

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

Ну так во вторую ступень уже придет "бизнесс" объект, не?

т.к. клиенты вешают всякие обработчики на это

это да

Ну так во вторую ступень уже придет "бизнесс" объект, не?

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

в разных случаях, наверное, по разному удобнее

мне нравится что получается четкий decoupling представления API от внутреннего

у меня в общем то считай коды для ошибок, только они текстовые и имеют вид errors = [{ code = "HuitaIsBad", title="Bad huita", detail="Huita should not be bad"}, ....]

риск сломать API специально каким-то дурацким инстансом падает многократно

мы ошибки структурой отдаем json-овой

там поля отдельные с ошибкой/детализацией

фак

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

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

типа not found

или ошибки валидации

я тут себе на голову вызвался писать реализацию перцептрона Розенблата на Prolog

@lonokhov ну вот допустим ты хочешь юзера заставить создавать секьюрный пароль

@catamorphism вот да, тоже паттерн матчу ошибки бэкэнда что-бы 404 выдать :)

ты хочешь чтобы выполнялось 1) есть цифры 2) есть буквы 3) есть спецсимволы 4) длина достаточная

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

(за первые 3 требования нынче бьют по рукам)

ты как юзер правишь пароль, далее приезжает со следующего запроса ошибка 2 и.т.д.

И?

я хочу все их агрегировать и отдавать разом

(за первые 3 требования нынче бьют по рукам)

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

Валидировать аппликативно можно и бизнесс объект

у меня проблема с jsonpath/xpath и прочим

оно не нужно, кмк

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

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

ну и чёрт с ним, на фронте путь можно восстановить из ошибки

/me восстаёт против принятых норм HTTP-RPC (aka RESTful)

самый главный поинт не в валидации все-таки, основной в том, чтобы представление транспортное(API или как угодно), было отвязано от внутреннего и сериализация/десериализация не зависела от всяких To/From инстансов для конкретных типов

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

и маппинг одного в другое будет в хэндлере. а там уже бизнесс пошел

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

но то что parseJSON выдаёт не очень полезную ошибку я согласен. String явно не достаточно.

пусть даже они теперь там путь пишут

вообще я сейчас вот так json парсю, и это боль int parse_string_array(const json_t* js, std::vector<std::string> &out) { if (json_is_array(js)) { int index; json_t* value; out.clear(); json_array_foreach(js, index, value) { if(json_is_string(value)) { out.push_back(json_string_value(value)); } else { return -1; } } return 0; } return -1; }

Где-то под СПб живёт чувак, который в генте Haskell суппортит.

@qnikst про тебя легенды уже ходят

ваще

Ух ты.

Почти что "во плоти" 😆

во слове

тот самый человек, который пользуется гентой

это как в анекдоте: “так вот кто купил второй!”

А кто в минск поедет?

я

Я думаю, тут есть ещё пользователи генты.

И тишина....

И вот эта круглая штука, перекати-поле, бежит из одного края чатика в другой.

Я думаю, тут есть ещё пользователи генты.

Я ливнул на никсос с месяц назад