0

현재 스프링 MVC 2.5를 사용하고 있으며, 모델/빈 클래스에 대해서는 서버 측 유효성 검사를 사용하고 있습니다. 입력 중 일부가 숫자가 아닌지 (0-9) 확인하고 싶습니다. 사용자는 '1234'대신 "abcd"와 같은 숫자가 아닌 문자를 입력 할 수 있습니다.스프링 MVC 프로퍼티/필드 바인딩 예외

저는 긍정적 인 BigDecimal (달러 금액을 나타냄) 만 허용하는 @Pattern입니다.

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에 바인딩하여 실패하게한다고 생각합니다.

하나의 추악한 솔루션이 offerSize setter 메소드에있을 수 있습니다. 다음 값을 확인하고 숫자가 아닌 경우 무언가를 할 수 있습니다. 하지만 나는 그걸 좋아하지 않는다.

이러한 종류의 바인딩 문제를 처리하는 더 좋은 방법은 무엇입니까?

FYI : 저는 클라이언트 측 유효성 검사 (JQuery 사용)를 할 것입니다. 이제는 사용자가 클라이언트 측 유효성 검사를 어떤 방식으로 통과시키는 것으로 가정합니다.

답변

2

오류 메시지는 자체 설명 할 수 있습니다. @PatternString 인수의 유효성 검사에 사용할 수 있습니다. 숫자 (int, double, BigDecimal 등)는 자동으로 구문 분석되므로 특별한 유효성 검사가 필요하지 않습니다.

그래서 패턴을 제거하거나 입력란 String을 만들고 직접 구문 분석하십시오. (두 번째 해결책은 나쁘다).

나는 돈을 벌기 위해 실제로 BigDecimal이 필요합니까? 얼마나 double 큰지 아십니까? 나는 최근 5 천년 동안 전 세계에서 인쇄 된 총 돈을 보유하기에 충분하다고 생각합니다.

+0

내가 패턴을 갖고 싶었던 이유는 모든 입력 문자가 검증 된 중앙 위치에 있어야하기 때문입니다. 그래서 그것이 부정이거나 아닌지, null인지 아닌지, 숫자가 포함되어 있는지 아닌지 확인해야합니다. 두 번째 것은 가능하지만 당신이 말했듯이 그것은 나쁠 수도 있습니다. 후자의 질문을 위해 시스템은 10 년 전에 설계되었으므로 BigDecimal 만 사용해야합니다. – WowBow

0

나는 문제가 그것이 실패하게 BigDecimal의에 문자열 값을 결합하는 패턴을 확인하기 전에 생각합니다.

예!

이러한 종류의 바인딩 문제를 처리하는 더 좋은 방법은 무엇입니까?

여기에 무슨 뜻인지 확실하지 않습니다. 오류가있었습니다. 오류가 발견되었습니다. 모두 잘 보인다. 어떤 행동을 선호합니까?

는 참고 : 나는에 후자의 클라이언트 측 유효성 검사 (jQuery를 사용) 할 것입니다 알고있다.이제는 사용자가 클라이언트 측 유효성 검사를 어떤 방식으로 통과시키는 것으로 가정합니다.

심지어 나중에, 하나는 IMO, 클라이언트 측과 서버 측 모두를 확인하는 더 나을 것입니다. 클라이언트 측 유효성 검사가 무해하고 악의적 인 경우 모두 실패 할 수있는 많은 방법이 있습니다. 그렇지 않은 경우에도 서버 측 코드가 배치 되었기 때문에 사라진 모든 유효성 검사를 걱정하지 않고 서버 측 코드를 재사용 할 수 있다는 것이 좋습니다. 클라이언트 측 Java 스크립트에서.

+0

필요한 것은 패턴에 대한 매개 변수 인 메시지를 표시하는 것입니다. 예외 메시지가 아님 – WowBow