ในคำอธิบายเชิงลึก ASP+ การตรวจสอบ

สรุป: คำอธิบายโดยละเอียดเกี่ยวกับการใช้การควบคุมเว็บการตรวจสอบ ASP+

สารบัญ

บทนำสั้น ๆ

เริ่มต้น

เกิดขึ้นเมื่อไหร่?

ลำดับการตรวจสอบทางฝั่งเซิร์ฟเวอร์

การยืนยันลูกค้า

กฎที่มีประสิทธิภาพและข้อมูลข้อผิดพลาดที่เป็นประโยชน์

ฟังก์ชั่นคุณสมบัติที่เปิดใช้งานมองเห็นและแสดงผล

การควบคุม customvalidator

การควบคุมใดที่สามารถตรวจสอบได้?

จบ

----------------------------------------------- ---------------------------------------------------------- ------------------------

บทนำสั้น ๆ

บทความนี้อธิบายวิธีการทำงานของการควบคุมการตรวจสอบ ASP+ โดยละเอียด หากคุณต้องการสร้างหน้าซับซ้อนที่มีการควบคุมการตรวจสอบหรือเพื่อขยายกรอบการตรวจสอบขอแนะนำให้คุณอ่านบทความนี้ หากคุณต้องการเรียนรู้ที่จะใช้การควบคุมการตรวจสอบหรือตัดสินใจว่าจะใช้การควบคุมการตรวจสอบให้ดู "ASP+ ผู้ใช้ป้อนการยืนยัน (ภาษาอังกฤษ)"

เริ่มต้น

เรารู้ว่ามันเป็นสิ่งสำคัญที่จะต้องเข้าใจการตรวจสอบในระหว่างกระบวนการพัฒนา ASP+ ทั้งหมด ดูเว็บไซต์เชิงพาณิชย์ส่วนใหญ่ของวันนี้คุณจะพบว่ามีหลายรูปแบบในเว็บไซต์เหล่านี้ซึ่งชัดเจนโดยการดำเนินการโค้ดที่เขียนด้วยลายมือจำนวนมาก การเขียนรหัสการยืนยันไม่ใช่งานที่น่าสนใจ หากคุณเขียนโค้ดเพื่อแสดงตารางข้อมูลหรือสร้างแผนภูมิแบบไดนามิกมันอาจน่าสนใจมาก แต่ไม่มีใครสามารถยืนยันกับเพื่อนร่วมงานของเขาได้ว่าวิธี "เจ๋ง" นี้สามารถห้ามค่าที่ว่างเปล่าในฟิลด์ชื่อ

ด้วยเหตุผลอื่นการตรวจสอบเว็บแอปพลิเคชันก็ลำบากเช่นกัน HTML 3.2 มีข้อ จำกัด มากมายเกี่ยวกับเนื้อหาที่คุณสามารถควบคุมหรือข้อเสนอแนะที่คุณสามารถได้รับจากผู้ใช้ดังนั้นจึงไม่สามารถนำไปใช้กับเทคนิคที่สามารถใช้กับไคลเอนต์ที่เติมเต็มได้มากขึ้นเช่นห้ามมิให้ผู้ใช้ป้อนอักขระบางตัวหรือ ทำเสียง การใช้สคริปต์เบราว์เซอร์อาจสร้างการตรวจสอบที่มีประสิทธิภาพมากขึ้น อย่างไรก็ตามวิธีนี้เป็นการยากที่จะยืนยันเนื่องจากเบราว์เซอร์ของลูกค้าไม่จำเป็นต้องเป็นสคริปต์และผู้ใช้ที่เป็นอันตรายสามารถข้ามได้ ดังนั้นเพื่อให้แน่ใจว่าความปลอดภัยของเว็บไซต์จำเป็นต้องทำการตรวจสอบเซิร์ฟเวอร์เดียวกัน

เมื่อพัฒนา ASP+ความตั้งใจดั้งเดิมของเราคือการใช้การควบคุมเพียงครั้งเดียวในการตรวจสอบกระบวนการ แต่เมื่อได้รับการออกแบบฉันพบว่าความปรารถนานี้ไม่สามารถทำได้ เราได้ทำการวิจัยแบบฟอร์มการป้อนข้อมูลข้อมูลจำนวนมากเพื่อค้นหาวิธีแก้ปัญหาที่สามารถนำไปใช้กับรูปแบบได้มากที่สุด เราพบว่าตารางข้อมูลอินพุตมีคุณสมบัติที่น่าสนใจมากมาย:

แม้ว่าข้อมูลข้อผิดพลาดหรือไอคอนมักจะอยู่ติดกับองค์ประกอบอินพุต แต่ก็มักจะอยู่ในเซลล์ที่แตกต่างกันของตาราง

มักจะมีพื้นที่ในหน้าเพื่อสรุปข้อผิดพลาดทั้งหมด

เว็บไซต์จำนวนมากรวมถึงสคริปต์ไคลเอนต์เพื่อให้ข้อเสนอแนะที่เร็วขึ้นในขณะที่ป้องกันการเดินทางระหว่างเซิร์ฟเวอร์โดยไร้ประโยชน์

เว็บไซต์จำนวนมากที่มีสคริปต์ไคลเอ็นต์แสดงกล่องข้อมูลเมื่อมีข้อผิดพลาด

ไม่เพียง แต่จะมีการตรวจสอบอินพุตข้อความเท่านั้น แต่ยังมีการตรวจสอบรายการดรอปดาวน์และปุ่มเลือกเดียว

หากฟิลด์ว่างเปล่าเว็บไซต์มักจะแสดงข้อมูลหรือไอคอนที่แตกต่างกันเมื่อรายการไม่ถูกต้อง

การตรวจสอบที่มีประสิทธิภาพจำนวนมากสามารถแทนที่ได้อย่างดีด้วยการแสดงออกที่ใช้กันทั่วไป

การตรวจสอบมักจะขึ้นอยู่กับผลการเปรียบเทียบระหว่างอินพุตสองอินพุต

90% หรือมากกว่า 90% ของงานตรวจสอบเป็นการดำเนินการทั่วไปบางอย่างเช่นการตรวจสอบชื่อหรือรหัสไปรษณีย์ เว็บไซต์ส่วนใหญ่ยังคงดูเหมือนจะทำซ้ำงานเหล่านี้

เนื่องจากความแตกต่างระหว่างไซต์มักจะมีขนาดใหญ่เกินไปจึงไม่สามารถหาทางออกที่สมบูรณ์แบบเพื่อจัดการงานการตรวจสอบทั้งหมดของแต่ละไซต์

