это понятно, но как пользоваться то?

@etehtsea https://wiki.haskell.org/Humor

@lonokhov агрегирует ворнинги или завершает валидацию на error, сейчас пример покажу

Типов достаточно для документации?

это понятно, но как пользоваться то?

runAvlidationT $ User <$> validateName <*> validateAge

Типов достаточно для документации?

потому и Straightforward validation monad. :)

это же как https://hackage.haskell.org/package/these, только со стейтом?

/me вообще у себя на AccValidation / EitherT наговнякал всякое

У нас ещё ворнинги есть, т.е. можно получить результат валидации вместе со списком предупреждений

@astynax а что за MonoidMap?

ну так и ChronicleT может

> Map with Monoid instance which mappend its values же :)

но зачем?

MonoidMap это мап, который клеит ошибки для одного поля

представь что валидируешь веб-форму

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

когда агрегируешь в MonoidMap, то они маппендятся

вот я в итоге отказался от такого, ибо тогда имена в формочке просачиваются в бэкенд

т.е. один экшен проверяет поле foo одним валидатором, другой - поле foo другие валидатором, а потом они мерджатся в ValidationT монаде

ну это понятно

а т.к. ValidationT это трансформер, то можно со своими любыми монадами запускать, в базу там ходить, это всё

а у вас (<*>) == ap?

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

вот я в итоге отказался от такого, ибо тогда имена в формочке просачиваются в бэкенд

это очень удобно, когда ты валидируешь API по схеме, например, т.к. по именам из API и надо агрегировать всё и отдавать в клиент/фронт

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

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

https://github.com/typeable/schematic/blob/master/src/Data/Schematic/Validation.hs#L56 https://github.com/typeable/schematic/blob/master/src/Data/Schematic.hs#L78

у меня не приходит рекорд пропарсенный как раз!

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

Я в итогде сделал рекорд попарсенный, ибо валидация таких вещей как "а вот айдишник то есть?" удобнее делать отдельно от парсинга.

ну т.е. ходить в бд

ибо транзакции

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

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

@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 от внутреннего

ERROR: S client not available

у меня в общем то считай коды для ошибок, только они текстовые и имеют вид 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 явно не достаточно.

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