Struts에서 Validator 프레임워크 사용

모든 애플리케이션에는 백엔드 데이터베이스에 삽입하는 데이터가 합법적이고 유효한지 확인할 책임이 있습니다. 결국 이러한 애플리케이션에 의존하는 데이터가 손상되면 애플리케이션에 또 어떤 재앙이 닥칠 수 있습니까? 자체적으로 제대로 작동하도록 사용합니까? 예를 들어, 공식 관계형 데이터베이스를 사용하는 애플리케이션에서 데이터베이스의 각 필드에는 저장된 데이터가 어느 정도 정확하도록 보장하는 고유한 규칙과 제약 조건이 있습니다. 백엔드 저장소 데이터를 사용하는 모든 애플리케이션은 제출하는 데이터의 무결성을 보호할 책임이 있습니다.
　
표준을 충족하지 않는 데이터를 삽입하거나 업데이트하려는 시도는 감지되어 거부될 가능성이 높습니다. 이러한 종류의 감지는 애플리케이션의 모든 부분에 분산될 수 있으며 일부 확인은 프레젠테이션 계층에서 수행될 수 있습니다. 비즈니스 로직 계층에서는 일반적으로 비즈니스 로직 개체에도 비즈니스 로직 확인 기능이 있으며 데이터도 백그라운드에서 확인해야 합니다. 데이터 베이스.
　
안타깝게도 이러한 종류의 확인은 애플리케이션 어디에나 있기 때문에 애플리케이션에서 어느 정도 코드 중복을 확인하게 됩니다. 이는 애플리케이션이 원하는 것이 아닙니다. 여러 위치에서의 작업 중복으로 인해 애플리케이션 배포 및 유지 관리에 더 많은 시간이 걸리기 때문입니다. 이러한 유효성 검사 규칙을 애플리케이션 전체에서 재사용할 수 있다면 애플리케이션이 더 유연해지며, 배포가 더 빨라지고, 사용자 정의가 더 쉬워지며, 프로그램이 더 유연해집니다.
　
　Jakarta Commons 프로젝트 Validator 프레임워크 소개
　Validator는 David Winterfeldt가 만든 오픈 소스 프로젝트이기도 합니다. Commons 프로젝트는 주로 Validator와 같은 재사용 가능한 구성 요소를 제공합니다. 기타 잘 알려진 Commons 구성 요소로는 BeanUtils, Digester, Logging 프레임워크 등이 있습니다. Validator 버전 1.0은 2002년 11월 초에 출시되었습니다.
　
Validator 사용의 이점
Validator 프레임워크를 사용하면 애플리케이션 코드에서 유효성 검사 규칙을 정의하는 것보다 다음과 같은 많은 이점이 있습니다.
한 곳에서 애플리케이션에 대한 유효성 검사 규칙을 정의할 수 있습니다. . 유효성 검사 규칙과 애플리케이션은 느슨하게 결합되어 있습니다.
서버 측과 클라이언트 측 유효성 검사 규칙을 동일한 위치에서 정의할 수 있습니다.
. 국제화 지원
.정규 표현식 지원
.웹 애플리케이션 또는 표준 Java 애플리케이션에 사용할 수 있습니다.
또한 Validator의 가장 큰 특징은 플러그 기능을 지원한다는 것입니다. 기사 후반부
　
작업을 더 잘 완료하기 위해 Validator 프레임워크에 내장된 유효성 검사 규칙을 사용하는 방법을 볼 수 있으며, 더 중요한 것은 Validator 프레임워크를 사용하면 유효성 검사기를 사용자 정의하고 프레임.
　
　Struts와 Validator의 관계
　Validator 프레임워크 자체가 Struts 프레임워크를 기반으로 구축되었다는 점에 유의해야 합니다. Validator의 창시자인 David Winterfeldt는 Struts를 사용하는 과정에서 많은 ActionForm 클래스에서 동일한 유효성 검사 규칙을 반복적으로 사용해야 하며 이로 인해 코드 중복이 많이 발생한다는 사실을 발견했습니다. 그래서 그는 이러한 중복성을 제거하기 위해 Validator 프레임워크를 만들기로 결정했고, Validator가 탄생했습니다.
　
Validator 아키텍처는 원래 Struts 아키텍처를 위해 탄생했지만 Struts 아키텍처와 독립적으로 사용되도록 설계 및 구성되었습니다. 이 기능을 사용하면 Struts 기반인지 여부에 관계없이 모든 애플리케이션에서 이 프레임워크를 사용할 수 있습니다. Struts 프레임워크를 사용하지 않는다고 해서 애플리케이션에 대한 Validator 아키텍처의 효과에 영향을 주지는 않습니다. 실제로 이것이 Validator가 Struts 프로젝트의 직접적인 일부가 아닌 Jakarta Commons 프로젝트의 일부인 이유입니다.
　
이제 이 프레임워크를 Struts 기반 아키텍처와 같은 웹 애플리케이션에 통합해 보겠습니다. 기사 마지막 부분에서는 EJB 기반 애플리케이션과 같은 다른 유형의 애플리케이션에 이를 적용하는 방법을 소개합니다.