เมื่อพิจารณาถึงสถานการณ์ทั้งหมดข้างต้นโซลูชั่นขั้นสุดท้ายรวมถึงการควบคุมอุปกรณ์การตรวจสอบห้าแบบการควบคุมการตรวจสอบความถูกต้องและการรวมเข้ากับวัตถุหน้า ในขณะเดียวกันก็เห็นได้ชัดว่าต้องมีการขยายโซลูชันและจำเป็นต้องมี API เพื่อร่วมมือกับไคลเอนต์และเซิร์ฟเวอร์

เราพบว่าเราต้องการกล่องเครื่องมือขนาดใหญ่ในระหว่างการตรวจสอบการวิจัยต่างๆ ในสภาพแวดล้อมส่วนใหญ่เช่น Microsoft & reg; โชคดีที่มีมรดกที่มีมนต์ขลังใน Microsoft & Reg;

การควบคุมเหล่านี้ส่วนใหญ่จะถูกนำไปใช้ในผู้ปกครองระดับสาธารณะ -ระดับ basevalidator นอกจากนี้คุณยังสามารถทำงานต่าง ๆ จาก basevalidator หรือการควบคุมอื่น ๆ ในความเป็นจริงแม้ว่า basevalidator จะขี้เกียจเกินไปที่จะบรรลุคุณลักษณะข้อความของตัวเอง แต่ก็สืบทอดมาจากแอตทริบิวต์ฉลาก

เกิดขึ้นเมื่อไหร่?

มันมีประสิทธิภาพมากที่จะเข้าใจลำดับเหตุการณ์เมื่อประมวลผลหน้าเว็บที่มีหน้าของการควบคุมเว็บ หากเงื่อนไขการตรวจสอบเป็นทางเลือกคุณต้องเข้าใจอย่างถูกต้องเมื่อไคลเอนต์และเซิร์ฟเวอร์ได้รับการตรวจสอบ หากคุณต้องการเขียนกิจวัตรการตรวจสอบด้วยตัวคุณเองอาจเป็นเวลาที่ต้องใช้เวลามากหรือผลข้างเคียง ในขณะเดียวกันก็เป็นสิ่งสำคัญที่จะต้องเข้าใจเวลาของการตรวจสอบการตรวจสอบ

ก่อนอื่นมาดูเซิร์ฟเวอร์

ลำดับการตรวจสอบทางฝั่งเซิร์ฟเวอร์

สิ่งสำคัญคือต้องเข้าใจระยะเวลาที่ถูกต้องของหน้า หากคุณคุ้นเคยกับการประมวลผลแบบฟอร์มในเครื่องมือ Visual Basic หรือเครื่องมือไคลเอนต์ที่ใช้งานได้คล้ายกันคุณต้องใช้เวลาในการทำความเข้าใจ วัตถุทั้งหมดในหน้าและหน้าไม่มีประสิทธิภาพเมื่อมีปฏิสัมพันธ์กับผู้ใช้แม้ว่าบางครั้งจะเหมือนกัน

ต่อไปนี้เป็นลำดับเหตุการณ์ที่ง่ายขึ้นเมื่อเยี่ยมชมหน้าเป็นครั้งแรก:

สร้างหน้าและการควบคุมตามไฟล์ ASPX

ทริกเกอร์เหตุการณ์ page_load

แอตทริบิวต์หน้าและการควบคุมจะถูกเก็บไว้ในฟิลด์ที่ซ่อนอยู่

หน้าและการควบคุมจะถูกแปลงเป็น HTML

ทิ้งทุกอย่าง

ตอนนี้เมื่อผู้ใช้คลิกปุ่มหรือตัวควบคุมที่คล้ายกันมันจะกลับไปที่เซิร์ฟเวอร์แล้วเรียกใช้ลำดับเหตุการณ์ที่คล้ายกัน ลำดับนี้เรียกว่าลำดับการส่งคืน:

สร้างหน้าและการควบคุมตามไฟล์ ASPX

กู้คืนหน้าและแอตทริบิวต์ควบคุมจากฟิลด์ที่ซ่อนอยู่

ป้อนการควบคุมหน้าอัปเดตตามผู้ใช้

ทริกเกอร์เหตุการณ์ page_load

ทริกเกอร์การเปลี่ยนแปลงเหตุการณ์การแจ้งเตือน

แอตทริบิวต์หน้าและการควบคุมจะถูกเก็บไว้ในฟิลด์ที่ซ่อนอยู่

หน้าและการควบคุมจะถูกแปลงเป็น HTML

ทิ้งทุกอย่างอีกครั้ง

ทำไมเราไม่เก็บวัตถุทั้งหมดไว้ในหน่วยความจำ? เนื่องจากเว็บไซต์ที่สร้างขึ้นด้วย ASP+ ไม่สามารถจัดการผู้ใช้จำนวนมากได้ ดังนั้นหน่วยความจำของเซิร์ฟเวอร์จะเก็บเนื้อหาที่จะประมวลผลทันที

การตรวจสอบเซิร์ฟเวอร์ -ด้านข้างคือเมื่อใด เมื่อได้รับข้อมูลหน้าเป็นครั้งแรกการตรวจสอบด้านข้างของเซิร์ฟเวอร์จะไม่ถูกดำเนินการเลย ผู้ใช้ปลายทางส่วนใหญ่จริงจังมาก

ในลำดับเหตุการณ์ส่งคืนการตรวจสอบจะดำเนินการระหว่างขั้นตอนที่ 3 และขั้นตอนที่ 4 กล่าวอีกนัยหนึ่งการตรวจสอบคือหลังจากแอตทริบิวต์การควบคุมข้อมูลการโหลดจากผู้ใช้ แต่ก่อนที่จำนวนการดำเนินการรหัสส่วนใหญ่ ซึ่งหมายความว่าเมื่อเขียนเหตุการณ์ผู้ใช้มักจะสามารถใช้สำหรับการตรวจสอบ ภายใต้สถานการณ์ปกติคุณจะต้องทำสิ่งนี้

ข้อเสียของการตรวจสอบในขณะนั้นคือ: หากคุณต้องการแก้ไขคุณลักษณะบางอย่างที่ส่งผลกระทบต่อการตรวจสอบโดยการเขียนโปรแกรมมันจะสายเกินไป ตัวอย่างเช่นคุณจะพบว่าหากคุณใช้รหัสเพื่อเปิดใช้งานหรือปิดใช้งานแอตทริบิวต์ของการควบคุมการตรวจสอบหรือแก้ไขการควบคุมการตรวจสอบคุณจะไม่เห็นผลกระทบใด ๆ ก่อนที่จะประมวลผลหน้า ปัญหานี้สามารถหลีกเลี่ยงได้ด้วยวิธีการสองวิธีต่อไปนี้:

แก้ไขแอตทริบิวต์ก่อนการตรวจสอบ

