Исключение связывания свойства/поля Spring MVC

Question

Я использую Spring MVC 2.5 и для моего класса модели/компонента, на данный момент я использую проверку на стороне сервера. Одна из проверок, которую я хотел сделать, - проверить, не являются ли некоторые из входов числовыми (0-9). Пользователь может вводить нечисловые символы, такие как «abcd» вместо «1234».

У меня есть @Pattern, который принимает только положительный BigDecimal (он представляет собой сумму в долларах).

public class OfferSettingBean implements Serializable { 


private static final String NUMBER_WITH_DECIMAL_PLACES_ONLY="^\\d+([.]\\d+)?$"; 

//org.hibernate.validator.pattern 
@Pattern(regex = NUMBER_WITH_DECIMAL_PLACES_ONLY, message = "invalid.amount") 
    private BigDecimal offerSize; 
//the rest of the code goes here including setter and getter methods 
} 

страница JSP

<input type="text" name="offerSize" id="offerSize" value="${offerSetting.offerSize}" placeholder="$" /> 

Проблема с моей кодой, если пользователь вводит номер нон характера как «asdfsd» оно не достигает даже до точки, где он должен проверить шаблон.

Failed to convert property value of type [java.lang.String] to required type [java.math.BigDecimal] for property offerSize; nested exception is java.lang.NumberFormatException 

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

Одно уродливое решение может быть в методе setSize setter. Я могу проверить ближайшее значение и сделать что-то, если оно не является числом. Но мне это не нравится.

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

FYI: Я знаю, что я сделаю проверку на стороне клиента (используя JQuery) последним. Теперь я предполагаю, что пользователь каким-то образом передает проверку на стороне клиента.

Answer 1

Сообщение об ошибке самоподписывается. @Pattern может использоваться для валидации аргументов String. Номера (int, double, BigDecimal и т. Д.) Анализируются автоматически и не требуют специальной проверки.

Итак, просто удалите свой узор или создайте поле String и проанализируйте его самостоятельно. (Второе решение плохое).

BTW Вы уверены, что вам действительно нужно BigDecimal для работы с деньгами? Знаете ли вы, как double большой? Я думаю, что он достаточно велик, чтобы удерживать общую сумму денег, которая когда-либо была напечатана во всем мире за последние 5 тысяч лет.

Answer 2

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

Да!

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

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

FYI: Я знаю, что я собираюсь сделать проверку на стороне клиента (с помощью JQuery) последней на.Теперь я предполагаю, что пользователь каким-то образом передает проверку на стороне клиента.

Даже позже, один лучше от проверки как на стороне клиента и на стороне сервера, ИМО. Существует много способов проверки подлинности на стороне клиента, как невинных, так и злонамеренных, и даже если это не так, приятно иметь возможность повторно использовать код на стороне сервера, не беспокоясь о том, что вся проверка прошла, потому что она была расположена в клиентском скрипте Java.