유효성 검사기 구성 요소 개요
유효성 검사기 아키텍처는 다음 구성 요소로 구성됩니다.
유효성 검사기,
구성 파일,
JSP 사용자 정의 태그, 양식 클래스;

유효성 검사기란 무엇입니까?
유효성 검사기는 유효성 검사 규칙을 실행할 때 유효성 검사기 프레임워크에서 호출되는 Java 클래스입니다. 프레임워크는 구성 파일에 정의된 메서드 서명을 기반으로 이 Validaotor 클래스를 호출합니다. 일반적으로 각 유효성 검사기 클래스는 별도의 유효성 검사 규칙을 제공하며, 이는 더 복잡한 규칙 세트로 결합될 수 있습니다.
　
참고: 때때로 편의를 위해 Validator 클래스는 여러 유효성 검사 규칙을 정의할 수도 있으며, 각 규칙은 정적 메서드이며 클라이언트 상태 정보를 포함하지 않습니다.
　
프레임워크는 14개의 기본 유효성 검사 규칙을 제공합니다. 때때로 이러한 규칙은 유효성 검사기 프레임워크의 "기본 규칙"이라고도 합니다.
이름　　　　 설명
byte, short, 정수, 값이 해당 기본 데이터 유형으로 변환 가능한지 확인
long, float, double
CreditCard 입력 필드가 합법적인 신용카드 번호인지 확인
date 입력이 되었는지 확인 필드는 유효한 날짜입니다.
email 입력이 합법적인 이메일 주소인지 확인하세요.
마스크 입력 필드가 정규 표현식과 성공적으로 일치할 수 있는지 확인하세요.
maxLength 값의 길이가 다음보다 작거나 같은지 확인하세요. 주어진 최대 길이
minLength 값의 길이가 주어진 최소 길이보다 크거나 같은지 확인
범위 | 값의 범위가 최대값과 최소값 사이인지 확인
필요 | 입력 필드가 비어 있지 않은지, 공백을 포함하지 않는 값의 길이가 0보다 큰지 확인
표 1
표 1에서 볼 수 있듯이 Validator 프레임워크는 대부분의 유효성 검사를 제공합니다. 웹 애플리케이션에 필요한 규칙. 이러한 기존 유효성 검사 규칙을 사용하여 고유한 유효성 검사 프로필을 만들 수 있습니다. 그럼에도 불구하고 앞서 언급했고 나중에 설명하겠지만 필요에 따라 더 많은 유효성 검사기를 자유롭게 추가할 수 있습니다.
　
이제 Struts 아키텍처 기반 애플리케이션에서 이러한 기본 유효성 검사기를 구성하고 사용하는 방법에 대해 논의하겠습니다.
유효성 검사기 프레임워크를 유연하게 만드는 것은 모든 유효성 검사 규칙과 특정 세부 사항이 외부 파일의 구성 선언을 통해 구현된다는 것입니다. 귀하의 애플리케이션은 이러한 특정 유효성 검사 규칙을 알 필요가 없습니다. 이 기능을 사용하면 애플리케이션의 소스 코드를 건드리지 않고도 규칙 세트를 확장하고 수정할 수 있습니다. 이는 각 설치를 개인화하려는 경우 또는 요구 사항이 변경되는 경우 매우 중요합니다.
Struts 1.1의 Validator 프레임워크를 사용하는 경우 두 개의 구성 파일을 사용하게 됩니다. 하나는 validator-rules.xml이고 다른 하나는 검증.xml입니다. 실제로 이름을 임의로 지정하거나 결합할 수도 있습니다. 하나의 XML 파일로 변환합니다. 하지만 각각의 용도가 다르기 때문에 별도로 보관하는 것이 좋습니다.
　
참고: 자카르타 웹사이트에서 Validator를 다운로드하는 경우 이 두 파일은 포함되지 않습니다. 이 두 파일은 Validator 프레임워크가 포함된 Struts 다운로드에서만 찾을 수 있습니다.
Validator-rules.xml 파일
validator-rules.xml 파일은 애플리케이션이 사용할 수 있는 유효성 검사기를 정의합니다. validator-rules.xml은 모든 애플리케이션에서 사용할 수 있는 유효성 검사기를 정의하는 템플릿 역할을 합니다.
　
참고: 이 xml 파일과 아래에서 논의할 다른 xml 파일은 클래스 로더가 찾을 수 있는 위치에 배치되어야 합니다. 웹 애플리케이션에서 유효성 검사기 프레임워크를 사용할 때 올바른 위치는 WEB-INF 아래에 있어야 합니다.
validator-rules.xml 파일은 jakarta.apache.org/struts/dtds/validator-rules_1_1.dtd에서 다운로드할 수 있는 validator-rules_1_1.dtd 관리 대상입니다. 우리는 이 파일의 특정 세부 사항을 연구하는 데 너무 많은 시간을 소비하고 싶지 않으며 여기서는 몇 가지 기본적인 소개만 제공합니다.
validator-rules.xml 파일에서 가장 중요한 요소는 요소에 포함되어 있습니다. 예를 들어, 예 1:
예 1: 간단한 validator-rules.xml 파일
< 양식 검증>
　
　methodparams="java.lang.Object,
org.apache.commons.validator.ValidatorAction,
org.apache.commons.validator.Field,
org.apache.struts.action.ActionErrors,
javax.servlet.http.HttpServletRequest"
msg="errors.required"/>