re -verify การควบคุมหลังจากการเปลี่ยนแปลงแอตทริบิวต์

ทั้งสองวิธีต้องใช้แอตทริบิวต์การตรวจสอบที่มีประสิทธิภาพและวิธีการบนวัตถุหน้า

หน้า API

วัตถุหน้ารวมคุณลักษณะที่สำคัญและวิธีการที่เกี่ยวข้องกับการตรวจสอบของเซิร์ฟเวอร์ ตารางที่ 1 สรุปคุณลักษณะและวิธีการเหล่านี้:

ตารางที่ 1. แอตทริบิวต์และวิธีการของ Object Page

คำอธิบายแอตทริบิวต์หรือวิธีการ

แอตทริบิวต์ isvalid เป็นแอตทริบิวต์ที่มีประโยชน์ที่สุด แอตทริบิวต์นี้สามารถตรวจสอบว่าแบบฟอร์มทั้งหมดมีประสิทธิภาพหรือไม่ การตรวจสอบนี้มักจะดำเนินการก่อนอัปเดตฐานข้อมูล เฉพาะวัตถุทั้งหมดของตัวตรวจสอบที่ถูกต้องแอตทริบิวต์เป็นจริงและค่าไม่ได้ถูกเก็บไว้ในแคช

ผู้ตรวจสอบคุณสมบัติการรวบรวมวัตถุการตรวจสอบทั้งหมดของหน้านี้ นี่คือคอลเลกชันของวัตถุที่ใช้อินเตอร์เฟส ivalidator

วิธีการค่าเรียกใช้วิธีการเมื่อตรวจสอบ วิธีการดำเนินการเริ่มต้นบนวัตถุหน้าคือการหันไปใช้อุปกรณ์ตรวจสอบแต่ละตัวและต้องการอุปกรณ์ตรวจสอบเพื่อประเมินตัวเอง

คอลเลกชันการตรวจสอบความถูกต้องมีประโยชน์มากสำหรับงานมากมาย ชุดนี้เป็นชุดของวัตถุที่ใช้อินเตอร์เฟส ivalidator เหตุผลที่ฉันใช้วัตถุนั้นไม่ใช่การควบคุมของการควบคุมเนื่องจากวัตถุหน้าจะให้ความสนใจกับอินเทอร์เฟซ ivalidator เท่านั้น เนื่องจากการตรวจสอบทั้งหมดมักจะใช้เพื่อให้ได้การควบคุมภาพของ ivalidator บางคนควรสามารถใช้วัตถุการตรวจสอบใด ๆ และเพิ่มวัตถุการตรวจสอบลงในหน้า

อินเตอร์เฟส ivalidator มีแอตทริบิวต์และวิธีการต่อไปนี้:

ตารางที่ 2. แอตทริบิวต์และวิธีการของอินเตอร์เฟส ivalidator

คำอธิบายแอตทริบิวต์หรือวิธีการ

แอตทริบิวต์ isvalid ชี้ให้เห็นว่าการทดสอบความถูกต้องที่ดำเนินการโดยวัตถุการตรวจสอบแยกต่างหากผ่านไปหรือไม่ คุณสามารถเปลี่ยนค่าด้วยตนเองหลังจากการตรวจสอบ

แอตทริบิวต์ ErrorMessage แนะนำข้อผิดพลาดในการตรวจสอบวัตถุที่จะตรวจสอบและข้อผิดพลาดที่อาจแสดงต่อผู้ใช้

วิธีการตรวจสอบความถูกต้องจะถูกตรวจสอบความถูกต้องของวัตถุการตรวจสอบเพื่ออัปเดตค่า isvalid

