대메뉴 바로가기 본문 바로가기

데이터 기술 자료

데이터 기술 자료 상세보기
제목 Validator를 사용하여 Form 검증
등록일 조회수 5683
첨부파일  

Validator를 사용하여 Form 검증

James Holmes

Validator의 풍부한 내장된 검증 기능을 사용하여 Struts 개발을 단순화하십시오.

Struts 프레임워크의 주요 이점 중 하나는 들어오는 폼 데이타에 대한 데이타 검증을 수행하기 위한 내장된 인터페이스입니다. 검증에 실패한 경우에는 잘못된 데이타를 수정할 수 있도록 애플리케이션이 HTML 폼을 다시 표시하고, 성공한 경우에는 처리가 계속됩니다. Struts 프레임워크의 단순한 검증 인터페이스는 데이타 검증 처리와 관련된 골치 아픈 문제를 대부분 줄여줌으로써 개발자가 데이타를 캡처하고 불완전하거나 잘못된 데이타를 다시 표시하는 체계가 아니라 검증 코드에 초점을 맞출 수 있게 합니다.

그러나 Struts의 내장된 검증 인터페이스는 결점을 갖고 있습니다. 예를 들어, 많은 필드에 동일한 검증 논리가 필요하기 때문에 애플리케이션 전체에서 검증 코드가 과도하게 중복됩니다. 유사한 필드에 대한 검증 논리를 변경하려면 여러 위치에서 코드를 변경해야 할 뿐만 아니라 영향을 받은 코드를 다시 컴파일해야 합니다. 이 문제를 해결하고 Struts의 검증 인터페이스를 향상시키기 위해 Validator 프레임워크가 Struts에 대한 타사 추가 기능으로서 작성되었습니다. 나중에 Validator는 핵심 Struts 코드 기반에 통합되었으며 그 이후로 Struts에서 분리되어 지금은 독립형의 Jakarta Commons 프로젝트가 되었습니다. Validator는 독립적인 프레임워크이기는 하지만 Struts와 함께 완벽하게 패키지화 및 통합됩니다.

Validator 개요

Validator가 없을 경우 모든 폼 데이타 검증을 Form Bean 객체의 validate( ) 메소드로 코드화해야 합니다. 검증을 수행할 각 Form Bean 필드에서는 이를 위한 논리를 코드화해야 합니다. 또한 실패한 검증에 대한 오류 메시지를 저장하는 코드도 작성해야 합니다.

Validator를 사용하면 검증이나 오류 메시지 저장을 위해서 Form Bean에서 코드를 작성할 필요가 없습니다. 대신에 Form Bean은 이 기능을 제공하는 Validator의 ActionForm 하위 클래스 중 하나를 확장합니다.

Validator 프레임워크는 Form Bean에 적용할 수 있는 검증 루틴의 플러그형 시스템으로 설정됩니다. 각 검증 루틴은 단순히 특정 유형의 검증을 수행하는 Java 메소드이며 성공 또는 실패할 수 있습니다. 기본적으로 Validator는 대부분의 검증 시나리오를 충족하는 여러 유용한 검증 루틴과 함께 패키지화된 상태로 제공됩니다. 그러나 Validator 프레임워크에 의해 제공되지 않은 검증이 필요한 경우에는 고유한 사용자 정의 검증 루틴을 만들어 프레임워크에 플러그인할 수 있습니다. 또한 Form Bean이 서버측 검증 인터페이스만 제공하는 것과 달리 Validator는 서버측 및 클라이언트측(JavaScript) 검증을 모두 지원합니다.

Validator는 설치해야 하는 검증 루틴과 특정 애플리케이션에 이러한 검증 루틴을 적용하는 방법을 결정하기 위해 두 개의 XML 구성 파일을 사용합니다. 첫 번째 구성 파일인 validator-rules.xml은 프레임워크에 플러그인해야 하는 검증 루틴을 선언하며 각 검증에 대한 논리적 이름을 제공합니다. 또한 validator-rules.xml 파일은 각 검증 루틴에 대한 클라이언트측 JavaScript 코드를 정의합니다. 이 JavaScript 코드를 브라우저로 보내도록 Validator를 구성하여 서버측 뿐만 아니라 클라이언트측에서도 검증이 수행되도록 할 수 있습니다.

두 번째 구성 파일인 validation.xml은 어떤 Form Bean에 어떤 검증 루틴을 적용해야 하는지 정의합니다. 이 파일의 정의는 struts-config.xml 파일에 있는 Form Bean의 논리적 이름과 함께 validator-rules.xml 파일에 있는 검증 루틴의 논리적 이름을 사용하여 둘을 결합합니다.

