LINUX.ORG.RU

Туплю с валидатором-конвертером

 ,


0

1

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

Падать на кривых данных в запросе не хочется.
Ставить два валидатора: один до конвертации, другой после - маразм.
Объединить валидатор и конвертер - ещё хуже.
Выставить из компонента public void setValue(String s) throws Exception просто кошмар.

Понял, что мозг просто заклинило и я перебираю одни и те же варианты в разных комбинациях. Хотелось бы оригинальных (можно и не очень) предложений, что б вылезти с колеи.

★★★★★

эээ... обычный atoi своими силами со всеми проверками спасет отца сишной демократии

unt1tled ★★★★
()

Не мудри. Один валидатор с двумя условиями - что тут сложного?.. Условий может быть в общем случае и больше двух... сколько угодно. Все должны выполняться.

BattleCoder ★★★★★
()

Или пример кода что ли кинь. Чтобы мы поняли, где там сложность.

BattleCoder ★★★★★
()
Ответ на: комментарий от BattleCoder

Сложность не в коде, а в подходе.

Один валидатор с двумя условиями - что тут сложного?

На вебморде есть поле ввода для чиселки. На сервере есть компонент, в который эту чиселку надо запихнуть. Допустим, при этом нужно проверить что чиселка больше 10.

Вроде бы всё очевидно: валидатором проверить что условие выполняется и если что-то не так вернуть ошибки, которые показать на форме. Но в дело вмешивается http запрос, в котором вместо чиселки может прилететь любая лабуда. Т.е. строку из запроса надо сконвертить в число, если же это не удалось то до валидатора дело просто не дойдёт. При этом хочется вернуть назад ошибку, что юзер вместо числа написал фигню («число» пример гипотетический, случаи могут быть сложнее).

Очень хочется каким-то образом стандартизировать этот самый механизм отображения ошибок, что б было не важно на каком месте отвалилось, но ведь конвертация сторка-число это ответственность конвертера.

ya-betmen ★★★★★
() автор топика
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

Ну пусть будет строка. Ок. У неё пусть будет два условия. Первое, что строка - число. Второе, что если оно число, то ещё и нужное число, типа больше 10, меньше 100. В обоих случаях, если условие нарушится - выкинуть аналогичный bad request с аналогичным телом, одинаковый формат, но разное сообщение об ошибке.

BattleCoder ★★★★★
()
Ответ на: комментарий от ya-betmen

смотрите, дети, мутант не осилил MVC, а уже лезет в валидаторы и вебморды

вон из профессии

anonymous
()
Ответ на: комментарий от ya-betmen

Т.е. строку из запроса надо сконвертить в число, если же это не удалось то до валидатора дело просто не дойдёт.

Regex? И все дойдет.

Nervous ★★★★★
()

В таких случаях обычно есть два объекта: 1) конвертер - преобразует из String в заданный тип T, 2) валидатор - проверяет что значение типа T удовлетворяет заданным условиям.

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

ricie
()

Конвертер при конвертации проводит валидацию. После этого на успешно конвертированных частях объекта запускаются дополнительные валидации.

Legioner ★★★★★
()
Ответ на: комментарий от BattleCoder

Если обе проверки пихать в валидатор, а сам валидатор ставить перед конвертером, то выходит, что валидатор должен учитывать логику работы конвертера (что он сможет сконвертить а что нет). К тому же валидатор числа (больше/меньше) внезапно начинает принимать на вход строку.

ПС. Вопрос не в том что я не могу сконвертить и провалидировать запрос, я просто хочу сделать это наиболее логично и наименее костыльно. Но этот чёртов призрак коммунизмахттп-запроса постоянно путает карты.

ya-betmen ★★★★★
() автор топика
Ответ на: комментарий от Legioner

Т.е. из конвертера должен торчать наружу ещё и интерфейс валидатора? При чём из любого ковертера.

ya-betmen ★★★★★
() автор топика
Ответ на: комментарий от ya-betmen
interface Errors {
    void addError(...);
}

interface Converter<From, To> {
    Optional<To> convert(From from, Errors errors);
}

interface Validator<T> {
    void validate(T item, Errors errors);
}

как-то так.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Во! Спасибо, точно ведь ошибки можно не напрямую возвращать, а то у меня что-то мозга за мозгу заехала.

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

ya-betmen ★★★★★
() автор топика
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

Хорошая валидация должна сообщать все ошибки, а не только первую. Нет ничего хуже при вводе формы узнавать ошибки по одной :) Ещё и пароль с капчей вводить каждый раз.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

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

А если конвертер навернётся то валидировать всё равно нечего.

ya-betmen ★★★★★
() автор топика
Ответ на: комментарий от Legioner

Тут важно отметить, что getSuppressed - один из самых недооцененных методов. А то как начнут городить какие-то списки исключений, плодить сущности - что начинается, мамачьке!

cdshines ★★★★★
()
Ответ на: комментарий от ya-betmen

Объяснись! Удобно же бросить одно ValidationException, у которого в suppressed индивидуальные по каждой структуре, которую валидируешь.

cdshines ★★★★★
()
Ответ на: комментарий от cdshines

Да объяснять-то особо нечего. Удобным оно кажется только в теории если смотреть на него с точки зрения выбрасывания ошибок. В реальности это костыль, который придумали на крайний случай, когда выкинуть ошибку нельзя а дропнуть не хочется. И при обработке он требует таких же костыльных манипуляций с нетипизированным массивом, да ещё и прибивет логику валидации намертво к процессу обработки ошибок.

тут ошибка==исключение

ya-betmen ★★★★★
() автор топика
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

Так ты сначала напиши что-то вменяемое. Мой совет как раз нормально вписывается во все общепринятые практики, а что ты там хочешь в вакууме получить, никто так и не понял.

cdshines ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.