ملخص: تفسيرات مفصلة لاستخدام التحكم في الويب ASP+ التحقق.
جدول المحتويات
مقدمة موجزة
ابدء
متى يحدث؟
تسلسل التحقق على جانب الخادم
التحقق من العميل
قواعد فعالة ومعلومات خطأ مفيدة
وظائف تمكين ومرئية وعرض الخصائص
CustomValidator التحكم
ما هي الضوابط التي يمكن التحقق منها؟
نهاية
------------------------------------------------- ------------------------------------------------- ------------------------
مقدمة موجزة
تشرح هذه المقالة طريقة عمل التحكم في ASP+ التحقق بالتفصيل. إذا كنت ترغب في إنشاء صفحة معقدة تحتوي على التحكم في التحقق ، أو لتوسيع إطار التحقق ، فمن المستحسن قراءة هذه المقالة. إذا كنت ترغب في تعلم استخدام التحكم في التحقق أو تحديد ما إذا كنت تريد استخدام التحكم في التحقق ، راجع "ASP+ User Enter Fear (English)".
ابدء
نحن نعلم أنه من المهم فهم التحقق خلال عملية تطوير ASP+ بأكملها. انظر إلى معظم مواقع الويب التجارية اليوم ، ستجد أن هناك أشكالًا متعددة في هذه المواقع ، والتي يتم تنفيذها بشكل واضح عن طريق تنفيذ عدد كبير من التعليمات البرمجية المكتوبة بخط اليد. كتابة رمز التحقق ليس وظيفة مثيرة للاهتمام. إذا كتبت رمزًا لعرض جدول البيانات أو إنشاء المخططات ديناميكيًا ، فقد يكون ذلك جذابًا للغاية ، ولكن لا يمكن لأحد أن يؤكد مع زملائه أن هذه الطريقة "الرائعة" يمكن أن تحظر القيمة الفارغة في حقل الاسم.
لأسباب أخرى ، فإن التحقق من تطبيقات الويب أمر مزعج للغاية. يحتوي HTML 3.2 على الكثير من القيود المفروضة على المحتوى الذي يمكنك التحكم فيه أو التعليقات التي يمكنك الحصول عليها من المستخدم ، لذلك لا يمكن تطبيقها على التقنيات التي يمكن استخدامها على عميل أكثر إرضاءً ، مثل منع المستخدمين من إدخال أحرف معينة أو صنع صوت. قد يؤدي استخدام البرنامج النصي للمتصفح إلى تحقيق أكثر قوة. ومع ذلك ، يصعب تأكيد هذه الطريقة ، لأن متصفح العميل ليس بالضرورة نصًا ، ويمكن للمستخدمين الخبيث تجاوزه. لذلك ، من أجل ضمان سلامة الموقع ، من الضروري إجراء نفس الفحص للخادم.
عند تطوير ASP+، فإن نيتنا الأصلية هي استخدام عنصر تحكم واحد فقط لمعالجة التحقق. ولكن عندما تم تصميمه ، وجدت أنه لا يمكن تحقيق هذه الرغبة. لقد بحثنا في عدد كبير من نماذج إدخال البيانات لإيجاد حل يمكن تطبيقه على أكبر عدد ممكن من النماذج. لقد وجدنا أن جدول إدخال البيانات يحتوي على العديد من الميزات المثيرة للاهتمام:
على الرغم من أن معلومات الخطأ أو أيقوناتها غالبًا ما تكون متاخمة لعناصر الإدخال ، إلا أنها تقع دائمًا في خلايا مختلفة من الجدول.
غالبًا ما تكون هناك منطقة على الصفحة لتلخيص جميع الأخطاء.
تتضمن العديد من المواقع البرامج النصية العميل لتوفير ملاحظات أسرع مع منع السفر بين الخادم دون جدوى.
العديد من المواقع التي تحتوي على برامج نصية العميل عرض مربعات المعلومات عندما يكون هناك خطأ.
لن يتم التحقق من إدخال النص فحسب ، بل سيتم التحقق من قائمة القائمة المنخفضة وزر الاختيار الفردي.
إذا كان الحقل فارغًا ، فإن الموقع عادة ما يعرض معلومات أو أيقونات مختلفة عندما يكون الإدخال غير صالح.
يمكن استبدال العديد من الفحوصات الفعالة بشكل جيد بالتعبيرات شائعة الاستخدام.
يعتمد التحقق عادةً على نتائج المقارنة بين مدخلتين.
90 ٪ أو أكثر من 90 ٪ من مهام التحقق هي بعض العمليات الشائعة ، مثل التحقق من الاسم أو الرمز البريدي. لا يزال يبدو أن معظم المواقع تكرر هذه المهام.
نظرًا لأن الفرق بين المواقع عادة ما يكون كبيرًا جدًا ، فلا يمكن الحصول على حل مثالي للتعامل مع جميع مهام التحقق من كل موقع.
بالنظر إلى جميع المواقف المذكورة أعلاه ، تتضمن الحلول النهائية خمسة عناصر تحكم في أجهزة التحقق ، وعناصر التحكم في مجال التحقق ، والتكامل مع كائنات الصفحة. في الوقت نفسه ، من الواضح أنه يجب توسيع الحل ، وهناك حاجة إلى واجهة برمجة التطبيقات للتعاون على العميل والخادم.
لقد وجدنا أننا بدا أننا بحاجة إلى صندوق أدوات أكبر أثناء إجراءات البحث المختلفة. في معظم بيئات المكونات ، مثل Microsoft & Reg ؛ لحسن الحظ ، هناك ميراث سحري في Microsoft & Reg ؛
يتم تنفيذ معظم هذه الضوابط في BaseValidator الوالدين العامين. يمكنك أيضًا إكمال مهام مختلفة من BaseValidator أو ضوابط أخرى. في الواقع ، حتى لو كان BaseValidator كسولًا جدًا لتحقيق سمات النص الخاصة به ، فهو موروث من سمات الملصقات.
متى يحدث؟
من الفعال للغاية فهم تسلسل الحدث عند معالجة الصفحة التي تحتوي على صفحة عنصر تحكم الويب. إذا كانت حالة التحقق اختيارية ، فأنت بحاجة إلى فهم بدقة عندما يتم التحقق من العميل والخادم. إذا كنت ترغب في كتابة روتين التحقق بنفسك ، فقد يكون الوقت الوقت -استغراق أو آثار جانبية. في الوقت نفسه ، من المهم أيضًا فهم توقيت استدعاء روتين التحقق.
أولاً ، دعنا نلقي نظرة على الخادم.
تسلسل التحقق على جانب الخادم
من المهم أن نفهم فترة صحة الصفحة. إذا كنت معتادًا على معالجة النموذج في Visual Basic أو أدوات العميل الوظيفية المماثلة ، فأنت بحاجة إلى قضاء وقت معين لفهمه. جميع الكائنات في الصفحة والصفحة ليست فعالة عند التفاعل مع المستخدمين ، على الرغم من أن هذا هو نفسه في بعض الأحيان.
فيما يلي تسلسل حدث مبسط عند زيارة صفحة لأول مرة:
قم بإنشاء صفحة وعنصرها بناءً على ملف ASPX.
تشغيل حدث Page_Load.
يتم تخزين سمات الصفحة والتحكم في حقل مخفي.
يتم تحويل الصفحات والضوابط إلى HTML.
تجاهل كل شيء.
الآن ، عندما ينقر المستخدم على زر أو عنصر تحكم مماثل ، فسوف يعود إلى الخادم ثم ينفذ تسلسل حدث مماثل. يسمى هذا التسلسل تسلسل الإرجاع:
قم بإنشاء صفحة وعنصرها بناءً على ملف ASPX.
استعادة سمات الصفحة والتحكم من الحقل المخفي.
أدخل التحكم في صفحة التحديث وفقًا للمستخدم.
تشغيل حدث Page_Load.
يغير المشغل أحداث الإخطار.
يتم تخزين سمات الصفحة والتحكم في حقل مخفي.
يتم تحويل الصفحات والضوابط إلى HTML.
تجاهل كل شيء مرة أخرى.
لماذا لا نحتفظ بجميع الكائنات في الذاكرة؟ لأن مواقع الويب التي تم إنشاؤها مع ASP+ لا يمكنها التعامل مع عدد كبير جدًا من المستخدمين. لذلك ، تحتفظ ذاكرة الخادم فقط بالمحتوى المطلوب معالجته على الفور.
متى يتم التحقق من الخادم على جانب الخادم؟ عند الحصول على معلومات الصفحة لأول مرة ، لن يتم إجراء التحقق من جانب الخادم على الإطلاق. معظم المستخدمين النهائيين خطيرة للغاية.
في تسلسل حدث الإرجاع ، سيتم إجراء التحقق بين الخطوة 3 والخطوة 4. بمعنى آخر ، يكون التحقق بعد سمات التحكم في تحميل البيانات من المستخدم ، ولكن قبل معظم عدد تنفيذ التعليمات البرمجية. هذا يعني أنه عند كتابة أحداث المستخدم ، يمكن استخدامه عادةً للتحقق. في ظل الظروف العادية ، سترغب في القيام بذلك.
عيب التحقق في تلك اللحظة هو: إذا كنت ترغب في تعديل بعض السمات التي تؤثر على التحقق من خلال البرمجة ، فسيكون الوقت قد فات. على سبيل المثال ، ستجد أنه إذا كنت تستخدم الرمز لتمكين أو تعطيل سمات التحكم في التحقق أو تعديل عنصر التحكم في التحقق ، فلن ترى أي تأثير قبل معالجة الصفحة. يمكن تجنب هذه المشكلة من خلال الطريقتين التاليتين:
تعديل السمة قبل التحقق.
إعادة التحكم في التحكم بعد تغيير السمة.
تحتاج كلتا الطريقتين إلى استخدام سمات التحقق والتحقق الفعالة على كائن الصفحة.
صفحة API
تتضمن كائنات الصفحة بعض السمات والأساليب المهمة المتعلقة بالتحقق من الخادم. يلخص الجدول 1 هذه السمات والأساليب:
الجدول 1. سمات وطرق كائن الصفحة
وصف السمة أو الطريقة
السمة isValid هي السمة الأكثر فائدة. يمكن لهذه السمة التحقق مما إذا كان النموذج بأكمله فعالًا. عادة ما يتم إجراء هذا الشيك قبل تحديث قاعدة البيانات. فقط جميع كائنات المدققين صالحة ، السمة صحيحة ، ولا يتم تخزين القيمة في ذاكرة التخزين المؤقت.
يعزو المدققون جمع جميع كائنات التحقق من هذه الصفحة. هذه مجموعة من الكائنات التي تنفذ واجهة ivalidator.
تستدعي طريقة القيمة طريقة عند التحقق. تتمثل طريقة التنفيذ الافتراضية في كائن الصفحة في التحول إلى كل جهاز التحقق وتتطلب من جهاز التحقق لتقييم نفسه.
مجموعة المدققين مفيدة للغاية للعديد من المهام. هذه المجموعة عبارة عن مجموعة من الكائنات التي تنفذ واجهة ivalidator. السبب في استخدام الكائن ليس هو التحكم في عنصر التحكم لأن كائن الصفحة يولي فقط الانتباه إلى واجهة ivalidator. نظرًا لأن جميع التحديات تستخدم عادةً لتحقيق بعض عناصر التحكم البصرية لـ Ivalidator ، يجب أن يكون أي شخص قادرًا على استخدام أي كائن التحقق وإضافة كائن التحقق إلى الصفحة.
تحتوي واجهة ivalidator على السمات والطرق التالية:
الجدول 2. سمات وطرق واجهة ivalidator
وصف السمة أو الطريقة
أشارت السمة isValid إلى ما إذا كان اختبار الصلاحية الذي يتم إجراؤه بواسطة كائن التحقق المنفصل قد مرت. يمكنك تغيير القيمة يدويًا بعد التحقق.
تقدم سمة errormessage الخطأ للتحقق من الكائن المراد التحقق منه والأخطاء التي قد يتم عرضها على المستخدم.
يتم فحص طريقة التحقق من صحة لصلاحية كائن التحقق لتحديث قيمة ISValid الخاصة به.
يمكنك استخدام هذه الواجهة لأداء بعض المهام المثيرة للاهتمام. على سبيل المثال ، لإعادة ضبط الصفحة إلى حالة فعالة ، استخدم الكود التالي (مثل المثال الموضح في C#):
قيمة aliversator ؛
foreach (val في المدققين) {
valueValid = true ؛
}
لإعادة تنفيذ تسلسل التحقق بأكمله ، استخدم الكود التالي:
قيمة aliversator ؛
foreach (val في المدققين) {
Val.Validate () ؛
}
إذا كان لديك إصدار بيتا 1 أو إصدارات أعلى ، فيمكنك أيضًا استدعاء طريقة القيمة لكائن الصفحة فقط ، بحيث يمكن إكمال المهمة نفسها. لإجراء بعض التغييرات قبل التحقق ، يمكن تغطية طريقة القيمة. يعرض هذا المثال صفحة تحتوي على جهاز التحقق ، والذي يتم فتحه أو إيقافه وفقًا لقيمة خانة الاختيار:
الطبقة العامة الشرطية: صفحة {
HtmlinputCheckbox العام ؛
ResearchFieldValidator Rfvalshipaddress ؛
Void Void محمي Void Void () {) {)
// فقط تحقق من عنوان التسليم (إذا كان مختلفًا عن عنوان الدفع)
BOOL ENABLESHIP =!
rfvalshipaddress.endabled = enableShip ؛
// تنفيذ التحقق الآن
base.validate () ؛
}
}
التحقق من العميل
إذا تم تمكين صفحتك عن طريق التحقق من العميل ، فسيحدث تسلسل حدث مختلف تمامًا خلال الرحلة ذهابًا وإيابًا. يستخدم التحقق من العميل Jscript & Reg ؛ لا يتطلب التحقق من أي مكونات ثنائية.
على الرغم من أن توحيد لغة JScript يتم بشكل جيد ، فإن نموذج كائن المستند (DOM) المستخدم في وثائق HTML في المتصفح (DOM) لم يستخدم على نطاق واسع. لذلك ، يتم إجراء التحقق من العميل فقط في Internet Explorer 4.0 والإصدارات العليا ، لأن الكائن الذي تم التحقق منه هو Internet Explorer DOM.
من منظور الخادم ، يعني التحقق من العميل فقط أن عنصر التحكم في التحقق يرسل محتوى مختلفًا إلى HTML. بالإضافة إلى ذلك ، تسلسل الحادث هو نفسه بالضبط. لا يزال يتم إجراء فحص جانب الخادم. على الرغم من أنها تبدو زائدة عن الحاجة ، إلا أنها مهمة للغاية لأن:
قد لا تدعم بعض عناصر التحكم في التحقق نص العميل. هناك مثال جيد: إذا كنت تريد استخدام وظائف التحقق من CustomValidator و Server في نفس الوقت ، ولكن لا توجد وظيفة التحقق من العميل.
احتياطات السلامة. يمكن لبعض الأشخاص الحصول بسهولة على صفحة تحتوي على نص ، ثم تعطيل أو تغيير الصفحة. يجب ألا تستخدم البرنامج النصي الخاص بك لمنع البيانات السيئة من إدخال نظامك ، ولكن فقط للمستخدمين للحصول على ملاحظات أسرع. لذلك ، إذا كنت ترغب في استخدام CustomValIdator ، فيجب عدم توفير وظيفة التحقق من العميل دون وظائف التحقق من الخادم المقابلة.
يمكن أن يضمن كل عنصر تحكم التحقق في إرسال كتلة البرنامج النصي العميل القياسية إلى الصفحة. في الواقع ، هذا مجرد جزء صغير من الكود ، والذي يحتوي على إشارة إلى الكود في مكتبة البرنامج النصي webuivalidation.js. يحتوي ملف مكتبة البرنامج النصي على جميع المنطق الذي تم التحقق منه من قبل العميل.
حول مكتبة السيناريو
نظرًا لأن التحقق من البرنامج النصي للتحكم في الويب موجود في مكتبة البرنامج النصي ، فإن الكود الذي تم التحقق منه من قبل جميع العملاء ليس ضروريًا لإرساله مباشرة إلى الصفحة ، على الرغم من أنه يبدو أنه يتم على السطح. تشبه مراجع ملف البرنامج النصي الرئيسي ما يلي:
<لغة البرنامج النصي = javaScript
SRC =/_ ASPX/1.0.9999/script/webuivalidation.js> </script>
بشكل افتراضي ، سيتم تثبيت ملف البرنامج النصي في دليل الجذر الافتراضي في دليل _aspx ، ويستخدم البرنامج النصي يتضمن تعليمات ليتم استدعاؤها ، والتي تبدأ بخط قطري إيجابي. يوضح المرجع أن كل كائن فردي لا يحتاج إلى تضمين مكتبة البرنامج النصي ، ويمكن لجميع الصفحات على نفس الكمبيوتر الرجوع إلى نفس الملف. ستلاحظ أن هناك أيضًا رقم إصدار لغة عامة في هذا المسار ، بحيث يمكن تشغيل إصدارات وقت التشغيل المختلفة على نفس الكمبيوتر.
إذا نظرت إلى دليل الجذر الافتراضي الخاص بك ، فستجد الملف وعرض المحتوى. يتم تحديد موضع هذه الملفات في ملف config.web. ملف config.web هو ملف XML لمعظم إعدادات ASP+. فيما يلي تعريف الموضع في هذا الملف:
<WebControls
clientiprtslocation =/_ aspx/{0}/script/
/>
شجعك على قراءة البرنامج النصي حتى تتمكن من فهم الأحداث التي تحدث بعمق. ومع ذلك ، يوصى بعدم تعديل هذه البرامج النصية ، لأن وظائفها مرتبطة ارتباطًا وثيقًا بإصدارات وقت تشغيل محددة. عند تحديث الإصدار ، قد تحتاج أيضًا إلى تحديث البرامج النصية وفقًا لذلك. إذا كان يجب تغيير مشاريع محددة ، فقم أولاً بالنسخ الاحتياطي لهذه البرامج النصية ، ثم قم بإشارة مشروعك إلى ملف النسخ الاحتياطي ، فإن الطريقة هي استخدام ملف config.web خاص لاستبدال موضع هذه الملفات. إذا كانت السلسلة تحتوي على أمر التنسيق {0} ، فسيحل رقم الإصدار محل التعليمات عندما يتم استبدال رقم إصدار وقت التشغيل. من الأفضل تغيير هذا الموقف إلى مرجع نسبي أو إشارة مطلقة.
تعطيل التحقق من العميل
في بعض الأحيان قد لا ترغب في التحقق من العملاء. إذا كان عدد حقول الإدخال صغيرة ، فقد لا يكون التحقق من العميل مفيدًا للغاية. بعد كل شيء ، يجب أن يكون لديك منطق يتطلب خادمًا مستديرًا واحدًا في كل مرة. ستجد أن المعلومات الديناميكية على العميل سيكون لها تأثير سلبي على تخطيطك.
لتعطيل التحقق من العميل ، استخدم Page Errugle ClientTarget = downlevel. تشبه هذه التعليمات بداية ملف ASPX:
<٪@page language = c# clienttarget = downlevel ٪>
القيمة الافتراضية لهذا التعليم هي تلقائي ، مما يشير إلى أنك تتحقق فقط من عميل Microsoft Internet Explorer 4.0 أو إصدارات أعلى.
ملاحظة: لسوء الحظ ، في بيتا 1 ، لا يتم تعطيل هذه التعليمات فقط للتحقق ، وفي الوقت نفسه ، تستخدم جميع عناصر التحكم في الويب HTML 3.2 لعمليات المعالجة ، والتي قد يكون لها نتائج غير متوقعة. توفر النسخة النهائية طريقة أفضل للتحكم في هذه المشكلة.
تسلسل حدث العميل
هذا التسلسل هو تسلسل حدث يحدث عندما يكون الصفحة التي تحتوي على التحقق من العميل:
عند تحميل المتصفح على الصفحة ، تحتاج إلى تهيئة كل عنصر تحكم التحقق. يتم إرسال عناصر التحكم هذه كعلامة <span> ، وميزات HTML الخاصة بها الأقرب إلى الميزات الموجودة على الخادم. الأهم من ذلك ، سيتم "شنق" جميع عناصر الإدخال المشار إليها بواسطة جهاز التحقق في هذا الوقت. سيعدل عنصر الإدخال المشار إليه حدث عميله للاتصال بروتين التحقق عند إدخال التغيير.
سيتم تنفيذ الرمز الموجود في مكتبة البرنامج النصي عندما يستخدم المستخدم مفتاح TAB للتبديل بين كل حقل. عند تغيير حقل مستقل معين ، سيتم إعادة تقييم شروط التحقق ، وسيكون جهاز التحقق مرئيًا أو غير مرئي حسب الحاجة.
عندما يحاول المستخدم إرسال النموذج ، سيتم تقييم جميع التحقيقات. إذا كانت كل هذه التحقق فعالة ، فسيتم إرسال النموذج إلى الخادم. إذا كان هناك خطأ في مكان واحد أو أكثر ، فسيحدث الموقف التالي:
تم إلغاء التقديم. لا يتم تقديم النموذج إلى الخادم.
جميع التحقيقات غير صالحة مرئية.
إذا كان ملخص التحقق يحتوي على displars summary = صحيح ، فسيتم جمع جميع الأخطاء من التحكم في التحقق ويتم تحديث المحتوى بهذه الأخطاء.
إذا كان ملخص التحقق يحتوي على ShowMessageBox = صحيح ، فسيقوم بجمع الأخطاء وعرض هذه الأخطاء في مربع معلومات العميل.
لأنه يتم تنفيذ التحكم في التحقق من العميل عند الدخول أو متى. يرجى ملاحظة أنه بعد التقديم ، ستظل ضوابط التحقق هذه إعادة تقييم على الخادم.
واجهة برمجة تطبيقات العميل
هناك واجهة برمجة تطبيقات صغيرة يمكن استخدامها على العميل لتحقيق تأثيرات مختلفة في رمز العميل الخاص بك. نظرًا لأنه لا يمكن إخفاء بعض الروتين ، من الناحية النظرية ، يمكنك استخدام العميل للتحقق من جميع المتغيرات والخصائص والوظائف المحددة من قبل العميل. ومع ذلك ، يمكن تغيير الكثير منهم. ما يلي يلخص كائن العميل الذي نشجعك على استخدامه.
الجدول 3. كائن العميل
وصف نوع الاسم
أشار Page_isvalid Boolean إلى ما إذا كانت الصفحة صالحة حاليًا. التحقق من البرامج النصية دائما الحفاظ على المتغير الأحدث.
Page_Validator Element Array هذه صفيف يحتوي على جميع التحقيقات في الصفحة.
تشير Page_ValidationActive Boolean إلى ما إذا كان ينبغي التحقق منها. يمكنك إثبات هذا المتغير على FALSE من خلال البرمجة.
يعزى ISValid Boolen كل جهاز التحقق من العميل لديه الخاصية ، مشيرًا إلى ما إذا كان جهاز التحقق صالحًا حاليًا. يرجى ملاحظة أنه في إصدار PDC ، يتم خلط هذه السمة مع isValid.
تجاوز التحقق من العميل
تتمثل إحدى المهام التي تحتاجها في كثير من الأحيان في إضافة زر "إلغاء" أو زر التنقل في الصفحة. في هذه الحالة ، حتى لو كانت هناك أخطاء في الصفحة ، فقد ترغب أيضًا في استخدام الزر لإرسال الصفحة. نظرًا لأن حدث زر العميل يحدث قبل حدث OnSubmit للنموذج ، فقد يتجنب تقديم الفحص وتجاوز التحقق. يوضح ما يلي كيفية استخدام التحكم في صورة HTML كزر "إلغاء" لإكمال المهمة:
<نوع الإدخال = صورة الصورة = الخادم
القيمة = إلغاء
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 عناصر التحكم هي الأمثلة.
تأثير خاص
متطلبات شائعة أخرى هو أنه بالإضافة إلى معلومات الخطأ التي يعرضها جهاز التحقق نفسه ، هناك حاجة إلى بعض التأثيرات الأخرى. في هذه الحالة ، يجب تنفيذ أي تعديل تقوم بإجراءه في نفس الوقت على الخادم أو العميل. لنفترض أنك بحاجة إلى إضافة ملصق لتغيير اللون وفقًا لما إذا كان الإدخال صالحًا. فيما يلي كيفية تنفيذ هذه المهمة على الخادم:
الطبقة العامة changeColorpage: صفحة {
العلامة العامة lblzip ؛
قيمة RegulaxPressionvalidator العامة ؛
تجاوز الفراغ المحمي (eventArgs e) {{
lblzip.forecolor = valzip.isvalid؟
}
}
جميع الطرق المذكورة أعلاه مثالية ، ولكن طالما قمت بتعديل التحقق أعلاه ، ستجد أنه ما لم تنفذ نفس العملية على العميل ، فستبدو غير متسقة للغاية. سيسمح لك إطار التحقق من تجنب العديد من هذه التأثيرات المزدوجة ، ولكن لا يمكنه تجنب التأثيرات الأخرى التي يجب تحقيقها في نفس الوقت على العميل والخادم. ما يلي عبارة عن جزء يؤدي نفس المهمة على العميل:
<ASP: Label ID = LBLZIP Runat = Server
النص = الرمز البريدي:/>
<ASP: TextBox ID = Txtzip Runat = Server
onChange = txtziponchange () ؛
<asp: undaterxpressionvalididator id = valzip runat = server
ControlTovalidate = txtzip
errormessage = رمز بريدي غير صالح
التحقق من الصحة = [0-9] {5} /> <br>
<لغة البرنامج النصي = javaScript>
دالة txtziponchange () {{) {
// إذا لم يكن التحقق من العميل في النشاط ، فلن يؤدي أي عملية
IFOF (page_validators) == غير محددة) العودة ؛
// تغيير لون الملصق
lblzip.style.color = valzip.isvalid؟
}
</script>
BETA 1 API Client API
بالنسبة إلى الإصدار التجريبي 1 ، فإن بعض الوظائف التي يمكن استدعاؤها من نص العميل ستتسبب في مواقف أخرى.
الجدول 4. وظيفة من مكالمة نص العميل
وصف الاسم
يستخدم ValitatorValidate (VAL) جهاز التحقق من العميل كمدخل. اجعل جهاز التحقق تحقق من الإدخال الخاص به وتحديث شاشة العرض الخاصة به.
Edativeatorenable (VAL ، Enable) الحصول على جهاز التحقق من العميل وقيمة منطقية. تمكين أو تعطيل جهاز التحقق من العميل. إذا تم تعطيله ، فلن يتم تقييم جهاز التحقق من العميل ، وسيكون مدقق العميل دائمًا صالحًا.
حصل ValitatorHookupControl (التحكم ، VAL) على عنصر HTML إدخال وجهاز التحقق من العميل. تعديل أو إنشاء حدث تغيير العنصر بحيث يمكن تحديث جهاز التحقق أثناء التغيير. هذه الوظيفة مناسبة للتحققات المخصصة بناءً على قيم إدخال متعددة.
غرضه الخاص هو تمكين أو تعطيل جهاز التحقق. إذا كنت ترغب في التحقق من أنك تدخل في ظروف محددة فقط ، فقد تحتاج إلى تغيير حالة التنشيط في نفس الوقت على الخادم والعملاء ، وإلا ستجد أنه لا يمكن للمستخدم إرسال الصفحة.
فيما يلي المثال أعلاه بالإضافة إلى الحقل.
الطبقة العامة الشرطية: صفحة {
HtmlinputCheckbox العام ؛
ResearchFieldValidator Rfvalshipaddress ؛
Void Void محمي Void Void () {) {)
BOOL ENABLESHIP =!
rfvalshipaddress.endabled = enableShip ؛
base.validate () ؛
}
}
فيما يلي رمز العميل المكافئ:
<نوع الإدخال = مربع الاختيار runat = معرف الخادم = chksameas
onclick = onchangesameas () ؛> نفس عنوان الدفع <br>
<لغة البرنامج النصي = javaScript>
وظيفة onchangesameas () {
var entleship =!
Valitatorenable (rfvalshipaddress ، enableship) ؛
}
</script>
قواعد فعالة ومعلومات خطأ مفيدة
يعرض كل جهاز التحقق معلومات خطأ محددة حول شروط محددة في عناصر تحكم محددة. هناك بعض القواعد التي تؤكد ما إذا كانت صالحة في البداية.
تعتبر جميع التحقيقات الفارغة (باستثناء مطلوب FieldValidator) صالحة. إذا كانت القيمة الفارغة غير صالحة ، فعادة ما تحتاج إلى مطلوب FieldValidator ومرحى آخر. تحتاج إلى القيام بذلك ، لأنه بشكل عام ، تريد دائمًا إظهار معلومات خطأ مختلفة على جهاز التحقق الفارغ والفعالية. يمكنك أيضًا استخدام معلومات غير واضحة ، مثل "يجب إدخال قيمة ، ويجب أن تتراوح هذه القيمة بين 1 و 10".
ترتبط قواعد خاصة أخرى تستخدم عندما لا يمكن تحويل حقل الإدخال إلى نوع بيانات محدد بـ CompareValidator و RangeValidator. تحدد عملية تقييم الصلاحية لـ comparevalidator of ControlTocompare أن عملية تقييم الصلاحية كما هو موضح أدناه:
إذا كان حقل الإدخال المشار إليه بواسطة ControlTovalidate فارغًا ، فهو فعال.
إذا كان لا يمكن تحويل حقل الإدخال المشار إليه بواسطة ControlTovalidate إلى نوع البيانات المطلوب ، فهو غير صالح.
إذا كان لا يمكن تحويل حقل الإدخال المشار إليه بواسطة ControlTocompare إلى نوع البيانات المطلوب ، فسيكون صحيحًا.
يتم تحويل حقل الإدخال إلى نوع البيانات المطلوب والمقارنة.
الخطوة الثالثة تبدو غير متسقة بعض الشيء. والسبب في ذلك هو أنه إذا فحص جهاز التحقق من فعالية الحقول المتعددة في نفس الوقت ، فمن الصعب كتابة معلومات خطأ ذات معنى لجهاز التحقق. يجب استخدام جهاز التحقق المستقل للإبلاغ عن حالة الخطأ في حقل إدخال ControlTocompare. يحتوي RangeValidator على طرق عمل مماثلة ، مع الحد الأقصى والحد الأدنى من الخصائص.
وظائف تمكين ومرئية وعرض الخصائص
قد لا يكون الفرق بين خصائص التمكين والمرئية والعرض لجهاز التحقق واضحًا للغاية.
Display = لا يمكن استخدام أي شيء لتحديد أن جهاز التحقق لا يعرض أي محتوى مباشرة ، ولكن لا يزال يقييم ، لا يزال يؤثر على الفعالية الكلية ، ولا يزال بإمكانه وضع الأخطاء في ملخص العميل والخادم. للتحقق من العميل ، يتم تحديد هذه القيم لاستخدام خصائص النمط المرئي أو استخدام خصائص نمط العرض لفتح أو إغلاق جهاز التحقق. بالنسبة للتحقق من الخادم ، يعني العرض = الديناميكي أن الإدخال لا يعرض أي محتوى عندما يكون الإدخال صالحًا ، ويمثل العرض = ثابت مساحة لا تتغير. سيتم طي الإعداد الأخير في عدم وجود محتوى عندما تكون الخلية التي تحتوي على جهاز التحقق فقط في الجدول صالحة.
لماذا لا تستخدم فقط مرئيًا = خطأ لجعل جهاز التحقق مرئيًا؟ في ASP+، فإن السمة المرئية لعنصر التحكم لها العديد من المعاني: لن تتم معالجة أو عرض السيطرة على مرئي = false على الإطلاق. ويرجع ذلك بالتحديد إلى هذا المعنى بأن مرئيًا = خطأ لجهاز التحقق يعني أنه لا يعرض أي محتوى فحسب ، بل لا يمكن استخدامه أيضًا. لن يتم تقييم جهاز التحقق هذا ، ولن يؤثر على صحة الصفحة ، ولن يتم وضعه في الملخص.
التمكين محايد. في معظم الحالات ، يكون تأثير التمكين = false و disible = false هو نفسه بالضبط. في الإصدار التجريبي 1 أو الإصدار الأعلى ، هناك فرق مهم: في التحقق من العميل ، سيظل جهاز التحقق المعاق يرسل إلى المتصفح ، لكنه في حالة معطلة. يمكنك استخدام وظيفة Valitatorenable في البرنامج النصي العميل لتنشيط جهاز التحقق.
عند استخدام مرئي أو تمكين للتحكم في ما إذا كان يجب التحقق ، انتبه إلى ترتيب الطلب على الخادم أعلاه. أو التغيير قبل التحقق ، أو إعادة تحديد بعد التغيير. خلاف ذلك ، لن تعكس قيمها Isvalid التغييرات على السمات.
CustomValidator التحكم
أسهل طريقة لتوسيع إطار التحقق هي استخدام التحكم في CustomValidator. يمكن استخدام عنصر التحكم هذا لإجراء عمليات التحقق التي لا يمكن تنفيذ عناصر تحكم التحقق الأخرى ، ولكن يمكنها أيضًا تنفيذ عمليات التحقق التي تحتاج إلى الوصول إلى المعلومات على الخادم (مثل قواعد البيانات أو خدمات الويب).
إذا تمت إضافة CustomValidator مع وظيفة التحقق من خادم واحدة فقط ، فستلاحظ أن جهاز التحقق لا يشارك في التحقق من العميل. عندما يتم تبديل المستخدم بين كل حقل باستخدام مفتاح TAB ، فلن يتم تحديث CustomValidator ، ويحتاج خادم trip المستدير إلى إجراء التحقق منه في وقت واحد. إذا كنت ترغب في استخدام CustomValIdator لإجراء فحص لا يتطلب أي معلومات على الخادم ، فيمكنك أيضًا استخدام خاصية ClientValidationFunction لجعل جهاز التحقق يشارك تمامًا في التحقق من العميل. لنفترض أنك توفر ClientValidationFunction. ولكن في الواقع ، فهو مجرد جزء من التحقق. لا يتجاوز التحقق من وظيفة التحقق من العميل التحقق من التنفيذ على الخادم لأن المتسللين يمكنهم بسهولة تجاوز وظيفة التحقق.
فيما يلي مثال بسيط على استخدام CustomValidator على العميل والخادم ، فقط تحقق مما إذا كان الإدخال متساويًا. دعنا نقدم وظيفة الخادم (في C#):
{الخدمة الجزئية) {الموضع
يحاول {
int i = int.fromString (value) ؛
العودة ((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 (value ، 10) ؛
إذا (Isnan (Val))
العودة كاذبة
العودة ((Val ٪ 2) == 0) ؛
}
//->
</script>
فيما يلي بعض الاحتياطات باستخدام CustomValidator:
على غرار جميع عناصر التحكم في التحقق الأخرى (باستثناء مطلوب FieldValidator) ، إذا كان حقل الإدخال فارغًا ، يُعتبر أن CustomValidator فعال.
إذا تم استخدام المتصفح الأقدم أو تم إغلاق التحقق من العميل ، فلا يمكن استدعاء وظيفة التحقق من العميل. قبل تحديد الوظيفة ، لا يتعين عليك التحقق من وظيفة المتصفح المستخدم في المتصفح ، ولكن تحتاج إلى التأكد من أن المتصفح لا يسبب أخطاء نصية بسبب التعريف. تأكد من جعل رمز العميل الخاص بك بمثابة تعليق توضيحي لـ HTML ، كما هو موضح في المثال التالي.
يتم تمرير معلمتين إلى وظيفة العميل الخاصة بك وتتوافق مع المعلمات التي تم تمريرها إلى وظيفة الخادم. الأول هو عنصر جهاز التحقق من العميل ، والثاني هو قيمة التحكم المحددة بواسطة ControlTovalidate. ومع ذلك ، على العميل ، يمكنك اختيار عدم تحديد المعلمات للوظيفة ، والتي ستعمل بشكل طبيعي.
إذا كنت تستخدم إصدارات Beta1 أو أعلى ، فيمكنك الحفاظ على ControlTovalidate فارغًا. في هذا الوضع ، ستؤدي وظيفة الخادم دائمًا إلى تشغيل رحلة ذهابًا وإيابًا مستديرة ، وسيتم دائمًا تشغيل وظيفة العميل في كل مرة تحاول إرسالها. يمكنك استخدام هذه الميزة للتحقق من عناصر التحكم التي لا يمكن التحقق منها ، مثل قائمة CheckBoxList أو أزرار الراديو المنفصلة. إذا كانت الحالة تعتمد على عناصر تحكم متعددة ، ولا تريد أن يقوم المستخدم بتقييم الحالة عند التبديل بين كل حقل في الصفحة ، يمكنك استخدام هذه الطريقة.
خيار آخر في الإصدار التجريبي 1 أو أعلى هو حدث تغيير عناصر تحكم متعددة. تتمثل الطريقة في إضافة بعض البرامج النصية المدمجة التي تستدعي دالة العميل ValitatorHookupControl ، كما هو موضح أعلاه.
ما هي الضوابط التي يمكن التحقق منها؟
لتمكين التحكم في مرجع التحكم ، يجب أن يكون عنصر التحكم قد تم التحقق منه. تحتوي جميع عناصر التحكم التي تم التحقق منها على خصائص ValidentPropertyAttribute ، والتي تشير إلى السمة التي يجب قراءتها أثناء التحقق. إذا قمت بكتابة جهاز التحكم الخاص بك ، فيمكنك تحديد السمات المراد استخدامها من خلال توفير واحدة منها ، بحيث يكون التحكم في التحقق.
لتمكين التحقق من تنفيذ العميل بشكل طبيعي ، يجب أن تتوافق السمة مع خصائص القيمة لعنصر HTML الذي يعرضه العميل. لا تستحق العديد من عناصر التحكم المعقدة (مثل بيانات البيانات والتقويم) العميل ولا يمكن التحقق منها إلا على الخادم. لذلك ، فقط يتحكم الأقرب في عناصر HTML يمكن المشاركة في التحقق. بالإضافة إلى ذلك ، يجب أن يكون للتحكم قيمة منطقية واحدة على العميل. لذلك ، يمكن التحقق من RadiObuttonList ، ولكن لا يمكن لـ CheckBoxList.
نهاية
قد يكون التفسير المذكور أعلاه لـ ASP+ التحقق قد تجاوز المحتوى الذي تريد فهمه. استمتع بها!
------------------------------------------------- ------------------------------------------------- ------------------------
يرجى استخدام IE4.0 أعلاه الإصدار 800 * 600 مشاهدة على هذا الموقع
& Copy ؛ الحفاظ على الملكية. استخدام اللوائح.
اجمع رمز التأثير الخاص الأكثر عمليًا لصفحة الويب!