Validator 프레임워크를 사용하는 것에는 Validator 플러그인을 활성화하고 Validator의 두 구성 파일을 구성하며 Validator의 ActionForm 하위 클래스를 확장하는 Form Bean을 만드는 것이 포함됩니다. 다음 절에서는 Validator를 구성 및 사용하는 방법에 대해 자세하게 설명합니다.

Validator 플러그인 활성화

Validator 프레임워크가 Struts와 함께 패키지화되어 제공되지만 Validator는 기본적으로 활성화되지 않습니다. Validator를 활성화하려면 다음 플러그인 정의를 애플리케이션의 struts-config.xml 파일에 추가합니다.



value="/WEB-INF/
validator-rules.xml, /WEB-INF/
validation.xml"/>

이 정의는 애플리케이션에 대해 Validator 플러그인을 로드 및 초기화하도록 Struts에 지시합니다. 초기화 시에 이 플러그인은 pathname 속성에 지정된 Validator 구성 파일의 쉼표로 구분된 목록을 로드합니다. 위 예에 나온 것처럼 웹 애플리케이션 상대 경로를 사용하여 각 구성 파일의 경로를 지정해야 합니다.
파일에서 요소가 표시되는 순서를 지정하는 Struts Configuration DTD(Document Type Definition)를 애플리케이션의 struts-config.xml 파일이 따라야 한다는 것에 주의합니다. 따라서 Validator 플러그인 정의를 파일의 적절한 위치에 두어야 합니다. 이 파일의 요소 순서를 올바르게 지정하는 가장 쉬운 방법은 DTD를 따르도록 구성 파일의 형식을 자동으로 지정하는 Struts Console과 같은 툴을 사용하는 것입니다.

validator-rules.xml 구성

Validator 프레임워크는 플러그형 시스템으로 설정되며 이 시스템의 검증 루틴은 단순히 특정 검증을 수행하기 위해 시스템에 플러그인되는 Java 메소드입니다. validator-rules.xml 파일은 Validator가 검증을 수행하기 위해 사용하는 검증 루틴에 선언적으로 플러그인됩니다. Struts 예제 애플리케이션은 이 파일의 미리 구성된 복사본과 함께 패키지화되어 제공됩니다. 고유한 사용자 정의 검증을 프레임워크에 추가하는 경우가 아니라면 대부분의 환경에서 미리 구성된 복사본을 수정할 필요가 없습니다.

목록 1은 검증 루틴이 Validator에 플러그인되는 방법을 보여주는 예제 validator-rules.xml 파일입니다. validator-rules.xml 파일의 각 검증 루틴은 validator 태그를 사용하여 선언하는 고유한 정의를 가지며 이 태그는 name 속성을 사용하여 논리적 이름을 루틴에 할당하고 루틴의 클래스와 메소드를 지정하는 데 사용됩니다. 루틴의 논리적 이름은 이 파일의 다른 루틴에 사용될 뿐만 아니라 해당 루틴을 참조하기 위해 validation.xml 파일의 검증 정의에도 사용됩니다.

서버측과 동일한 검증을 클라이언트측에서 수행하기 위해 클라이언트측 JavaScript 코드를 정의하는 데 사용되는 javascript 태그를 validator 태그가 캡슐화한다는 것에 주의하십시오.

포함된 검증

기본적으로 Validator는 대부분의 검증 시나리오를 처리하는 데 사용할 수 있는 여러 기본 검증 루틴과 함께 패키지화되어 제공됩니다. 이러한드 번호 값의 경우), email(전자 메일 주소 값의 경우) 등과 같은 논리적 이름을 가집니다.

Form Bean 만들기

Validator를 사용하려면 애플리케이션의 Form Bean은 ActionForm 자체가 아니라 Validator의 ActionForm 하위 클래스 중 하나를 하위 클래스화해야 합니다. Validator의 ActionForm 하위 클래스는 Validator 프레임워크에 연결되는 ActionForm의 validate( ) 메소드에 대한 구현을 제공합니다. Validator가 검증 코드를 제공하므로 개발자는 검증을 validate( ) 메소드로 하드 코드화하는 대신에 이 메소드를 완전히 생략할 수 있습니다.

Struts가 제공하는 핵심 기능과 대등한 Validator는 Form Bean 작성 시에 선택할 수 있는 두 가지 경로를 제공합니다. 첫 번째 경로는 다음과 같이 실제적 Form Bean 객체를 만들기 위해 선택할 수 있습니다.