classname="org.apache.struts.util. StrutsValidator"
Method="validateMinLength"
methodparams="java.lang.Object,
org.apache.commons.validator.ValidatorAction,
org.apache.commons.validator.Field,
ORG.APACHE.STRUTS.ACTION.ACTIONERRORS,
javax.servlet.httpservletRequest "
=" 필수 "
msg =" 오류에 따라 다릅니다. minlength "/& gt; <🎜 ;> & Lt;/global & gt ;
　
　
　
　
애플리케이션에서 사용하는 각 유효성 검사기는 예제 1에서는 두 개의 유효성 검사기를 보여줍니다. 하나는 요청 유효성 검사기이고 다른 하나는 최소 길이 유효성 검사기입니다. 요소는 다양한 속성을 지원합니다. 이러한 속성은 이 유효성 검사기가 호출해야 하는 올바른 클래스와 메서드를 프레임워크에 알리는 데 필요합니다. 예를 들어, 예제 1의 요청 유효성 검사기 요소는 이 유효성 검사기가 org.apache.struts.util.StrutsValidator 클래스의 verifyRequest() 메서드를 호출할 것임을 나타냅니다. 유효성 검사기는 다른 유효성 검사기에 의존할 수도 있습니다. 예를 들어 예제 1의 최소 길이 유효성 검사기는 이 유효성 검사기가 요청하는 유효성 검사기에 의존함을 나타내는 데 사용되는 종속 속성을 포함합니다. msg 속성은 프레임워크가 올바른 오류 메시지를 생성하는 데 사용할 키 값으로 리소스 바인딩을 지정합니다. 리소스 바인딩을 사용하면 오류 메시지를 현지화하는 데 도움이 됩니다.
　 요소는 하위 요소도 지원하므로 클라이언트에서 실행할 JavaScript 기능을 지정할 수 있습니다. 이러한 방식으로 서버 측 유효성 검사와 클라이언트 측 유효성 검사를 동일한 위치에 지정할 수 있으므로 애플리케이션 유지 관리가 간단해집니다.
　
　validation.xml 파일
　Validator 프레임워크의 두 번째 구성 파일은 유효성 검사.xml이라는 파일입니다. 사실 이름은 마음대로 정하시면 됩니다.

위 내용은 Struts에서 Validator 프레임워크를 사용한 내용이며, 더 많은 관련 글은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요. !