ในคำอธิบายเชิงลึก ASP+ การตรวจสอบ
แอนโทนี่มัวร์
Microsoft Corporation
ตุลาคม 2543
สรุป: คำอธิบายโดยละเอียดเกี่ยวกับการใช้การควบคุมเว็บการตรวจสอบ ASP+
สารบัญ
บทนำสั้น ๆ
เริ่มต้น
เกิดขึ้นเมื่อไหร่?
ลำดับการตรวจสอบทางฝั่งเซิร์ฟเวอร์
การยืนยันลูกค้า
กฎที่มีประสิทธิภาพและข้อมูลข้อผิดพลาดที่เป็นประโยชน์
ฟังก์ชั่นคุณสมบัติที่เปิดใช้งานมองเห็นและแสดงผล
การควบคุม customvalidator
การควบคุมใดที่สามารถตรวจสอบได้?
จบ
----------------------------------------------- ---------------------------------------------------------- ------------------------
บทนำสั้น ๆ
บทความนี้อธิบายวิธีการทำงานของการควบคุมการตรวจสอบ ASP+ โดยละเอียด หากคุณต้องการสร้างหน้าซับซ้อนที่มีการควบคุมการตรวจสอบหรือเพื่อขยายกรอบการตรวจสอบขอแนะนำให้คุณอ่านบทความนี้ หากคุณต้องการเรียนรู้ที่จะใช้การควบคุมการตรวจสอบหรือตัดสินใจว่าจะใช้การควบคุมการตรวจสอบให้ดู "ASP+ ผู้ใช้ป้อนการยืนยัน (ภาษาอังกฤษ)"
เริ่มต้น
เรารู้ว่ามันเป็นสิ่งสำคัญที่จะต้องเข้าใจการตรวจสอบในระหว่างกระบวนการพัฒนา ASP+ ทั้งหมด ดูเว็บไซต์เชิงพาณิชย์ส่วนใหญ่ของวันนี้คุณจะพบว่ามีหลายรูปแบบในเว็บไซต์เหล่านี้ซึ่งชัดเจนโดยการดำเนินการโค้ดที่เขียนด้วยลายมือจำนวนมาก การเขียนรหัสการยืนยันไม่ใช่งานที่น่าสนใจ หากคุณเขียนโค้ดเพื่อแสดงตารางข้อมูลหรือสร้างแผนภูมิแบบไดนามิกมันอาจน่าสนใจมาก แต่ไม่มีใครสามารถยืนยันกับเพื่อนร่วมงานของเขาได้ว่าวิธี "เจ๋ง" นี้สามารถห้ามค่าที่ว่างเปล่าในฟิลด์ชื่อ
ด้วยเหตุผลอื่นการตรวจสอบเว็บแอปพลิเคชันก็ลำบากเช่นกัน HTML 3.2 มีข้อ จำกัด มากมายเกี่ยวกับเนื้อหาที่คุณสามารถควบคุมหรือข้อเสนอแนะที่คุณสามารถได้รับจากผู้ใช้ดังนั้นจึงไม่สามารถนำไปใช้กับเทคนิคที่สามารถใช้กับไคลเอนต์ที่เติมเต็มได้มากขึ้นเช่นห้ามมิให้ผู้ใช้ป้อนอักขระบางตัวหรือ ทำเสียง การใช้สคริปต์เบราว์เซอร์อาจสร้างการตรวจสอบที่มีประสิทธิภาพมากขึ้น อย่างไรก็ตามวิธีนี้เป็นการยากที่จะยืนยันเนื่องจากเบราว์เซอร์ของลูกค้าไม่จำเป็นต้องเป็นสคริปต์และผู้ใช้ที่เป็นอันตรายสามารถข้ามได้ ดังนั้นเพื่อให้แน่ใจว่าความปลอดภัยของเว็บไซต์จำเป็นต้องทำการตรวจสอบเซิร์ฟเวอร์เดียวกัน
เมื่อพัฒนา ASP+ความตั้งใจดั้งเดิมของเราคือการใช้การควบคุมเพียงครั้งเดียวในการตรวจสอบกระบวนการ แต่เมื่อได้รับการออกแบบฉันพบว่าความปรารถนานี้ไม่สามารถทำได้ เราได้ทำการวิจัยแบบฟอร์มการป้อนข้อมูลข้อมูลจำนวนมากเพื่อค้นหาวิธีแก้ปัญหาที่สามารถนำไปใช้กับรูปแบบได้มากที่สุด เราพบว่าตารางข้อมูลอินพุตมีคุณสมบัติที่น่าสนใจมากมาย:
แม้ว่าข้อมูลข้อผิดพลาดหรือไอคอนมักจะอยู่ติดกับองค์ประกอบอินพุต แต่ก็มักจะอยู่ในเซลล์ที่แตกต่างกันของตาราง
มักจะมีพื้นที่ในหน้าเพื่อสรุปข้อผิดพลาดทั้งหมด
เว็บไซต์จำนวนมากรวมถึงสคริปต์ไคลเอนต์เพื่อให้ข้อเสนอแนะที่เร็วขึ้นในขณะที่ป้องกันการเดินทางระหว่างเซิร์ฟเวอร์โดยไร้ประโยชน์
เว็บไซต์จำนวนมากที่มีสคริปต์ไคลเอ็นต์แสดงกล่องข้อมูลเมื่อมีข้อผิดพลาด
ไม่เพียง แต่จะมีการตรวจสอบอินพุตข้อความเท่านั้น แต่ยังมีการตรวจสอบรายการดรอปดาวน์และปุ่มเลือกเดียว
หากฟิลด์ว่างเปล่าเว็บไซต์มักจะแสดงข้อมูลหรือไอคอนที่แตกต่างกันเมื่อรายการไม่ถูกต้อง
การตรวจสอบที่มีประสิทธิภาพจำนวนมากสามารถแทนที่ได้อย่างดีด้วยการแสดงออกที่ใช้กันทั่วไป
การตรวจสอบมักจะขึ้นอยู่กับผลการเปรียบเทียบระหว่างอินพุตสองอินพุต
90% หรือมากกว่า 90% ของงานตรวจสอบเป็นการดำเนินการทั่วไปบางอย่างเช่นการตรวจสอบชื่อหรือรหัสไปรษณีย์ เว็บไซต์ส่วนใหญ่ยังคงดูเหมือนจะทำซ้ำงานเหล่านี้
เนื่องจากความแตกต่างระหว่างไซต์มักจะมีขนาดใหญ่เกินไปจึงไม่สามารถหาทางออกที่สมบูรณ์แบบเพื่อจัดการงานการตรวจสอบทั้งหมดของแต่ละไซต์
เมื่อพิจารณาถึงสถานการณ์ทั้งหมดข้างต้นโซลูชั่นขั้นสุดท้ายรวมถึงการควบคุมอุปกรณ์การตรวจสอบห้าแบบการควบคุมการตรวจสอบความถูกต้องและการรวมเข้ากับวัตถุหน้า ในขณะเดียวกันก็เห็นได้ชัดว่าต้องมีการขยายโซลูชันและจำเป็นต้องมี API เพื่อร่วมมือกับไคลเอนต์และเซิร์ฟเวอร์
เราพบว่าเราต้องการกล่องเครื่องมือขนาดใหญ่ในระหว่างการตรวจสอบการวิจัยต่างๆ ในสภาพแวดล้อมส่วนประกอบส่วนใหญ่เช่นMicrosoft®ActiveX®เราอาจพยายามรวมฟังก์ชั่นของการควบคุมการตรวจสอบทั้งหมดเข้ากับการควบคุมเพื่อประมวลผลแอตทริบิวต์ที่แตกต่างกันในโหมดที่แตกต่างกัน โชคดีที่มีมรดกที่มีมนต์ขลังในMicrosoft® .NET Framework
การควบคุมเหล่านี้ส่วนใหญ่จะถูกนำไปใช้ในผู้ปกครองระดับสาธารณะ -ระดับ 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® การตรวจสอบไม่จำเป็นต้องมีส่วนประกอบไบนารีใด ๆ
แม้ว่ามาตรฐานของภาษา 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 มันจะรวบรวมข้อผิดพลาดและแสดงข้อผิดพลาดเหล่านี้ในกล่องข้อมูลของลูกค้า
เนื่องจากการควบคุมการตรวจสอบไคลเอ็นต์จะดำเนินการเมื่อเข้าหรือเมื่อใด โปรดทราบว่าหลังจากการส่งการควบคุมการตรวจสอบเหล่านี้จะยังคงได้รับการประเมินบนเซิร์ฟเวอร์อีกครั้ง