Б
У всех разные представления о высоком юзабилити
хорошие сообщения об ошибках это бесспорно хорошее юзабилити
Size: a a a
2020 February 03
Б
решение уровня java validation api по юзабилити и качеству ошибок в скале ещё никто не сделал
SA
решение уровня java validation api по юзабилити и качеству ошибок в скале ещё никто не сделал
я сделал. движок JSR303 можно адаптировать под скалу и он отлично работает. Но хочется же возвышенного, на ньютайпах.
Oℕ
решение уровня java validation api по юзабилити и качеству ошибок в скале ещё никто не сделал
А что там такого, расскажите
λ
я сделал. движок JSR303 можно адаптировать под скалу и он отлично работает. Но хочется же возвышенного, на ньютайпах.
Зачем тебе ньютайпы не понятно. Тебе ж сказали, юзай refined
AO
Я вот не очень понимаю как парсинг связан с валидацией данных.
По мне это два развязанных процесса. Если бы будешь это липить в кучу, то это уже не библиотека для парсинга. Потом тебе захочется в этот слой добавить ещё какого говна, типа я хочу на этапе десиарилизации получать для вот этого id в поле сущность при помощи эффекта. Тоже прикажите это в либу пихать?
По мне это два развязанных процесса. Если бы будешь это липить в кучу, то это уже не библиотека для парсинга. Потом тебе захочется в этот слой добавить ещё какого говна, типа я хочу на этапе десиарилизации получать для вот этого id в поле сущность при помощи эффекта. Тоже прикажите это в либу пихать?
SA
А что там такого, расскажите
Олег, я чуть выше всё изложил. декларативное объявление ограничений на поля, аккумулирующий валидатор, объект ошибки содержит сообщение, текст ошибочного поля, полный путь к ошибочнуму полю от корня дерева объектов
AO
я сделал. движок JSR303 можно адаптировать под скалу и он отлично работает. Но хочется же возвышенного, на ньютайпах.
Большенство jsr которые так или иначе появились под давлением spring сообщества - полный кал
SA
Большенство jsr которые так или иначе появились под давлением spring сообщества - полный кал
говоришь, твой валидатор лучше по функционалу?) делись тогда.
λ
Я вот не очень понимаю как парсинг связан с валидацией данных.
По мне это два развязанных процесса. Если бы будешь это липить в кучу, то это уже не библиотека для парсинга. Потом тебе захочется в этот слой добавить ещё какого говна, типа я хочу на этапе десиарилизации получать для вот этого id в поле сущность при помощи эффекта. Тоже прикажите это в либу пихать?
По мне это два развязанных процесса. Если бы будешь это липить в кучу, то это уже не библиотека для парсинга. Потом тебе захочется в этот слой добавить ещё какого говна, типа я хочу на этапе десиарилизации получать для вот этого id в поле сущность при помощи эффекта. Тоже прикажите это в либу пихать?
Ну вообще, наверное простую валидацию то можно делать. Как раз если в поле лежит совсем дичь
AO
говоришь, твой валидатор лучше по функционалу?) делись тогда.
Моего валидатора нет, потому что это вообще часть бизнесс логики, которая есть в 5-10 процентах кейсов
SA
Я вот не очень понимаю как парсинг связан с валидацией данных.
По мне это два развязанных процесса. Если бы будешь это липить в кучу, то это уже не библиотека для парсинга. Потом тебе захочется в этот слой добавить ещё какого говна, типа я хочу на этапе десиарилизации получать для вот этого id в поле сущность при помощи эффекта. Тоже прикажите это в либу пихать?
По мне это два развязанных процесса. Если бы будешь это липить в кучу, то это уже не библиотека для парсинга. Потом тебе захочется в этот слой добавить ещё какого говна, типа я хочу на этапе десиарилизации получать для вот этого id в поле сущность при помощи эффекта. Тоже прикажите это в либу пихать?
смысл в том, чтобы в приложении в модели *никогда* не было неверных данных
AO
Ну вообще, наверное простую валидацию то можно делать. Как раз если в поле лежит совсем дичь
Да пожалуйста, это и сейчас никто не мешает делать, только нахрена это накапливать? Эта инфа нужна исключительно на этапе разработки фронта
SA
Моего валидатора нет, потому что это вообще часть бизнесс логики, которая есть в 5-10 процентах кейсов
это вопрос к качеству ваших приложений. все поля входных моделей апи должны валидироваться.
NV
Я вот не очень понимаю как парсинг связан с валидацией данных.
По мне это два развязанных процесса. Если бы будешь это липить в кучу, то это уже не библиотека для парсинга. Потом тебе захочется в этот слой добавить ещё какого говна, типа я хочу на этапе десиарилизации получать для вот этого id в поле сущность при помощи эффекта. Тоже прикажите это в либу пихать?
По мне это два развязанных процесса. Если бы будешь это липить в кучу, то это уже не библиотека для парсинга. Потом тебе захочется в этот слой добавить ещё какого говна, типа я хочу на этапе десиарилизации получать для вот этого id в поле сущность при помощи эффекта. Тоже прикажите это в либу пихать?
Что здесь подразумевается под парсингом и валидацией? Парсинг — получение АСТ жсона, валидация — проверка что в поле phone лежит телефон с правильным форматом?
AO
это вопрос к качеству ваших приложений. все поля входных моделей апи должны валидироваться.
Ну дак и в чем проблема написать тот же validated руками? Получится столько же строк как и с аннотациями. В чем вообще профит?
AO
Что здесь подразумевается под парсингом и валидацией? Парсинг — получение АСТ жсона, валидация — проверка что в поле phone лежит телефон с правильным форматом?
Да
λ
@sergey_alaev вообще зная чуть-чуть твои код, тебе нельзя делать валидацию на этапе Парсинга. У тебя ж там батчи, не?
λ
А, или ты про другое место
NV
А к чему относится построение кейз класса из АСТ? Валидация?