คุณสามารถใช้อินเทอร์เฟซนี้เพื่อทำงานที่น่าสนใจ ตัวอย่างเช่นในการรีเซ็ตหน้าเป็นสถานะที่มีประสิทธิภาพให้ใช้รหัสต่อไปนี้ (เช่นตัวอย่างที่แสดงใน C#):

ค่า ivalidator;

foreach (val ในตัวตรวจสอบ) {

valuevalid = true;

-

หากต้องการทำการตรวจสอบลำดับการตรวจสอบทั้งหมดให้ใช้รหัสต่อไปนี้:

ค่า ivalidator;

foreach (val ในตัวตรวจสอบ) {

val.validate ();

-

หากคุณมีรุ่นเบต้า 1 หรือรุ่นที่สูงกว่าคุณสามารถเรียกใช้วิธีการค่าสำหรับวัตถุหน้าเท่านั้นเพื่อให้งานเดียวกันเสร็จสมบูรณ์ เพื่อทำการเปลี่ยนแปลงบางอย่างก่อนการตรวจสอบวิธีการสามารถครอบคลุมได้ ตัวอย่างนี้แสดงหน้าเว็บที่มีอุปกรณ์ตรวจสอบซึ่งเปิดหรือปิดตามค่าของช่องทำเครื่องหมาย:

คลาสสาธารณะเงื่อนไข: หน้า {

public htmlinputcheckbox chksameas;

Public ResearchfieldValidator Rfvalshipaddress;

Void Void ที่ได้รับการป้องกันการตรวจสอบ () {) {)

// เพียงตรวจสอบที่อยู่จัดส่ง (หากแตกต่างจากที่อยู่การชำระเงิน)

bool enableship =!

rfvalshipaddress.enabled = enableship;

// ตอนนี้ดำเนินการตรวจสอบ

base.validate ();

-

-

การยืนยันลูกค้า

หากหน้าของคุณเปิดใช้งานโดยการตรวจสอบไคลเอนต์ลำดับเหตุการณ์ที่แตกต่างอย่างสิ้นเชิงจะเกิดขึ้นระหว่างการเดินทางไปกลับ การตรวจสอบของลูกค้าใช้ JScript & reg; การตรวจสอบไม่จำเป็นต้องมีส่วนประกอบไบนารีใด ๆ

แม้ว่ามาตรฐานของภาษา JScript นั้นทำได้ดี แต่โมเดลวัตถุเอกสาร (DOM) ที่ใช้ในเอกสาร HTML ในเบราว์เซอร์ (DOM) ไม่ได้ใช้มาตรฐานอย่างกว้างขวาง ดังนั้นการตรวจสอบลูกค้าจะดำเนินการเฉพาะใน Internet Explorer 4.0 และรุ่นที่สูงกว่าเนื่องจากวัตถุที่ได้รับการตรวจสอบคือ Internet Explorer DOM

จากมุมมองของเซิร์ฟเวอร์การตรวจสอบของไคลเอนต์หมายความว่าการควบคุมการตรวจสอบจะส่งเนื้อหาที่แตกต่างกันไปยัง HTML นอกจากนี้ลำดับเหตุการณ์ยังเหมือนกันทุกประการ การตรวจสอบของเซิร์ฟเวอร์ยังคงดำเนินการอยู่ แม้ว่ามันจะดูเหมือนซ้ำซ้อน แต่ก็สำคัญมากเพราะ:

การควบคุมการตรวจสอบบางอย่างอาจไม่รองรับสคริปต์ไคลเอนต์ มีตัวอย่างที่ดี: หากคุณต้องการใช้ฟังก์ชั่นการตรวจสอบ CustomValidator และเซิร์ฟเวอร์ในเวลาเดียวกัน แต่ไม่มีฟังก์ชั่นการตรวจสอบไคลเอนต์

ข้อควรระวังด้านความปลอดภัย บางคนสามารถรับหน้าเว็บที่มีสคริปต์ได้อย่างง่ายดายจากนั้นปิดการใช้งานหรือเปลี่ยนหน้า คุณไม่ควรใช้สคริปต์ของคุณเพื่อป้องกันไม่ให้ข้อมูลที่ไม่ดีเข้าสู่ระบบของคุณ แต่สำหรับผู้ใช้เท่านั้นที่จะได้รับข้อเสนอแนะที่เร็วขึ้น ดังนั้นหากคุณต้องการใช้ CustomValidator คุณไม่ควรให้ฟังก์ชั่นการตรวจสอบไคลเอนต์โดยไม่ต้องใช้ฟังก์ชั่นการตรวจสอบเซิร์ฟเวอร์ที่สอดคล้องกัน

การควบคุมการตรวจสอบแต่ละครั้งสามารถมั่นใจได้ว่าบล็อกสคริปต์ไคลเอนต์มาตรฐานจะถูกส่งไปยังหน้า ในความเป็นจริงนี่เป็นเพียงส่วนเล็ก ๆ ของรหัสซึ่งมีการอ้างอิงถึงรหัสในสคริปต์ไลบรารี webuivalidation.js ไฟล์ไลบรารีสคริปต์นี้มีตรรกะทั้งหมดที่ตรวจสอบโดยไคลเอนต์

เกี่ยวกับไลบรารีสคริปต์

เนื่องจากการตรวจสอบสคริปต์ควบคุมเว็บอยู่ในไลบรารีสคริปต์รหัสที่ตรวจสอบโดยลูกค้าทั้งหมดจึงไม่จำเป็นต้องส่งไปยังหน้าโดยตรงแม้ว่ามันจะดูเหมือนจะทำบนพื้นผิว การอ้างอิงไฟล์สคริปต์หลักคล้ายกับต่อไปนี้:

<ภาษาสคริปต์ = JavaScript

src =/_ aspx/1.0.9999/script/webuivalidation.js> </script>

โดยค่าเริ่มต้นไฟล์สคริปต์จะถูกติดตั้งในไดเรกทอรีรูทเริ่มต้นในไดเรกทอรี _aspx และใช้สคริปต์รวมคำสั่งที่จะเรียกซึ่งเริ่มต้นด้วยเส้นทแยงมุมบวก การอ้างอิงแสดงให้เห็นว่าวัตถุแต่ละชิ้นไม่จำเป็นต้องรวมไลบรารีสคริปต์และหน้าทั้งหมดในคอมพิวเตอร์เดียวกันสามารถอ้างอิงไฟล์เดียวกันได้ คุณจะสังเกตเห็นว่ายังมีหมายเลขเวอร์ชันภาษาสาธารณะในเส้นทางนี้เพื่อให้รุ่นรันไทม์ที่แตกต่างกันสามารถทำงานบนคอมพิวเตอร์เครื่องเดียวกันได้

หากคุณดูไดเรกทอรีรูทเสมือนจริงเริ่มต้นคุณจะพบไฟล์และดูเนื้อหา ตำแหน่งของไฟล์เหล่านี้ระบุไว้ในไฟล์ config.web ไฟล์ config.web เป็นไฟล์ XML สำหรับการตั้งค่า ASP+ ส่วนใหญ่ ต่อไปนี้เป็นคำจำกัดความของตำแหน่งในไฟล์นี้:

<WebControls

clientsCriptSlocation =/_ aspx/{0}/สคริปต์/

-

กระตุ้นให้คุณอ่านสคริปต์เพื่อให้คุณสามารถเข้าใจเหตุการณ์ที่เกิดขึ้นในเชิงลึก อย่างไรก็ตามขอแนะนำให้คุณไม่แก้ไขสคริปต์เหล่านี้เนื่องจากฟังก์ชั่นของพวกเขาเชื่อมโยงอย่างใกล้ชิดกับเวอร์ชันรันไทม์เฉพาะ เมื่อมีการอัปเดตเวอร์ชันสคริปต์เหล่านี้อาจต้องได้รับการปรับปรุงตามนั้น หากโครงการเฉพาะต้องมีการเปลี่ยนแปลงก่อนอื่นให้สำรองข้อมูลสคริปต์เหล่านี้แล้วชี้โครงการของคุณไปยังไฟล์สำรองข้อมูลวิธีการคือใช้ไฟล์ config.web ส่วนตัวเพื่อแทนที่ตำแหน่งของไฟล์เหล่านี้ หากสตริงมีคำสั่งรูปแบบ {0} หมายเลขเวอร์ชันจะแทนที่คำสั่งเมื่อหมายเลขเวอร์ชันรันไทม์จะถูกแทนที่ เป็นการดีที่สุดที่จะเปลี่ยนตำแหน่งนี้เป็นการอ้างอิงที่สัมพันธ์กันหรือการอ้างอิงแบบสัมบูรณ์

ปิดใช้งานการตรวจสอบลูกค้า

บางครั้งคุณอาจไม่ต้องการยืนยันลูกค้า หากจำนวนฟิลด์อินพุตมีขนาดเล็กการตรวจสอบไคลเอนต์อาจไม่เป็นประโยชน์มาก ท้ายที่สุดคุณต้องมีตรรกะที่ต้องใช้เซิร์ฟเวอร์รอบหนึ่งรอบทุกครั้ง คุณจะพบว่าข้อมูลแบบไดนามิกของลูกค้าจะมีผลกระทบด้านลบต่อเค้าโครงของคุณ

ในการปิดใช้งานการตรวจสอบไคลเอนต์ให้ใช้ clienttarget คำสั่งหน้า = downlevel คำสั่งนี้คล้ายกับจุดเริ่มต้นของไฟล์ ASPX:

< %@page language = c# clientTarget = downlevel %>

ค่าเริ่มต้นของคำสั่งนี้คืออัตโนมัติซึ่งระบุว่าคุณตรวจสอบลูกค้าของ Microsoft Internet Explorer 4.0 หรือสูงกว่าเท่านั้น

หมายเหตุ: น่าเสียดายที่ในเบต้า 1 คำสั่งนี้ไม่เพียง แต่ปิดใช้งานสำหรับการตรวจสอบและในเวลาเดียวกันการควบคุมเว็บทั้งหมดใช้แท็ก HTML 3.2 ในการดำเนินการซึ่งอาจมีผลลัพธ์ที่ไม่คาดคิด เวอร์ชันสุดท้ายเป็นวิธีที่ดีกว่าในการควบคุมปัญหานี้

ลำดับเหตุการณ์ลูกค้า

ลำดับนี้เป็นลำดับเหตุการณ์ที่เกิดขึ้นเมื่อหน้าที่มีการตรวจสอบไคลเอนต์:

เมื่อโหลดเบราว์เซอร์บนหน้าคุณจะต้องเริ่มต้นการควบคุมการตรวจสอบแต่ละครั้ง การควบคุมเหล่านี้จะถูกส่งเป็นเครื่องหมาย <span> และคุณสมบัติ HTML ของพวกเขาอยู่ใกล้กับคุณสมบัติบนเซิร์ฟเวอร์มากที่สุด สิ่งสำคัญที่สุดคือองค์ประกอบอินพุตทั้งหมดที่อ้างอิงโดยอุปกรณ์ตรวจสอบจะถูก "แขวนคอ" ในเวลานี้ องค์ประกอบอินพุตอ้างอิงจะแก้ไขเหตุการณ์ไคลเอนต์เพื่อเรียกรูทีนการตรวจสอบเมื่อป้อนการเปลี่ยนแปลง

รหัสในไลบรารีสคริปต์จะถูกดำเนินการเมื่อผู้ใช้ใช้ปุ่มแท็บเพื่อสลับระหว่างแต่ละฟิลด์ เมื่อมีการเปลี่ยนแปลงฟิลด์อิสระบางอย่างเงื่อนไขการตรวจสอบจะได้รับการประเมินใหม่และอุปกรณ์ตรวจสอบจะมองเห็นหรือมองไม่เห็นตามต้องการ

เมื่อผู้ใช้พยายามส่งแบบฟอร์มการตรวจสอบทั้งหมดจะได้รับการประเมิน หากการตรวจสอบทั้งหมดเหล่านี้มีประสิทธิภาพแบบฟอร์มจะถูกส่งไปยังเซิร์ฟเวอร์ หากมีข้อผิดพลาดในหนึ่งสถานที่หรือมากกว่าสถานการณ์ต่อไปนี้จะเกิดขึ้น:

การส่งถูกยกเลิก แบบฟอร์มไม่ได้ส่งไปยังเซิร์ฟเวอร์

การตรวจสอบที่ไม่ถูกต้องทั้งหมดสามารถมองเห็นได้

หากสรุปการตรวจสอบมีการแสดง showmary = true ข้อผิดพลาดทั้งหมดจากการควบคุมการตรวจสอบจะถูกรวบรวมและเนื้อหาจะได้รับการปรับปรุงด้วยข้อผิดพลาดเหล่านี้

หากสรุปการตรวจสอบมี showMessageBox = TRUE มันจะรวบรวมข้อผิดพลาดและแสดงข้อผิดพลาดเหล่านี้ในกล่องข้อมูลของลูกค้า

เนื่องจากการควบคุมการตรวจสอบไคลเอ็นต์จะดำเนินการเมื่อเข้าหรือเมื่อใด โปรดทราบว่าหลังจากการส่งการควบคุมการตรวจสอบเหล่านี้จะยังคงได้รับการประเมินบนเซิร์ฟเวอร์อีกครั้ง

API ลูกค้า

มี API ขนาดเล็กที่สามารถใช้กับลูกค้าเพื่อให้ได้เอฟเฟกต์ต่าง ๆ ในรหัสลูกค้าของคุณเอง เนื่องจากรูทีนบางอย่างไม่สามารถซ่อนได้ในทางทฤษฎีคุณสามารถใช้ไคลเอนต์เพื่อตรวจสอบตัวแปรคุณสมบัติและฟังก์ชั่นที่กำหนดโดยไคลเอนต์ทั้งหมด อย่างไรก็ตามหลายคนสามารถเปลี่ยนแปลงได้ ต่อไปนี้สรุปวัตถุลูกค้าที่เราสนับสนุนให้คุณใช้

ตารางที่ 3 วัตถุไคลเอนต์

ชื่อประเภทคำอธิบาย

ตัวแปร Boolean PAGE_ISVALID ชี้ให้เห็นว่าหน้าเว็บนั้นถูกต้องหรือไม่ การตรวจสอบสคริปต์จะทำให้ตัวแปรล่าสุดอยู่เสมอ

อาร์เรย์องค์ประกอบ page_validator นี่คืออาร์เรย์ที่มีการตรวจสอบทั้งหมดในหน้า

page_validationactive ตัวแปรบูลีนระบุว่าควรตรวจสอบหรือไม่ ตั้งค่าตัวแปรนี้เป็นเท็จสามารถพิสูจน์ได้โดยการเขียนโปรแกรม

แอตทริบิวต์ isvalid boolen อุปกรณ์ตรวจสอบไคลเอนต์แต่ละตัวมีคุณสมบัติชี้ให้เห็นว่าอุปกรณ์ตรวจสอบนั้นถูกต้องหรือไม่ โปรดทราบว่าในเวอร์ชัน PDC แอตทริบิวต์นี้ผสมกับ Isvalid

ข้ามการตรวจสอบลูกค้า

งานหนึ่งที่คุณต้องดำเนินการบ่อยครั้งคือการเพิ่มปุ่ม "ยกเลิก" หรือปุ่มนำทางบนหน้า ในกรณีนี้แม้ว่าจะมีข้อผิดพลาดในหน้าคุณอาจต้องการใช้ปุ่มเพื่อส่งหน้า เนื่องจากปุ่ม client onclick เกิดขึ้นก่อนเหตุการณ์ onsubmit ของแบบฟอร์มจึงอาจหลีกเลี่ยงการส่งการตรวจสอบและข้ามการตรวจสอบ ต่อไปนี้แสดงวิธีใช้การควบคุมภาพ HTML เป็นปุ่ม "ยกเลิก" เพื่อให้งานเสร็จสมบูรณ์:

<อินพุตประเภท = image runat = เซิร์ฟเวอร์

ค่า = ยกเลิก

onclick = page_validationactive = false;

onserverClight = cmdcancel_click>

ใช้ปุ่มหรือการควบคุม ImageButton เพื่อดำเนินการสับสนเนื่องจากเหตุการณ์ onClick ถือว่าเป็นเหตุการณ์ที่อยู่ข้างเซิร์ฟเวอร์ที่มีชื่อเดียวกัน คุณควรตั้งค่าเหตุการณ์นี้ในสคริปต์ไคลเอนต์:

<ASP: ImageButton Runat = Server ID = CMDimGCancel

Alternatetext = ยกเลิก

onclick = cmdcancel_click/>

<ภาษาสคริปต์ = JavaScript>

document.all [cmdimgcancel] .onclick =

ฟังก์ชั่นใหม่ (page_validationactive = false;);

</script>

อีกวิธีหนึ่งในการแก้ปัญหานี้คือการตั้งค่าการตั้งค่าบางอย่างของปุ่ม "ยกเลิก" เพื่อที่จะไม่เรียกเหตุการณ์การส่งในสคริปต์ไคลเอนต์เมื่อกลับมา การควบคุม HTMLINPUTBUTTON และ LINKBUTTON เป็นตัวอย่าง

ผลพิเศษ

ข้อกำหนดทั่วไปอีกประการหนึ่งคือนอกเหนือจากข้อมูลข้อผิดพลาดที่แสดงโดยอุปกรณ์ตรวจสอบตัวเองยังจำเป็นต้องมีเอฟเฟกต์อื่น ๆ ในกรณีนี้การปรับเปลี่ยนใด ๆ ที่คุณจำเป็นต้องดำเนินการในเวลาเดียวกันบนเซิร์ฟเวอร์หรือไคลเอนต์ สมมติว่าคุณต้องเพิ่มป้ายกำกับเพื่อเปลี่ยนสีตามที่อินพุตนั้นใช้ได้หรือไม่ ต่อไปนี้เป็นวิธีการใช้งานนี้บนเซิร์ฟเวอร์:

Public Class ChangecolorPage: หน้า {

ฉลากสาธารณะ lblzip;

ค่า regulaxpressionValidator สาธารณะ;

ได้รับการป้องกันการแทนที่โมฆะ overoad (eventargs e) {{

lblzip.forecolor = valzip.isvalid?

-

-

วิธีการทั้งหมดข้างต้นนั้นสมบูรณ์แบบ แต่ตราบใดที่คุณแก้ไขการตรวจสอบด้านบนคุณจะพบว่าถ้าคุณไม่ได้ดำเนินการเดียวกันกับลูกค้ามันจะดูไม่สอดคล้องกันมาก เฟรมเวิร์กการตรวจสอบจะช่วยให้คุณหลีกเลี่ยงเอฟเฟกต์คู่ดังกล่าวได้ แต่ไม่สามารถหลีกเลี่ยงผลกระทบอื่น ๆ ที่คุณต้องได้รับในเวลาเดียวกันกับไคลเอนต์และเซิร์ฟเวอร์ ต่อไปนี้เป็นส่วนที่ทำงานเดียวกันกับลูกค้า:

<asp: label id = lblzip runat = เซิร์ฟเวอร์

text = zip code:/>

<asp: textbox id = txtzip runat = เซิร์ฟเวอร์

onchange = txtziponchange (); /> < /asp: textbox> <br>

<ASP: RegantyXpressionValididator id = valzip runat = เซิร์ฟเวอร์

controltovalidate = txtzip

errorMessage = รหัสไปรษณีย์ไม่ถูกต้อง

validationxpression = [0-9] {5} /> <br>

<ภาษาสคริปต์ = JavaScript>

ฟังก์ชั่น txtziponchange () {{) {

// หากการตรวจสอบลูกค้าไม่ได้อยู่ในกิจกรรมมันจะไม่ดำเนินการใด ๆ

ifof (page_validators) == undefined) return;

// เปลี่ยนสีของฉลาก

lblzip.style.color = valzip.isvalid?

-

</script>

เบต้า 1 ไคลเอนต์ API

สำหรับรุ่นเบต้า 1 ฟังก์ชั่นบางอย่างที่สามารถเรียกได้จากสคริปต์ไคลเอนต์จะทำให้เกิดสถานการณ์อื่น

ตารางที่ 4 ฟังก์ชั่นจากการโทรสคริปต์ไคลเอนต์

คำอธิบายชื่อ

ValidatorValidate (VAL) ใช้อุปกรณ์ตรวจสอบไคลเอนต์เป็นอินพุต ทำให้อุปกรณ์ตรวจสอบตรวจสอบอินพุตและอัปเดตการแสดงผล

Validatorenable (VAL, เปิดใช้งาน) ได้รับอุปกรณ์ตรวจสอบไคลเอนต์และค่าบูลีน เปิดหรือปิดใช้งานอุปกรณ์ยืนยันไคลเอนต์ หากถูกปิดใช้งานอุปกรณ์ตรวจสอบไคลเอนต์จะไม่ได้รับการประเมินและตัวตรวจสอบไคลเอนต์จะถูกต้องเสมอ

ValidatorHookUpControl (การควบคุม, VAL) ได้รับองค์ประกอบอินพุต HTML และอุปกรณ์ตรวจสอบไคลเอนต์ แก้ไขหรือสร้างเหตุการณ์การเปลี่ยนแปลงขององค์ประกอบเพื่อให้สามารถอัปเดตอุปกรณ์ตรวจสอบได้ในระหว่างการเปลี่ยนแปลง ฟังก์ชั่นนี้เหมาะสำหรับการตรวจสอบที่กำหนดเองตามค่าอินพุตหลายค่า

วัตถุประสงค์พิเศษคือการเปิดใช้งานหรือปิดใช้งานอุปกรณ์ตรวจสอบ หากคุณต้องการตรวจสอบว่าคุณมีผลเฉพาะในสถานการณ์เฉพาะคุณอาจต้องเปลี่ยนสถานะการเปิดใช้งานในเวลาเดียวกันบนเซิร์ฟเวอร์และไคลเอนต์มิฉะนั้นคุณจะพบว่าผู้ใช้ไม่สามารถส่งหน้าเว็บได้

ต่อไปนี้เป็นตัวอย่างข้างต้นพร้อมฟิลด์

คลาสสาธารณะเงื่อนไข: หน้า {

public htmlinputcheckbox chksameas;

Public ResearchfieldValidator Rfvalshipaddress;

Void Void ที่ได้รับการป้องกันการตรวจสอบ () {) {)

bool enableship =!

rfvalshipaddress.enabled = enableship;

base.validate ();

-

-

ต่อไปนี้เป็นรหัสของลูกค้าเทียบเท่า:

<อินพุตประเภท = ช่องทำเครื่องหมาย runat = เซิร์ฟเวอร์ ID = chksameas

onclick = onChangesameas ();> เช่นเดียวกับที่อยู่การชำระเงิน <br>

<ภาษาสคริปต์ = JavaScript>

ฟังก์ชั่น onchangesameas () {

var entleship =!

ตรวจสอบความถูกต้อง (rfvalshipaddress, enableship);

-

</script>

กฎที่มีประสิทธิภาพและข้อมูลข้อผิดพลาดที่เป็นประโยชน์

อุปกรณ์ตรวจสอบแต่ละตัวแสดงข้อมูลข้อผิดพลาดเฉพาะเกี่ยวกับเงื่อนไขเฉพาะในการควบคุมเฉพาะ มีกฎบางอย่างที่ยืนยันว่ามันถูกต้องหรือไม่

การตรวจสอบที่ว่างเปล่าทั้งหมด (ยกเว้นสำหรับ FieldValidator ที่ต้องการ) ถือว่าถูกต้อง หากค่าที่ว่างเปล่าไม่ถูกต้องคุณมักจะต้องใช้ฟีลด์ฟิลด์ที่จำเป็นและผู้ตรวจสอบอื่น ๆ คุณต้องทำเช่นนี้เพราะโดยทั่วไปคุณต้องการแสดงข้อมูลข้อผิดพลาดที่แตกต่างกันเกี่ยวกับอุปกรณ์ตรวจสอบที่ว่างเปล่าและประสิทธิภาพ นอกจากนี้คุณยังสามารถใช้ข้อมูลที่ไม่ชัดเจนเช่น "คุณต้องป้อนค่าและค่านี้จะต้องอยู่ระหว่าง 1 ถึง 10"

กฎพิเศษอื่นที่ใช้เมื่อไม่สามารถแปลงฟิลด์อินพุตเป็นชนิดข้อมูลที่ระบุนั้นเกี่ยวข้องกับการเปรียบเทียบและ rangevalidator กระบวนการประเมินความถูกต้องของผู้เปรียบเทียบการควบคุมของ ControlTocompare ระบุกระบวนการประเมินความถูกต้องตามที่อธิบายไว้ด้านล่าง:

หากฟิลด์อินพุตที่อ้างอิงโดย ControlTovalidate นั้นว่างเปล่าก็จะมีประสิทธิภาพ

หากฟิลด์อินพุตที่อ้างอิงโดย ControlTovalidate ไม่สามารถแปลงเป็นชนิดข้อมูลที่ต้องการได้จะไม่ถูกต้อง

หากฟิลด์อินพุตที่อ้างอิงโดย ControlTocompare ไม่สามารถแปลงเป็นชนิดข้อมูลที่ต้องการได้จะถูกต้อง

ฟิลด์อินพุตจะถูกแปลงเป็นชนิดข้อมูลที่ต้องการและเปรียบเทียบ

ขั้นตอนที่สามดูไม่สอดคล้องกันเล็กน้อย เหตุผลนี้เป็นเพราะหากอุปกรณ์ตรวจสอบตรวจสอบประสิทธิภาพของหลายฟิลด์ในเวลาเดียวกันมันเป็นเรื่องยากที่จะเขียนข้อมูลข้อผิดพลาดที่มีความหมายสำหรับอุปกรณ์ตรวจสอบ ควรใช้อุปกรณ์ตรวจสอบอิสระเพื่อรายงานสถานการณ์ข้อผิดพลาดในฟิลด์อินพุต ControlTocompare Rangevalidator มีวิธีการทำงานที่คล้ายกันโดยมีคุณสมบัติสูงสุดและต่ำสุด

ฟังก์ชั่นคุณสมบัติที่เปิดใช้งานมองเห็นและแสดงผล

ความแตกต่างระหว่างคุณสมบัติที่เปิดใช้งานการมองเห็นและการแสดงผลของอุปกรณ์ตรวจสอบอาจไม่ชัดเจนมาก

display = none สามารถใช้เพื่อระบุว่าอุปกรณ์ตรวจสอบไม่แสดงเนื้อหาใด ๆ โดยตรง แต่ยังคงประเมินยังคงมีผลต่อประสิทธิภาพโดยรวมและยังสามารถใส่ข้อผิดพลาดในบทสรุปของไคลเอนต์และเซิร์ฟเวอร์ สำหรับการตรวจสอบลูกค้าค่าเหล่านี้จะถูกกำหนดให้ใช้คุณสมบัติสไตล์ที่มองเห็นได้หรือใช้คุณสมบัติสไตล์การแสดงผลเพื่อเปิดหรือปิดอุปกรณ์การตรวจสอบ สำหรับเซิร์ฟเวอร์ -การตรวจสอบด้านข้าง, display = dynamic หมายความว่าอินพุตไม่แสดงเนื้อหาใด ๆ เมื่ออินพุตถูกต้องและ display = static แสดงถึงพื้นที่ที่ไม่เปลี่ยนแปลง การตั้งค่าสุดท้ายจะถูกพับลงในเนื้อหาเมื่อเซลล์ที่มีเฉพาะอุปกรณ์ตรวจสอบในตารางนั้นถูกต้อง

ทำไมไม่ใช้ Visible = False เพื่อให้อุปกรณ์ตรวจสอบมองเห็นได้? ใน ASP+แอตทริบิวต์ที่มองเห็นได้ของการควบคุมมีความหมายมากมาย: การควบคุมของ Visible = False จะไม่ถูกประมวลผลหรือแสดงเลย มันเป็นเพราะความหมายนี้ว่าสิ่งที่มองเห็นได้ = เท็จของอุปกรณ์ตรวจสอบหมายความว่าไม่เพียง แต่ไม่แสดงเนื้อหาใด ๆ แต่ยังไม่สามารถใช้งานได้ อุปกรณ์ตรวจสอบนี้จะไม่ได้รับการประเมินจะไม่ส่งผลกระทบต่อความถูกต้องของหน้าและจะไม่ถูกใส่ในนามธรรม

เปิดใช้งานเป็นกลาง ในกรณีส่วนใหญ่ผลของ enabled = false และ visible = false นั้นเหมือนกันทุกประการ ในรุ่นเบต้า 1 หรือรุ่นที่สูงกว่ามีความแตกต่างที่สำคัญ: ในการตรวจสอบไคลเอ็นต์อุปกรณ์ตรวจสอบการปิดใช้งานจะยังคงถูกส่งไปยังเบราว์เซอร์ แต่อยู่ในสถานะปิดใช้งาน คุณสามารถใช้ฟังก์ชั่นที่ถูกต้องได้ในสคริปต์ไคลเอนต์เพื่อเปิดใช้งานอุปกรณ์ตรวจสอบ

เมื่อใช้การมองเห็นหรือเปิดใช้งานเพื่อควบคุมว่าจะตรวจสอบให้ใส่ใจกับคำสั่งซื้อตามคำสั่งซื้อบนเซิร์ฟเวอร์ข้างต้น หรือเปลี่ยนแปลงก่อนการตรวจสอบหรือตรวจสอบอีกครั้งหลังจากการเปลี่ยนแปลง มิฉะนั้นค่า isvalid ของพวกเขาจะไม่สะท้อนการเปลี่ยนแปลงของแอตทริบิวต์

การควบคุม 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 = เซิร์ฟเวอร์

errorMessage = ตัวเลขไม่สามารถลบได้!

controltovalidate = txtCustomData

onservalidationFunction = servervalidation

clientValidationFunction = checkeven /> <br>

ฟิลด์ข้อมูล: <asp: textbox id = txtcustosdata runat = เซิร์ฟเวอร์ />

<ภาษาสคริปต์ = JavaScript>

-

ฟังก์ชั่น checkeven (แหล่งที่มา, ค่า) {{

var value = parseInt (ค่า, 10);

ถ้า (isnan (val))

กลับเท็จ;

return ((val % 2) == 0);

-

-

</script>

นี่คือข้อควรระวังบางประการโดยใช้ CustomValidator:

เช่นเดียวกับการควบคุมการตรวจสอบอื่น ๆ ทั้งหมด (ยกเว้นสำหรับ FieldValidator ที่ต้องการ) หากฟิลด์อินพุตว่างเปล่าก็จะพิจารณาว่า customValidator มีประสิทธิภาพ

หากใช้เบราว์เซอร์รุ่นเก่าหรือปิดการตรวจสอบไคลเอนต์จะไม่สามารถเรียกใช้ฟังก์ชันการตรวจสอบไคลเอนต์ ก่อนที่จะกำหนดฟังก์ชั่นคุณไม่จำเป็นต้องตรวจสอบฟังก์ชั่นของเบราว์เซอร์ที่ใช้ในเบราว์เซอร์ แต่คุณต้องตรวจสอบให้แน่ใจว่าเบราว์เซอร์ไม่ได้ทำให้เกิดข้อผิดพลาดของสคริปต์เนื่องจากคำจำกัดความ อย่าลืมทำให้รหัสลูกค้าของคุณเป็นคำอธิบายประกอบของ HTML ดังที่แสดงในตัวอย่างต่อไปนี้

พารามิเตอร์สองพารามิเตอร์จะถูกส่งผ่านไปยังฟังก์ชันไคลเอนต์ของคุณและสอดคล้องกับพารามิเตอร์ที่ส่งผ่านไปยังฟังก์ชันเซิร์ฟเวอร์ อย่างแรกคือองค์ประกอบอุปกรณ์ตรวจสอบไคลเอนต์และอย่างที่สองคือค่าควบคุมที่ระบุโดย ControlTovalidate อย่างไรก็ตามบนไคลเอนต์คุณสามารถเลือกที่จะไม่กำหนดพารามิเตอร์สำหรับฟังก์ชั่นซึ่งจะทำงานได้ตามปกติ

หากคุณใช้ Beta1 หรือรุ่นที่สูงกว่าคุณสามารถควบคุม Controltovalidate ได้ว่างเปล่า ในโหมดนี้ฟังก์ชั่นเซิร์ฟเวอร์จะทริกเกอร์การเดินทางไปกลับรอบเสมอและฟังก์ชั่นไคลเอนต์จะถูกทริกเกอร์ทุกครั้งที่คุณพยายามส่ง คุณสามารถใช้คุณสมบัตินี้เพื่อตรวจสอบการควบคุมที่วิธีการอื่นไม่สามารถตรวจสอบได้เช่นช่องทำเครื่องหมายหรือปุ่มวิทยุแยกต่างหาก หากเงื่อนไขขึ้นอยู่กับการควบคุมหลายตัวและคุณไม่ต้องการให้ผู้ใช้ประเมินเงื่อนไขเมื่อสลับระหว่างแต่ละฟิลด์บนหน้าคุณสามารถใช้วิธีนี้ได้

ตัวเลือกอื่นในรุ่นเบต้า 1 หรือสูงกว่าคือเหตุการณ์การเปลี่ยนแปลงของการควบคุมหลายตัว วิธีการคือการเพิ่มสคริปต์ฝังตัวที่เรียกฟังก์ชันไคลเอนต์ ValidatorHookupControl ตามที่อธิบายไว้ข้างต้น

การควบคุมใดที่สามารถตรวจสอบได้?

ในการเปิดใช้งานการควบคุมที่จะตรวจสอบโดยการอ้างอิงการควบคุมการควบคุมจะต้องมีคุณสมบัติที่ตรวจสอบแล้ว การควบคุมที่ได้รับการตรวจสอบทั้งหมดมีคุณสมบัติการตรวจสอบความถูกต้องของระบบการตรวจสอบซึ่งระบุว่าควรอ่านแอตทริบิวต์ที่ควรอ่านในระหว่างการตรวจสอบ หากคุณเขียนการควบคุมของคุณเองคุณสามารถระบุคุณสมบัติที่จะใช้โดยการจัดหาหนึ่งในนั้นเพื่อให้การควบคุมมีส่วนร่วมในการตรวจสอบ

ในการเปิดใช้งานการตรวจสอบที่จะดำเนินการตามปกติบนไคลเอนต์แอตทริบิวต์จะต้องสอดคล้องกับลักษณะค่าขององค์ประกอบ HTML ที่แสดงโดยไคลเอนต์ การควบคุมที่ซับซ้อนจำนวนมาก (เช่น DataGrid และปฏิทิน) ไม่คุ้มค่ากับไคลเอนต์และสามารถตรวจสอบได้บนเซิร์ฟเวอร์เท่านั้น ดังนั้นเฉพาะการควบคุมที่ใกล้เคียงกับองค์ประกอบ HTML เท่านั้นที่สามารถมีส่วนร่วมในการตรวจสอบ นอกจากนี้การควบคุมจะต้องมีค่าตรรกะเดียวบนไคลเอนต์ ดังนั้น RadiobuttonList สามารถตรวจสอบได้ แต่ CheckBoxList ไม่สามารถทำได้

จบ

คำอธิบายข้างต้นของการตรวจสอบ ASP+ อาจเกินเนื้อหาที่คุณต้องการเข้าใจ สนุกกับมัน!

----------------------------------------------- ---------------------------------------------------------- ------------------------

โปรดใช้ IE4.0 ด้านบนเวอร์ชัน 800 * 600 ดูในเว็บไซต์นี้

& Copy; 2001 Microsoft Corporation สงวนลิขสิทธิ์ รักษาความเป็นเจ้าของ ใช้กฎระเบียบ

รวบรวมรหัสเอฟเฟกต์พิเศษของหน้าเว็บที่ใช้งานได้จริงที่สุด!