요약 : ASP+ Verification 웹 제어 사용에 대한 자세한 설명.
목차
간단한 소개
시작하기
언제 발생합니까?
서버 측의 확인 시퀀스
클라이언트 확인
효과적인 규칙 및 유용한 오류 정보
활성화, 가시 및 표시 속성 기능
CustomValidator 제어
어떤 컨트롤을 확인할 수 있습니까?
끝
-------------------------------------------- --------------------------------------------------------- -------------------------
간단한 소개
이 기사에서는 ASP+ Verification Control의 작업 방법을 자세히 설명합니다. 검증 컨트롤이 포함 된 복잡한 페이지를 생성하거나 검증 프레임 워크를 확장하려면이 기사를 읽는 것이 좋습니다. 검증 컨트롤을 사용하는 법을 배우거나 확인 제어를 사용할지 여부를 결정하려면 "ASP+ 사용자 입력 (영어)을 참조하십시오.
시작하기
전체 ASP+ 개발 프로세스에서 검증을 이해하는 것이 중요하다는 것을 알고 있습니다. 오늘날의 상업용 웹 사이트의 대부분을 살펴보면이 사이트에는 많은 양식이 있으며 많은 수많은 필기 코드를 실행하여 실행됩니다. 검증 코드 작성은 흥미로운 작업이 아닙니다. 데이터 테이블을 표시하거나 차트를 동적으로 생성하는 코드를 작성하는 경우 매우 매력적 일 수 있지만 동료와 함께이 "Cool"방법이 이름 필드의 빈 값을 금지 할 수 있음을 확인할 수는 없습니다.
다른 이유로, 웹 응용 프로그램의 확인도 매우 번거 롭습니다. HTML 3.2에는 사용자가 제어 할 수있는 컨텐츠 또는 사용자로부터 얻을 수있는 피드백에 대한 많은 제한 사항이 있으므로 사용자가 특정 문자 입력을 금지하는 등보다 충족하는 클라이언트에 사용할 수있는 기술에 적용 할 수 없습니다. 소리 만들기. 브라우저 스크립트를 사용하면보다 강력한 검증이 생성 될 수 있습니다. 그러나 고객의 브라우저가 반드시 스크립트가 아니며 악의적 인 사용자가이를 우회 할 수 있기 때문에이 방법은 확인하기가 어렵습니다. 따라서 사이트의 안전을 보장하려면 서버에 대한 동일한 검사를 수행해야합니다.
ASP+를 개발할 때, 우리의 원래 의도는 하나의 컨트롤 만 사용하여 검증을 처리하는 것입니다. 그러나 그것이 설계되었을 때, 나는이 욕망을 달성 할 수 없다는 것을 알았습니다. 우리는 가능한 한 많은 양식에 적용 할 수있는 솔루션을 찾기 위해 많은 수의 데이터 입력 양식을 연구했습니다. 데이터 입력 테이블에는 많은 흥미로운 기능이 있음을 발견했습니다.
오류 정보 나 아이콘이 종종 입력 요소에 인접 해 있지만 거의 항상 테이블의 다른 셀에 있습니다.
모든 오류를 요약 할 수있는 영역이 종종 있습니다.
많은 사이트에는 고객 스크립트가 포함되어있어 더 빠른 피드백을 제공하면서 서버 사이의 이동을 방지합니다.
클라이언트 스크립트가 포함 된 많은 사이트에는 오류가있을 때 정보 상자가 표시됩니다.
텍스트 입력을 확인할뿐만 아니라 Drop -Down 목록 및 단일 선택 버튼도 확인됩니다.
필드가 비어 있으면 사이트는 일반적으로 항목이 유효하지 않은 경우 다른 정보 나 아이콘을 보여줍니다.
많은 효과적인 시험은 일반적으로 사용되는 표현으로 잘 대체 될 수 있습니다.
검증은 일반적으로 두 입력 사이의 비교 결과를 기반으로합니다.
검증 작업의 90% 이상이 90% 이상이 확인 이름이나 우편 번호와 같은 일반적인 작업입니다. 대부분의 사이트는 여전히 이러한 작업을 반복하는 것 같습니다.
사이트 간의 차이가 일반적으로 너무 크기 때문에 각 사이트의 모든 검증 작업을 처리하기 위해 완벽한 솔루션을 얻을 수 없습니다.
위의 모든 상황을 고려하여 최종 솔루션에는 5 개의 검증 장치 컨트롤, 유효성 검사 서식 컨트롤 및 Page Objects와의 통합이 포함됩니다. 동시에 솔루션을 확장해야하며 클라이언트와 서버에서 협력하려면 API가 필요합니다.
우리는 다양한 연구 검증 중에 더 큰 도구 상자가 필요하다는 것을 알았습니다. Microsoft & Reg;와 같은 대부분의 구성 요소 환경에서는 모든 검증 컨트롤의 기능을 다른 모드에서 다른 속성을 처리하기 위해 컨트롤에 통합하려고 시도했을 수 있습니다. 다행스럽게도 Microsoft & Reg에는 마법의 상속이 있으며, 각각의 새로운 컨트롤에 필요한 추가 작업 부하가 매우 작기 때문에 특정 속성을 확인할 수 있습니다.
이러한 컨트롤의 대부분은 공개 부모 수준의베이스 볼리 디터에서 구현됩니다. BaseValidator 또는 기타 컨트롤에서 다양한 작업을 완료 할 수도 있습니다. 실제로, BaseValidator가 자체 텍스트 속성을 달성하기에는 너무 게으르더라도 레이블 속성에서 상속됩니다.
언제 발생합니까?
웹 컨트롤 페이지가 포함 된 페이지를 처리 할 때 이벤트 시퀀스를 이해하는 것이 매우 효과적입니다. 확인 조건이 선택 사항 인 경우 클라이언트와 서버가 확인되는시기를 정확하게 이해해야합니다. 검증 루틴을 직접 작성하려면 시간이 많이 걸리거나 부작용 일 수 있습니다. 동시에 호출 검증 루틴의시기를 이해하는 것도 중요합니다.
먼저 서버를 살펴 보겠습니다.
서버 측의 확인 시퀀스
페이지의 유효 기간을 이해하는 것이 중요합니다. Visual Basic 또는 유사한 기능적 클라이언트 도구에서 양식을 처리하는 데 익숙한 경우 이해하는 데 특정 시간을 소비해야합니다. 페이지와 페이지의 모든 객체는 사용자와 상호 작용할 때 효과적이지 않지만 때로는 동일합니다.
다음은 처음으로 페이지를 방문 할 때 단순화 된 이벤트 시퀀스입니다.
ASPX 파일을 기반으로 페이지와 제어를 만듭니다.
page_load 이벤트를 트리거합니다.
페이지 및 제어 속성은 숨겨진 필드에 저장됩니다.
페이지 및 컨트롤은 HTML로 변환됩니다.
모든 것을 버립니다.
이제 사용자가 버튼 또는 유사한 컨트롤을 클릭하면 서버로 돌아가서 유사한 이벤트 시퀀스를 실행합니다. 이 순서는 리턴 시퀀스라고합니다.
ASPX 파일을 기반으로 페이지와 제어를 만듭니다.
숨겨진 필드에서 페이지 및 제어 속성을 복원하십시오.
사용자에 따라 업데이트 페이지 제어를 입력하십시오.
page_load 이벤트를 트리거합니다.
변경 알림 이벤트를 트리거합니다.
페이지 및 제어 속성은 숨겨진 필드에 저장됩니다.
페이지 및 컨트롤은 HTML로 변환됩니다.
모든 것을 다시 버립니다.
모든 객체를 메모리에 유지하지 않는 이유는 무엇입니까? ASP+로 설정된 웹 사이트는 매우 많은 사용자를 처리 할 수 없기 때문입니다. 따라서 서버의 메모리는 즉시 처리 할 컨텐츠 만 보유합니다.
서버 -사이드 확인은 언제입니까? 처음으로 페이지 정보를 얻을 때 서버 -사이드 확인은 전혀 수행되지 않습니다. 대부분의 최종 사용자는 매우 심각합니다. 사용자는 양식에 채워진 정보가 올바른지 확인할 수 있습니다. 그런 다음 빨간색 텍스트를 사용하여 사용자에게 잘못된 정보를 작성하도록 알립니다.
반환 이벤트 시퀀스에서, 단계 3과 4 단계 사이에 검증이 수행됩니다. 다시 말해, 검증은 사용자의 데이터로드 컨트롤 속성 이후에 있지만 대부분의 코드 실행 수 이전입니다. 이것은 사용자 이벤트를 작성할 때 일반적으로 검증에 사용할 수 있음을 의미합니다. 정상적인 상황에서는이 작업을 원할 것입니다.
그 순간 확인의 단점은 다음과 같습니다. 프로그래밍을 통해 확인에 영향을 미치는 일부 속성을 수정하려면 너무 늦습니다. 예를 들어, 코드를 사용하여 확인 컨트롤의 속성을 활성화 또는 비활성화하거나 검증 컨트롤을 수정하면 페이지를 처리하기 전에 효과가 표시되지 않습니다. 이 문제는 다음 두 가지 방법을 통해 피할 수 있습니다.
확인 전에 속성을 수정하십시오.
속성 변경 후 제어를 다시 검토하십시오.
두 방법 모두 페이지 객체에서 효과적인 검증 속성과 메소드를 사용해야합니다.
페이지 API
페이지 객체에는 서버 -사이드 검증과 관련된 몇 가지 중요한 속성 및 메소드가 포함됩니다. 표 1은 이러한 속성과 방법을 요약합니다.
표 1. 페이지 객체의 속성 및 방법
속성 또는 메소드 설명
IsValid 속성이 가장 유용한 속성입니다. 이 속성은 전체 양식이 효과적인지 확인할 수 있습니다. 이 점검은 일반적으로 데이터베이스를 업데이트하기 전에 수행됩니다. 유효성 검사기의 모든 객체 만 유효하고 속성은 참이며 값은 캐시에 저장되지 않습니다.
유효성 검사기는이 페이지의 모든 검증 객체의 모음을 나타냅니다. 이것은 Ivalidator 인터페이스를 구현하는 객체 모음입니다.
값 메소드는 확인시 메소드를 호출합니다. 페이지 객체의 기본 실행 방법은 각 확인 장치로 돌리고 확인 장치가 자체를 평가하도록 요구하는 것입니다.
Validators Collection은 많은 작업에 매우 유용합니다. 이 세트는 Ivalidator 인터페이스를 구현하는 객체 모음입니다. 객체를 사용하는 이유는 페이지 객체가 Ivalidator 인터페이스에만주의를 기울이기 때문에 컨트롤 제어가 아닙니다. 모든 검증은 일반적으로 Ivalidator의 시각적 제어를 달성하는 데 사용되므로 누구나 검증 객체를 사용하고 확인 객체를 페이지에 추가 할 수 있어야합니다.
Ivalidator 인터페이스에는 다음 속성과 방법이 포함되어 있습니다.
표 2. Ivalidator 인터페이스의 속성 및 방법
속성 또는 메소드 설명
IsValid 속성은 별도의 검증 객체에 의해 수행 된 유효성 테스트가 통과되었는지 여부를 지적했습니다. 확인 후 값을 수동으로 변경할 수 있습니다.
errormessage 속성은 확인할 객체와 사용자에게 표시 될 수있는 오류를 확인하기 위해 오류를 도입합니다.
Valid 메소드는 isvalid 값을 업데이트하기 위해 확인 오브젝트의 유효성을 확인합니다.
이 인터페이스를 사용하여 몇 가지 흥미로운 작업을 수행 할 수 있습니다. 예를 들어, 페이지를 유효 상태로 재설정하려면 다음 코드 (예 : C#에 표시된 예)를 사용하십시오.
Ivalidator 값;
foreach (Val in Validators) {
ValueValid = true;
}
전체 확인 시퀀스를 다시 실행하려면 다음 코드를 사용하십시오.
Ivalidator 값;
foreach (Val in Validators) {
val.validate ();
}
베타 1 에디션 이상의 버전이있는 경우 동일한 작업을 완료 할 수 있도록 페이지 객체의 값 메소드 만 호출 할 수도 있습니다. 검증 전에 약간의 변경을 위해 값 방법을 다룰 수 있습니다. 이 예제는 확인 박스의 값에 따라 여력 장치가 포함 된 페이지를 보여줍니다.
공공 수업 조건부 : 페이지 {
공개 htmlinputcheckbox chksameas;
Public ResearchfieldValidator rfvalshipaddress;
보호 된 재정의 void validate () {) {)
// 배송 주소를 확인하십시오 (지불 주소와 다른 경우)
bool enableship =! Chksameas.Checked;
rfvalshipaddress.enabled = enableShip;
// 이제 확인을 실행합니다
base.validate ();
}
}
클라이언트 확인
클라이언트 확인에 의해 페이지가 활성화되면 왕복 중에 완전히 다른 이벤트 시퀀스가 발생합니다. 클라이언트의 확인은 클라이언트 jscript & reg를 사용합니다. 검증에는 이진 구성 요소가 필요하지 않습니다.
JScript 언어의 표준화는 잘 수행되었지만 브라우저 (DOM)의 HTML 문서에 사용되는 문서 객체 모델 (DOM)은 널리 사용 된 표준이 아닙니다. 따라서 클라이언트 확인은 인터넷 익스플로러 4.0 이상에서만 수행됩니다.
서버의 관점에서 클라이언트의 확인은 검증 컨트롤이 다른 컨텐츠를 HTML로 보낸다는 것을 의미합니다. 또한 입사 순서는 정확히 동일합니다. 서버 -사이드 점검은 여전히 수행됩니다. 중복되는 것처럼 보이지만 다음과 같이 매우 중요합니다.
일부 확인 컨트롤은 클라이언트 스크립트를 지원하지 않을 수 있습니다. 좋은 예가 있습니다. CustomValidator 및 서버 확인 기능을 동시에 사용하려는 경우 클라이언트 확인 기능이 없습니다.
안전 예방 조치. 어떤 사람들은 스크립트가 포함 된 페이지를 쉽게 얻은 다음 페이지를 비활성화하거나 변경할 수 있습니다. 잘못된 데이터가 시스템에 들어가는 것을 방지하기 위해 스크립트를 사용해서는 안되며 사용자가 더 빠른 피드백을받을 수 있도록해야합니다. 따라서 CustomValidator를 사용하려면 해당 서버 확인 기능없이 클라이언트 확인 기능을 제공해서는 안됩니다.
각 확인 컨트롤은 표준 클라이언트 스크립트 블록이 페이지로 전송되도록 할 수 있습니다. 실제로 이것은 코드의 작은 부분 일뿐입니다. 여기에는 스크립트 라이브러리 WebUivalidation.js의 코드에 대한 참조가 포함되어 있습니다. 이 스크립트 라이브러리 파일에는 클라이언트가 검증 한 모든 논리가 포함되어 있으며 브라우저 캐시에 저장 될 수 있습니다.
스크립트 라이브러리 정보
웹 제어 스크립트의 확인은 스크립트 라이브러리에 있으므로 모든 클라이언트가 확인한 코드는 표면에서 수행되는 것 같습니다. 기본 스크립트 파일 참조는 다음과 유사합니다.
<스크립트 언어 = JavaScript
src =/_ aspx/1.0.9999/script/webuivalidation.js> </script>
기본적으로 스크립트 파일은 _ASPX 디렉토리의 기본 루트 디렉토리에 설치되며 긍정적 인 대각선으로 시작하는 습자를 포함하는 스크립트를 사용합니다. 참조는 각 개별 객체에 스크립트 라이브러리를 포함 할 필요가 없으며 동일한 컴퓨터의 모든 페이지가 동일한 파일을 참조 할 수 있음을 보여줍니다. 이 경로에는 공개 언어 버전 번호가 있으므로 동일한 컴퓨터에서 다른 런타임 버전이 실행될 수 있습니다.
기본 가상 루트 디렉토리를 보면 파일을 찾아 내용을 보게됩니다. 이 파일의 위치는 config.web 파일에 지정되어 있습니다. config.web 파일은 대부분의 ASP+ 설정에 대한 XML 파일입니다. 다음은이 파일의 위치 정의입니다.
<WebControls
clientscripttSlocation =/_ aspx/{0}/script/
/>
심층적으로 발생하는 이벤트를 이해할 수 있도록 스크립트를 읽도록 권장하십시오. 그러나 함수는 특정 런타임 버전과 밀접하게 연결되어 있으므로 이러한 스크립트를 수정하지 않는 것이 좋습니다. 버전이 업데이트되면이 스크립트는 변경 사항을 포기하거나 작동하지 않는 문제에 직면해야 할 수도 있습니다. 특정 프로젝트를 변경 해야하는 경우 먼저이 스크립트를 백업 한 다음 프로젝트를 백업 파일로 가리 키십시오.이 파일의 위치를 대체하기 위해 개인 config.web 파일을 사용해야합니다. 문자열에 형식 명령어 {0}이 포함 된 경우 런타임 버전 번호를 대체 할 때 버전 번호가 지침을 대체합니다. 이 위치를 상대 참조 또는 절대 참조로 변경하는 것이 가장 좋습니다.
클라이언트 확인을 비활성화합니다
때로는 고객을 확인하고 싶지 않을 수도 있습니다. 입력 필드 수가 작 으면 클라이언트 확인이 그다지 유용하지 않을 수 있습니다. 결국, 매번 하나의 라운드 트립 서버가 필요한 논리가 있어야합니다. 클라이언트에 대한 동적 정보가 레이아웃에 부정적인 영향을 미칠 것임을 알 수 있습니다.
클라이언트 확인을 비활성화하려면 페이지 명령어 ClientTarget = DownLevel을 사용하십시오. 이 명령어는 ASPX 파일의 시작과 유사합니다.
< %@page language = c# clientTarget = 다운 레벨 %>
이 명령어의 기본값은 자동이므로 Microsoft Internet Explorer 4.0 이상의 클라이언트 만 확인할 수 있습니다.
참고 : 불행히도, 베타 1에서는이 명령어가 검증을 위해 비활성화되지 않았으며 동시에 모든 웹 컨트롤은 HTML 3.2 태그를 사용하여 프로세스를 사용하여 예기치 않은 결과를 얻을 수 있습니다. 최종 버전은이 문제를 제어하는 더 나은 방법을 제공합니다.
클라이언트 이벤트 시퀀스
이 순서는 클라이언트 확인이 포함 된 페이지가 다음과 같은 이벤트 시퀀스입니다.
페이지에 브라우저를로드 할 때는 각 확인 제어를 초기화해야합니다. 이러한 컨트롤은 <Span> 마크로 전송되며 HTML 기능은 서버의 기능에 가장 가깝습니다. 가장 중요한 것은 검증 장치에서 참조하는 모든 입력 요소가 현재 "교수형"됩니다. 참조 된 입력 요소는 클라이언트 이벤트를 수정하여 변경을 입력 할 때 확인 루틴을 호출합니다.
스크립트 라이브러리의 코드는 사용자가 탭 키를 사용하여 각 필드간에 전환하면 실행됩니다. 특정 독립 필드가 변경되면 검증 조건이 다시 평가되고 검증 장치가 필요에 따라 보이지 않거나 보이지 않습니다.
사용자가 양식을 제출하려고하면 모든 검증이 평가됩니다. 이러한 모든 verificationR이 효과적이면 양식이 서버에 제출됩니다. 하나 이상의 장소에 오류가있는 경우 다음 상황이 발생합니다.
제출물이 취소되었습니다. 양식은 서버에 제출되지 않습니다.
모든 잘못된 검증이 보입니다.
확인 요약에 showSummary = true가 포함 된 경우 확인 제어의 모든 오류가 수집되고 이러한 오류로 컨텐츠가 업데이트됩니다.
확인 요약에 ShowMessageBox = true가 포함 된 경우 오류를 수집하고 클라이언트 정보 상자에 이러한 오류가 표시됩니다.
클라이언트 확인 제어는 각 입력 변경에서 클라이언트 확인 컨트롤이 수행되거나 제출시 수행되므로 이러한 검증 제어는 일반적으로 클라이언트에서 두 번 이상 평가됩니다. 제출 후 이러한 검증 제어는 서버에서 여전히 다시 평가됩니다.
클라이언트 API
클라이언트에 사용할 수있는 작은 API가 있습니다. 클라이언트 코드에서 다양한 효과를 달성합니다. 일부 루틴은 숨길 수 없으므로 이론적으로 클라이언트를 사용하여 클라이언트가 정의한 모든 변수, 특성 및 기능을 확인할 수 있습니다. 그러나 많은 사람들이 변경 될 수 있습니다. 다음은 사용하도록 권장하는 클라이언트 객체를 요약합니다.
표 3. 클라이언트 객체
이름 유형 설명
page_isvalid boolean 변수 페이지가 현재 유효한 지 여부를 지적했습니다. 스크립트 확인 스크립트는 항상 변수를 최신 상태로 유지합니다.
page_validator 요소 배열 이것은 페이지의 모든 검증을 포함하는 배열입니다.
page_validationActive 부울 변수는 확인 해야하는지 여부를 나타냅니다. 이 변수를 False로 설정하면 프로그래밍을 통해 예정 될 수 있습니다.
IsValid Boolen 속성 각 클라이언트 검증 장치에는 속성이 있는데, 검증 장치가 현재 유효한지 여부를 지적합니다. PDC 버전 에서이 속성은 isvalid와 혼합되어 있습니다.
클라이언트 확인 우회
실행 해야하는 한 가지 작업 중 하나는 페이지에 "취소"버튼 또는 탐색 버튼을 추가하는 것입니다. 이 경우 페이지에 오류가 있더라도 버튼을 사용하여 페이지를 제출할 수도 있습니다. 클라이언트 버튼 ONCLICK 이벤트는 양식의 OnSubmit 이벤트 전에 발생하므로 검사를 제출하고 확인을 우회하지 않을 수 있습니다. 다음은 HTML 이미지 컨트롤을 "취소"버튼으로 사용하여 작업을 완료하는 방법을 보여줍니다.
<입력 유형 = 이미지 runat = 서버
값 = 취소
onclick = page_validationActive = false;
onserverclight = cmdcancel_click>
OnClick 이벤트는 동일한 이름의 서버 -사이드 이벤트라고 가정하기 때문에 버튼 또는 ImageButton 컨트롤을 사용하여 혼란을 실행하십시오. 이 이벤트를 클라이언트 스크립트에서 설정해야합니다.
<ASP : ImageButton runat = Server ID = CMDIMGCANCEL
Alternatetext = 취소
onclick = cmdcancel_click/>
<스크립트 언어 = javaScript>
문서. ALL [CMDIMGCANCEL] .ONCLICK =
새 함수 (page_validationActive = false;);
</스크립트>
이 문제를 해결하는 또 다른 방법은 "취소"버튼의 특정 설정을 설정하여 리턴 할 때 클라이언트 스크립트에서 제출 이벤트를 트리거하지 않도록하는 것입니다. Htmlinputbutton 및 LinkButton 컨트롤이 예입니다.
특수 효과
또 다른 일반적인 요구 사항은 검증 장치 자체에 표시되는 오류 정보 외에도 다른 효과가 필요하다는 것입니다. 이 경우 서버 또는 클라이언트에서 동시에 수행해야합니다. 입력이 유효한지 여부에 따라 색상을 변경하기 위해 레이블을 추가해야한다고 가정하십시오. 다음은 서버 에서이 작업을 구현하는 방법입니다.
공개 클래스 changecolorpage : page {
공개 레이블 LBLZIP;
공개 regulaxpressionvalidator 값;
보호 된 재정의 void Overoad (EventArgs e) {{
lblzip.forecolor = valzip.isvalid? black : color.red;
}
}
위의 모든 방법은 완벽하지만 위의 검증을 수정하는 한 클라이언트에서 동일한 작업을 수행하지 않으면 매우 일관성이없는 것으로 보입니다. 검증 프레임 워크를 사용하면 이러한 많은 이중 효과를 피할 수 있지만 클라이언트와 서버에서 동시에 달성 해야하는 다른 효과를 피할 수는 없습니다. 다음은 클라이언트에서 동일한 작업을 수행하는 조각입니다.
<ASP : 레이블 ID = lblzip runat = 서버입니다
텍스트 = 우편 번호 :/>
<asp : textbox id = txtzip runat = 서버입니다
onchange = txtziponchange ();
<asp : exeralxpressionvalididator id = valzip runat = server
ControlTovalIdate = txtzip
errormessage = 유효하지 않은 우편 번호
validationxpression = [0-9] {5} /> <br>
<스크립트 언어 = javaScript>
함수 txtziponchange () {{) {
// 클라이언트 확인이 활동에 있지 않으면 작업이 수행되지 않습니다.
ifof (page_validators) == 정의되지 않은) 반환;
// 레이블의 색상을 변경합니다
lblzip.style.color = valzip.isvalid?
}
</스크립트>
베타 1 클라이언트 API
베타 1 판의 경우 클라이언트 스크립트에서 호출 할 수있는 일부 기능으로 인해 다른 상황이 발생합니다.
표 4. 클라이언트 스크립트 호출의 기능
이름 설명
ValidatorValidate (VAL)는 클라이언트 검증 장치를 입력으로 사용합니다. 검증 장치가 입력을 확인하고 디스플레이를 업데이트하십시오.
ValidatorEnable (Val, enable) 클라이언트 검증 장치와 부울 값을 얻습니다. 클라이언트 확인 장치를 활성화 또는 비활성화합니다. 비활성화 된 경우 클라이언트 확인 장치는 평가되지 않으며 클라이언트 유효성 검사기는 항상 유효합니다.
ValidatorHookUpControl (Control, Val)은 입력 HTML 요소 및 클라이언트 검증 장치를 얻었습니다. 변경 중에 검증 장치를 업데이트 할 수 있도록 요소의 변경 이벤트를 수정하거나 작성하십시오. 이 기능은 여러 입력 값을 기반으로 사용자 정의 검증에 적합합니다.
특별한 목적은 검증 장치를 활성화하거나 비활성화하는 것입니다. 특정 상황에서만 적용되는지 확인하려면 서버 및 클라이언트에서 동시에 활성화 상태를 변경해야 할 수도 있습니다. 그렇지 않으면 사용자가 페이지를 제출할 수 없다는 것을 알 수 있습니다.
다음은 위의 예제와 필드입니다.이 필드는 확인란의 선택이 취소 된 경우에만 확인됩니다.
공공 수업 조건부 : 페이지 {
공개 htmlinputcheckbox chksameas;
Public ResearchfieldValidator rfvalshipaddress;
보호 된 재정의 void validate () {) {)
bool enableship =! Chksameas.Checked;
rfvalshipaddress.enabled = enableShip;
base.validate ();
}
}
다음은 클라이언트의 코드입니다.
<입력 유형 = checkbox runat = Server id = chksameas
onclick = onchangesameas ();> 지불 주소와 동일합니다 <br>
<스크립트 언어 = javaScript>
함수 onchangesameas () {
var entleship =! srcelement.status;
validatorenable (rfvalshipaddress, enableShip);
}
</스크립트>
효과적인 규칙 및 유용한 오류 정보
각 검증 장치는 특정 제어의 특정 조건에 대한 특정 오류 정보를 보여줍니다. 처음에는 유효한 지 여부를 확인하는 몇 가지 규칙이 있습니다. 사용자에게 실제 도움말로 오류 정보를 생성하려면 이러한 규칙이 필요합니다.
모든 빈 검증 (필수 필드 밸리 디터 제외)은 유효한 것으로 간주됩니다. 빈 값이 유효하지 않은 경우 일반적으로 필수 필드 바리 디터와 다른 검증자가 필요합니다. 일반적으로 빈 검증 장치 및 효과에 대한 다른 오류 정보를 항상 표시하려고하므로이를 수행해야합니다. "값을 입력해야 하며이 값은 1에서 10 사이 여야합니다"와 같은 명확한 정보를 사용할 수도 있습니다.
입력 필드를 지정된 데이터 유형으로 변환 할 수없는 경우 사용되는 또 다른 특수 규칙은 CompareValidator 및 RangeValidator와 관련이 있습니다. ControlToCompare의 비교 측정기의 유효성 평가 프로세스는 유효성 평가 프로세스를 지정합니다.
ControlTovalidate에 의해 참조 된 입력 필드가 비어 있으면 효과적입니다.
ControlTovalidate에 의해 참조 된 입력 필드를 필요한 데이터 유형으로 변환 할 수없는 경우 유효하지 않습니다.
ControlToCompare에서 참조 된 입력 필드를 필요한 데이터 유형으로 변환 할 수없는 경우 유효합니다.
입력 필드는 필요한 데이터 유형으로 변환되며 비교됩니다.
세 번째 단계는 약간 일관성이없는 것처럼 보입니다. 그 이유는 검증 장치가 여러 필드의 효과를 동시에 확인하면 검증 장치에 대한 의미있는 오류 정보를 작성하기가 어렵 기 때문입니다. ControlToCompare 입력 필드의 오류 상황을보고하는 데 독립적 인 검증 장치를 사용해야합니다. RangeValidator는 최대 및 최소 특성을 갖는 비슷한 작업 방법을 가지고 있습니다.
활성화, 가시 및 표시 속성 기능
검증 장치의 활성화, 가시 및 디스플레이 특성의 차이는 그다지 분명하지 않을 수 있습니다.
display = none은 검증 장치가 컨텐츠를 직접 표시하지 않지만 여전히 평가하고 여전히 전체 효과에 영향을 미치며 클라이언트 및 서버 요약에 오류를 가질 수 있음을 지정하는 데 사용될 수 있습니다. 클라이언트 확인의 경우 이러한 값은 가시 스타일 특성을 사용하거나 디스플레이 스타일 특성을 사용하여 검증 장치를 열거 나 닫기로 결정됩니다. 서버 -사이드 검증의 경우 디스플레이 = 동적은 입력이 유효 할 때 컨텐츠가 표시되지 않으며 디스플레이 = 정적은 변경되지 않는 공간을 나타냅니다. 테이블의 검증 장치 만 포함 된 셀이 유효 할 때 마지막 설정은 콘텐츠로 접히는 것입니다.
Visive = False를 사용하여 검증 장치를 보이게하는 이유는 무엇입니까? ASP+에서 컨트롤의 가시 속성은 많은 의미를 갖습니다. 가시적 = 거짓의 제어는 전혀 처리되거나 표시되지 않습니다. 이 의미 때문에 검증 장치의 가시적 = false는 콘텐츠를 표시 할뿐만 아니라 사용할 수 없다는 것을 의미합니다. 이 검증 장치는 평가되지 않으며 페이지의 유효성에 영향을 미치지 않으며 초록에 넣지 않습니다.
활성화 된 것은 중립적입니다. 대부분의 경우 enabled = false 및 visible = false의 효과는 정확히 동일합니다. 베타 1 판 이상의 버전에서는 중요한 차이가 있습니다. 클라이언트 확인에서 비활성화 된 검증 장치는 여전히 브라우저로 전송되지만 장애인 상태에 있습니다. 클라이언트 스크립트에서 validatorenable 함수를 사용하여 확인 장치를 활성화 할 수 있습니다.
표시할지 여부를 제어하기 위해 표시되거나 활성화 된 경우 위 서버의 주문 순서에주의를 기울이십시오. 또는 확인 전에 변경하거나 변경 후 다시 검사하십시오. 그렇지 않으면, 그들의 isvalid 값은 속성에 대한 변화를 반영하지 않습니다.
CustomValidator 제어
검증 프레임 워크를 확장하는 가장 쉬운 방법은 CustomValidator 컨트롤을 사용하는 것입니다. 이 컨트롤은 다른 검증 컨트롤을 수행 할 수없는 검증을 수행하는 데 사용될 수 있지만 서버 (예 : 데이터베이스 또는 웹 서비스)의 정보에 액세스 해야하는 검증을 실행할 수도 있습니다.
서버 확인 기능이 하나만있는 CustomValidator가 추가되면 확인 장치가 클라이언트 확인에 참여하지 않음을 알 수 있습니다. 사용자가 탭 키로 각 필드를 전환하면 CustomValidator가 업데이트되지 않으며 Round -Trip 서버는 한 번에 확인을 수행해야합니다. CustomValidator를 사용하여 서버에 정보가 필요하지 않은 수표를 수행하려면 ClientValidationFunction 속성을 사용하여 검증 장치가 클라이언트 확인에 완전히 참여하도록 할 수도 있습니다. ClientValidationFunction은 서버 검증 처리 프로세스와 정확히 동일한 검사를 수행해야한다고 가정합니다. 그러나 실제로는 검증의 일부일뿐입니다. 해커가 확인 기능을 쉽게 우회 할 수 있기 때문에 클라이언트 확인 기능의 확인은 서버에서 실행 검증을 초과하지 않습니다.
다음은 클라이언트와 서버에서 CustomValidator를 사용하는 간단한 예입니다. 입력이 짝수 여부 만 확인하십시오. 서버 기능 (C#)을 소개하겠습니다.
{부분 서비스) {위치
노력하다 {
int i = int.fromString (값);
return ((i % 2) == 0);
} 잡다 {
거짓을 반환합니다.
}
}
다음은 클라이언트의 함수의 선언 방법과 동일한 점검을 수행하는 클라이언트 검증 기능입니다. 이것은 일반적으로 JScript 형식이지만 목표가 Microsoft & Reg;
<asp : customValidator id = customVal2 runat = Server
errormessage = 숫자를 제거 할 수 없습니다!
ControlTovalidate = TxtCustomData
onservalidationFunction = ServerValidation
ClientValidationFunction = Checkeven /> <br>
데이터 필드 : <asp : textbox id = txtcustosdata runat = server />
<스크립트 언어 = javaScript>
<!-
함수 checkeven (소스, 값) {{
var value = parseint (값, 10);
if (isnan (val))
거짓을 반환합니다.
return ((val % 2) == 0);
}
//->
</스크립트>
다음은 CustomValidator를 사용하는 몇 가지 예방 조치입니다.
다른 모든 검증 컨트롤 (필수 필드 발리 디터 제외)과 유사하게 입력 필드가 비어 있으면 CustomValidator가 효과적인 것으로 간주됩니다.
이전 브라우저가 사용되거나 클라이언트 확인이 닫히면 클라이언트 확인 기능을 호출 할 수 없습니다. 함수를 정의하기 전에 브라우저에 사용 된 브라우저의 기능을 확인할 필요는 없지만 브라우저가 정의로 인해 스크립트 오류가 발생하지 않도록해야합니다. 다음 예에서 볼 수 있듯이 클라이언트 코드를 HTML 주석으로 만들어야합니다.
두 매개 변수가 클라이언트 함수로 전달되며 서버 기능에 전달 된 매개 변수에 해당합니다. 첫 번째는 클라이언트 검증 장치 요소이고 두 번째는 ControlTovalidate에 의해 지정된 제어 값입니다. 그러나 클라이언트에서는 함수의 매개 변수를 정의하지 않도록 선택할 수 있으며, 이는 정상적으로 작동합니다.
Beta1 이상의 버전을 사용하는 경우 ControlTovalidate를 비어있을 수 있습니다. 이 모드에서 서버 기능은 항상 라운드 트립 왕복을 트리거하며 제출할 때마다 클라이언트 기능이 항상 트리거됩니다. 이 기능을 사용하여 CheckboxList 또는 별도의 라디오 버튼과 같은 다른 메소드가 확인할 수없는 컨트롤을 확인할 수 있습니다. 조건이 여러 컨트롤을 기반으로하고 페이지의 각 필드를 전환 할 때 조건을 평가하지 않으려면이 메소드를 사용할 수 있습니다.
베타 1 이상의 버전의 또 다른 옵션은 여러 컨트롤의 변경 이벤트입니다. 이 방법은 위에서 설명한대로 클라이언트 기능 validatorhookupcontrol이라고하는 임베디드 스크립트를 추가하는 것입니다.
어떤 컨트롤을 확인할 수 있습니까?
제어 기준에 의해 컨트롤을 확인할 수 있으려면 컨트롤에 속성이 확인되어야합니다.所有可以验证的控件均具有validationpropertyattribute 属性，该属性指明验证时应读取的属性。如果编写自己的控件，可以通过提供其中一个特性来指定要使用的属性，从而使该控件参与验证。
要使验证可以在客户端正常进行，该属性必须与客户端显示的html 元素的value 特性对应。许多复杂的控件（例如datagrid 和calendar）在客户端没有值，只能在服务器上进行验证。因此，只有最接近html 元素的控件才可以参与验证。此外，控件必须在客户端具有单个逻辑值。因此，radiobuttonlist 可以被验证，但是checkboxlist 不可以。
끝
上述对asp+ 验证的讲解可能已经超过了您要了解的内容。 즐기세요!
-------------------------------------------- --------------------------------------------------------- -------------------------
请以ie4.0 以上版本800 * 600 浏览本站
©2001 microsoft corporation 版权所有。 소유권을 유지하십시오.使用规定。
가장 실용적인 웹 페이지 특수 효과 코드를 수집하십시오!