package com.jamesholmes.minihr;

import org.apache.struts.validator
.ValidatorForm;

public class LogonForm extends ValidatorForm {
private String username;
private String password;

public String getUsername() {
return username;
}

public void setUsername(String
username) {
this.username = username;
}

public String getPassword() {
return password;
}
public void setPassword(String
password) {
this.password = password;
}
}


이 클래스는 Validator를 사용하지 않을 경우에 만드는 것과 비슷하지만 ActionForm 대신에 ValidatorForm을 확장합니다. 또한 이 클래스는 ActionForm의 빈 reset( ) 및 validate( ) 메소드에 대한 구현을 제공하지 않는데 이는 ValidatorForm에서 이를 제공하기 때문입니다.
개발자는 일반적인 Form Bean에서와 같은 방법으로 다음과 같이 struts-config.xml 파일에서 실제적 Form Bean을 구성합니다.


type="com.jamesholmes
.minihr.LogonForm"/>

form 태그의 name 속성과 함께 실제적 Form Bean에 제공되는 논리적 이름은 다음과 같이 validation.xml 파일에서 검증을 정의할 때 사용하는 이름입니다.
PUBLIC "-//Apache Software Foundation//
DTD Commons Validator Rules
Configuration 1.0//EN"
"http://jakarta.apache.org/
commons/dtds/validator_1_0.dtd">




depends="required">




Validator는 form 태그의 name 속성 값을 사용하여 검증 정의를 적용해야 하는 Form Bean의 이름에 검증 정의를 일치시킵니다.

Form Bean을 만들 때 선택할 수 있는 두 번째 경로는 다음과 같이 struts-config.xml 파일에서 동적 Form Bean을 정의하는 것입니다.


type="org.apache
.struts.validator.DynaValidatorForm">
type="java.lang.String"/>
type="java.lang.String"/>

동적 Form Bean에서는 실제적 Form Bean 객체를 만들 필요가 없으며 대신에 Form Bean이 가져야 하는 속성과 그 유형을 정의합니다. Struts는 개발자를 대신하여 Form Bean을 동적으로 만듭니다. Validator에서는 핵심 Struts의 경우와 마찬가지로 이 개념을 사용할 수 있습니다. Validator와의 유일한 차이점은 Form Bean의 유형을 org.apache.struts.action.DynaActionForm 대신에 org.apache.struts.validator.DynaValidatorForm으로 지정한다는 것입니다.
동적 Form Bean에 제공된 논리적 이름은 validation.xml 파일에서 검증을 정의할 때 사용하는 이름입니다. Validator는 일치하는 이름을 사용하여 검증을 Form Bean에 연결합니다.

Form Bean을 만들기 위한 두 개의 표준 옵션 외에 Validator는 여러 검증 정의를 하나의 Form Bean 정의에 연결하기 위한 고급 기능을 제공합니다. validatorForm 또는 DynaValidatorForm 기반의 Form Bean이 사용되면 Validator는 struts-config.xml 파일에서 Form Bean에 대한 논리적 이름을 사용하여 Form Bean을 validation.xml 파일의 검증 정의에 매핑합니다. 이 메커니즘은 대부분의 경우에 적합하지만 일부 시나리오에서는 여러 작업 간에 Form Bean이 공유됩니다. 하나의 작업이 Form Bean의 모든 필드를 사용하고 다른 작업은 이러한 필드의 하위 집합만 사용할 수 있습니다. 검증 정의가 Form Bean에 연결되기 때문에 필드의 하위 집합만을 사용하는 작업은 사용하지 않는 필드에 대한 검증을 무시할 수 있는 방법이 없습니다. Form Bean은 검증 시에 사용하지 않는 필드에 대해 오류 메시지를 생성합니다. 이는 Validator가 사용하지 않는 필드를 검증하지 않는다는 것을 알 수 없어 이러한 필드를 단순히 누락되었거나 잘못된 것으로 인식하기 때문입니다.

이 문제를 해결하기 위해 Validator는 검증을 Form Bean이 아니라 작업에 연결할 수 있게 하는 두 개의 추가 ActionForm 하위 클래스를 제공합니다. 이러한 방법을 통해 개발자는 Form Bean을 사용 중인 작업에 기초하여 Form Bean에 적용할 검증을 지정할 수 있습니다. 실제적 Form Bean의 경우 다음과 같이 org.apache.struts.validator.ValidatorActionForm을 하위 클래스화합니다.

public class AddressForm extends ValidatorActionForm {
...
}

동적 Form Bean의 경우 다음과 같이 struts-config.xml 파일에서 Form Bean 정의에 대해 org.apache.struts.validator.DynaValidatorActionForm 유형을 지정합니다.

type="org.apache.struts
.validator.DynaValidatorActionForm">
...

validation.xml 파일 내에서 검증 집합을 Form Bean 이름 대신에 작업 경로에 매핑합니다. 이는 다음과 같이 동일한 Form Bean을 사용하는 주소 작성 및 주소 편집의 두 작업이 정의된 경우 각각 고유한 작업 경로를 가지기 때문입니다.

type="com.jamesholmes
.minihr.CreateAddressAction"
name="addressForm"/>
type="com.jamesholmes
.minihr.EditAddressAction"
name="addressForm"/>

다음 validation.xml 파일 단편은 동일한 Form Bean을 대상으로 하지만 다른 작업 경로로 구별되는 두 개의 검증 집합을 보여줍니다.



depends="required">




depends="required">



Form Bean이 ValidatorActionForm 또는 DynaValidatorActionForm을 하위 클래스화하므로 Validator는 Form Bean에 대한 검증을 찾기 위해 Form Bean의 논리적 이름 대신에 작업 경로를 사용한다는 것을 알 수 있습니다.
validation.xml 구성

validation.xml 파일은 Form Bean에 적용해야 하는 검증 집합을 선언하는 데 사용됩니다. 검증할 각 Form Bean은 이 파일에 고유한 정의를 가집니다. 해당 정의 내에서 개발자는 Form Bean의 필드에 적용할 검증을 지정합니다. 다음은 검증이 정의되는 방법을 보여주는 예제 validation.xml 파일입니다.

PUBLIC "-//Apache Software Foundation//
DTD Commons Validator Rules
Configuration 1.0//EN"
"http://jakarta.apache.org/
commons/dtds/validator_1_0.dtd">




depends="required">


depends="required">




마스터 요소이며 한 번만 정의됩니다. form-validation 요소 내에서는 여러 form 요소를 캡슐화하는 form-set 요소를 정의합니다. 일반적으로 파일에서 form-set 요소를 한 번만 정의하지만 검증을 국제화하는 경우에는 각 로케일에 대해 별도의 요소를 사용합니다.

각 form 요소는 name 속성을 사용하여 둘러싼 필드 검증 집합과 이름을 연관시킵니다. Validator는 이 논리적 이름을 사용하여 struts-config.xml 파일에 정의된 Form Bean에 검증을 매핑합니다. 검증하는 Form Bean의 유형에 기초하여 Validator는 이 이름을 Form Bean의 논리적 이름이나 작업 경로에 일치시키려고 시도합니다. form 요소 내에서 field 요소는 지정된 Form Bean 필드에 적용할 검증을 정의합니다. field 요소의 property 속성은 지정된 Form Bean의 필드 이름에 해당합니다. depends 속성은 필드에 적용해야 하는 validator-rules.xml 파일의 검증 루틴에 대한 논리적 이름을 지정합니다.

ApplicationResources.properties 구성

Validator는 오류 메시지를 구체화하기 위해 Struts의 Resource Bundle 메커니즘을 사용합니다. 프레임워크에서 하드 코드화된 오류 메시지를 가지는 대신에 Validator를 사용하면 검증이 실패할 경우에 반환해야 하는 메시지에 대한 키를 ApplicationResources.properties 파일에 지정할 수 있습니다. validator-rules.xml 파일의 각 검증 루틴은 다음과 같이 validator 태그의 msg 속성을 사용하여 오류 메시지 키를 지정합니다.

classname="org.apache
.struts.validator.FieldChecks"
method="validateRequired"
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">

검증 실행이 실패할 경우 msg 속성에 의해 지정된 키에 해당하는 메시지가 반환됩니다.

다음 단편은 Struts 예제 애플리케이션과 함께 미리 패키지화되어 제공되는 ApplicationResources.properties 파일에 있는 검증 오류 메시지의 기본 집합을 보여줍니다. 각 메시지 키는 마찬가지로 Struts 예제 애플리케이션과 함께 미리 패키지화되어 제공되는 validator-rules.xml 파일의 검증 루틴에 의해 지정된 메시지 키에 해당합니다.

# Error messages for Validator framework validations
errors.required={0} is required.
errors.minlength={0} cannot be less than {1} characters.
errors.maxlength={0} cannot be greater than {2} characters.
errors.invalid={0} is invalid.
errors.byte={0} must be a byte.
errors.short={0} must be a short.
errors.integer={0} must be an integer.
errors.long={0} must be a long.0. errors.float={0} must be a float.
errors.double={0} must be a double.
errors.date={0} is not a date.
errors.range={0} is not in the range {1} through {2}.
errors.creditcard={0} is not a valid credit card number.
errors.email={0} is an invalid e-mail address.

각 메시지에 {0}, {1} 또는 {2} 형태의 위치 표시자가 있다는 것에 주의합니다. 런타임에 이러한 위치 표시자는 검증되는 필드 이름 같은 다른 값으로 대체됩니다. 이 기능은 특히 여러 다른 필드에 재사용할 수 있는 일반적인 검증 오류 메시지를 만들 때 유용합니다.
예를 들어, required 검증의 오류 메시지인 errors.required는 다음과 같습니다.

errors.required={0} is required.

validation.xml 파일에서 required 검증을 사용할 때는 다음과 같이 오류 메시지의 {0}을 대체하는 데 사용되는 값을 정의해야 합니다.





오류 메시지는 {0}에서 {3}까지 최대 네 개의 위치 표시자를 가질 수 있습니다. 이러한 위치 표시자는 각각 arg0에서 arg3으로 알려져 있으며 arg0 - arg3 태그를 사용하여 지정할 수 있습니다. 위 예제에서 arg0 태그는 {0} 위치 표시자를 대체하는 데 사용해야 하는 값을 지정합니다. 이 태그의 key 속성은 해당 값이 위치 표시자를 대체하는 데 사용되는 다음과 같은 ApplicationResources.properties 파일의 메시지 키를 지정합니다.

다음 단계

Validator에 대한 자세한 내용 읽기
jakarta.apache.org/commons/validator

Struts Console 추가 정보
www.jamesholmes.com/struts

prompt.bid=Auction Bid

위치 표시자 값에 메시지 키를 사용하면 validation.xml 파일에서 대체 값을 반복하여 하드 코드화할 필요가 없습니다. 그러나 위치 표시자 값을 지정하기 위한 Resource Bundle 키/값 메커니즘을 사용하지 않으려는 경우에는 다음 구문을 arg0 태그에 사용하여 위치 표시자 값을 명시적으로 지정할 수 있습니다.

이 예제에서 resource 속성이 false로 설정되므로 Validator는 key 속성으로 지정된 값을 ApplicationResources.properties 파일의 메시지에 대한 키가 아니라 리터럴 위치 표시자 값으로 간주합니다.

클라이언트측 검증 활성화

서버측 폼 데이타 검증을 단순화하기 위한 프레임워크를 제공하는 것 외에도 Validator는 클라이언트측 검증을 수행하기 위한 간편한 메커니즘을 제공합니다. validator-rules.xml 파일에 정의된 각 검증 루틴은 서버측에서 발생하는 검증과 동일한 검증을 수행하기 위해 브라우저에서(클라이언트측에서) 실행될 수 있는 JavaScript 코드를 선택적으로 지정합니다. 클라이언트측에서 실행될 경우 모든 검증에 성공할 때까지 폼을 제출하는 것이 허용되지 않습니다.

클라이언트측 검증을 활성화하려면 다음과 같이 Struts HTML 태그 라이브러리의 javascript 태그를 검증이 필요한 각 JSP에 두어야 합니다.

javascript 태그를 사용하려면 다음과 같이 formName 속성을 사용하여 검증을 수행할 폼 정의의 이름을 validation.xml 파일에서 지정해야 합니다.


depends="required">


depends="required">


서버측에서 실행할 폼 정의에 대해 지정한 모든 검증은 또한 클라이언트측에서도 실행됩니다. 클라이언트측 검증은 JavaScript를 사용하여 수행하기 때문에 이러한 검증을 실행하지 않는 방법이 있습니다. Validator는 검증이 항상 실행되도록 하기 위해 개발자가 클라이언트측 검증을 활성화했는지 여부에 상관 없이 서버측에서 검증을 수행합니다.

결론

Validator 프레임워크는 폼 데이타 검증을 적용하기 위한 구성 가능한 시스템을 제공함으로써 핵심 Struts 프레임워크의 가치를 훨씬 더 향상시킵니다. 개발자는 Validator 프레임워크를 애플리케이션과 함께 사용하여 시간을 절약하는 동시에 Struts 애플리케이션 개발을 단순화할 수 있습니다.

 

제공 : DB포탈사이트 DBguide.net