الصفحة الرئيسية / مشاكل/ المتهور التحقق من صحة php. تم التحقق من صحتها ، والتحقق من صحتها ... والتحقق من صحتها! مقارنة مدققي البيانات في PHP

التحقق المتهور php. تم التحقق من صحتها ، والتحقق من صحتها ... والتحقق من صحتها! مقارنة مدققي البيانات في PHP

من الضروري للغاية أن يتم التحقق من صحة الإدخال في النموذج الخاص بك قبل أخذ بيانات إرسال النموذج لمزيد من المعالجة. عندما يكون هناك العديد من الحقول في النموذج ، يصبح النص البرمجي للتحقق من صحة PHP معقدًا للغاية. نظرًا لأنك تقوم بنفس التحقق من الصحة أو ما شابه ذلك لمعظم النماذج التي تقوم بها ، يتم إنفاق الكثير من الجهد المكرر على عمليات التحقق من صحة النموذج.

حول هذا البرنامج النصي العام للتحقق من صحة نموذج PHP

هذا البرنامج النصي العام لأداة التحقق من صحة نموذج PHP يجعل من السهل جدًا إضافة عمليات التحقق إلى النموذج الخاص بك.

نقوم بإنشاء وربط مجموعة من "واصفات التحقق" مع كل عنصر في النموذج. "واصف التحقق" عبارة عن سلسلة تحدد نوع التحقق المطلوب إجراؤه. على سبيل المثال ، "req" تعني "مطلوب" ، وتعني "alpha" السماح فقط بالأحرف الأبجدية وما إلى ذلك.

يمكن أن يحتوي كل حقل في النموذج على صفر أو واحد أو أكثر من عمليات التحقق من الصحة. على سبيل المثال ، يجب ألا يكون الإدخال فارغًا ، ويجب أن يكون أقل من 25 حرفًا ، ويجب أن يكون أبجديًا رقميًا ، إلخ

يمكنك إقران مجموعة من واصفات التحقق لكل حقل إدخال في النموذج.

قم بتنزيل البرنامج النصي للتحقق من صحة نموذج PHP

يمكنك تنزيل البرنامج النصي للتحقق من صحة نموذج PHP أدناه:
يحتوي الملف المضغوط على formvalidator.php النصي للتحقق من صحة النموذج والوثائق ونماذج الاستخدام.

استخدام البرنامج النصي للتحقق من صحة نموذج PHP

قم بتضمين formvalidator.php في البرنامج النصي لمعالجة النموذج الخاص بك
قم بإنشاء كائن FormValidator وأضف واصفات التحقق من صحة النموذج.

الوسيطة الأولى هي اسم حقل الإدخال في النموذج. الوسيطة الثانية هي واصف التحقق الذي يخبر نوع التحقق المطلوب. الوسيطة الثالثة هي رسالة الخطأ التي سيتم عرضها في حالة فشل التحقق من الصحة.

تحقق من صحة النموذج عن طريق استدعاء دالة ValidateForm ()

أخطاء التحقق من الصحة:

inpname $: inp_err

مثال

المثال أدناه سيجعل الفكرة أكثر وضوحًا

addValidation ("الاسم" ، "طلب" ، "الرجاء ملء الاسم") ؛ Validator-> addValidation ("Email" ، "email" ، "إدخال البريد الإلكتروني يجب أن يكون قيمة بريد إلكتروني صالحة") ؛ Validator-> addValidation ("Email"، "req"، "Please fill in Email")؛ إذا ($ validator-> ValidateForm ()) (echo "

تم التحقق بنجاح!

"؛ $ show_form = false؛) else (echo" أخطاء التحقق من الصحة:"؛ $ error_hash = $ validator-> GetErrors ()؛ foreach ($ error_hash كـ $ inpname => $ inp_err) (echo"

inpname $: inp_err

\ n "؛))) إذا (صحيح == $ show_form) (؟>

إضافة التحقق المخصص

إذا كنت تريد إضافة تحقق مخصص لم يتم توفيره بواسطة واصفات التحقق ، يمكنك القيام بذلك. فيما يلي الخطوات:

قم بإنشاء فئة للتحقق المخصص وتجاوز وظيفة DoValidate ()

يمتد class MyValidator إلى CustomValidator (الوظيفة DoValidate (& $ formars، & $ error_hash) (if (stristr ($ formars ["Comments"]، "http: //")) ($ error_hash ["Comments"] = "لا عناوين URL مسموح بها في التعليقات "؛ إرجاع خطأ ؛) إرجاع صحيح ؛))

أضف كائن التحقق المخصص

المدقق $ = new FormValidator ()؛ $ validator-> addValidation ("Name"، "req"، "Please fill in Name")؛ Validator-> addValidation ("Email" ، "email" ، "إدخال البريد الإلكتروني يجب أن يكون قيمة بريد إلكتروني صالحة") ؛ Validator-> addValidation ("Email"، "req"، "Please fill in Email")؛ $ custom_validator = new MyValidator ()؛ المدقق $-> AddCustomValidator ($ custom_validator) ؛

سيتم استدعاء وظيفة التحقق المخصصة تلقائيًا بعد عمليات التحقق الأخرى.

جدول واصفات التحقق

فيما يلي قائمة بجميع واصفات التحقق:

واصف التحقق	إستعمال
مطلوب	يجب ألا يكون الحقل فارغًا
maxlen = ؟؟؟	يتحقق من طول البيانات المدخلة إلى الحد الأقصى. على سبيل المثال ، إذا كان الحد الأقصى للحجم المسموح به هو 25 ، فامنح واصف التحقق مثل "maxlen = 25"
مينلين = ؟؟؟	يتحقق من طول السلسلة التي تم إدخالها إلى الحد الأدنى المطلوب. مثال "minlen = 5"
alnum	تحقق من البيانات إذا كانت تحتوي على أي أحرف أخرى بخلاف الأحرف الأبجدية أو الرقمية
alnum_s	يسمح فقط بالأحرف الأبجدية والرقمية والمسافات
الأس	تحقق من البيانات الرقمية
ألفا	تحقق من البيانات الأبجدية.
alpha_s	تحقق من البيانات الأبجدية واسمح بمسافات.
البريد الإلكتروني	الحقل عبارة عن حقل بريد إلكتروني وتحقق من صحة البيانات.
لتر = ؟؟؟ ليسثان = ؟؟؟	تحقق من البيانات لتكون أقل من القيمة التي تم تمريرها. صالحة فقط للحقول الرقمية. مثال: إذا كانت القيمة يجب أن تكون أقل من 1000 ، فاذكر وصف التحقق على النحو التالي "lt = 1000"
GT = ؟؟؟ أكبر من = ؟؟؟	تحقق من البيانات لتكون أكبر من القيمة التي تم تمريرها. صالحة فقط للحقول الرقمية. مثال: إذا كانت القيمة يجب أن تكون أكبر من 10 ، فاذكر وصف التحقق على النحو التالي "gt = 10"
regex = ؟؟؟	تحقق باستخدام تعبير عادي من أن القيمة يجب أن تتطابق مع التعبير العادي. مثال: يسمح "regexp = ^ (1،20) $" بما يصل إلى 20 حرفًا أبجديًا.
لا تختار = ؟؟	واصف التحقق هذا مخصص لعناصر الإدخال المحددة (القوائم) عادةً ، تحتوي مربعات القائمة المختارة على عنصر واحد يقول "اختر واحدًا". يجب على المستخدم تحديد خيار آخر غير هذا الخيار. إذا كان القيمةمن هذا الخيار "Select One" ، يجب أن يكون وصف التحقق "dontselect = Select One"
لايختلط	واصف التحقق هذا مخصص لخانات الاختيار. يجب على المستخدم عدم تحديد خانة الاختيار المحددة. قم بتوفير القيمةمن خانة الاختيار بدلاً من ؟؟ على سبيل المثال ، dontselectchk = on
ينبغيسيلشك	واصف التحقق هذا مخصص لخانات الاختيار. يجب على المستخدم تحديد خانة الاختيار المحددة. أدخل قيمة خانة الاختيار بدلاً من ؟؟ على سبيل المثال ، shouldselchk = on
لا تشغل بالكهرباء	واصف التحقق هذا مخصص لأزرار الاختيار. يجب على المستخدم عدم تحديد زر الاختيار المحدد. أدخل قيمة زر الاختيار بدلاً من ؟؟ على سبيل المثال ، dontselectradio = NO
سيليكتراديو	واصف التحقق هذا مخصص لأزرار الاختيار. يجب على المستخدم تحديد زر الاختيار المحدد. أدخل قيمة زر الاختيار بدلاً من ؟؟ على سبيل المثال ، selectradio = نعم
selmin = ؟؟	حدد على الأقل عدد n من خانات الاختيار من مجموعة خانات الاختيار. على سبيل المثال: selmin = 3
سلوني	يجعل مجموعة الراديو إلزامية. يجب على المستخدم تحديد عنصر واحد على الأقل من مجموعة الراديو.
eqelmnt = ؟؟؟	قارن بين عنصرين في النموذج وتأكد من تطابق القيمتين على سبيل المثال ، "كلمة المرور" و "تأكيد كلمة المرور". استبدال ؟؟؟ باسم عنصر الإدخال الآخر. على سبيل المثال: eqelmnt = Confirm_pwd

في المقالة السابقة ، وعدت بكتابة مقارنة لمكتبتي الخاصة مع الحلول الأخرى المتاحة ، لذلك سننظر اليوم في التحقق من الصحة باستخدام Aura.Filter و Respect Validation و Sirius Validation و Valitron.

لنتخيل أن لدينا نوعًا من الخدمة العامة قيد التطوير ، والتي تتضمن تسجيل المستخدمين للوصول الكامل إلى جميع الوظائف. وبالتالي ، سيحتوي نموذج التسجيل على الحقول التالية:

اسم.يجب أن يحتوي على كلمتين بالضبط ، حيث تكون الأولى هي الاسم الأول للمستخدم والثانية هي الاسم الأخير.
تسجيل الدخول.إذا تم تمرير قيمة ، فيجب أن تحتوي فقط على أحرف لاتينية وواصلات وشرطات سفلية.
البريد الإلكتروني.يجب أن يحتوي على عنوان بريد إلكتروني صالح.
كلمه السر.يجب تثبيته وألا يزيد طوله عن 64 حرفًا.
متفق عليه.مربع اختيار نموذجي يجب على المستخدم التحقق منه لتأكيد موافقته على شروط الخدمة.

لذلك ، لدينا خمسة حقول يجب على المستخدم إكمالها من أجل التسجيل في خدمتنا التخيلية. لنتخيل أننا تلقينا بيانات غير صالحة تمامًا كإدخال:

$ data = ["name" => "Albert" ، // يجب أن تكون كلمتين "تسجيل الدخول" => "lbert" ، // "Forbidden" character @ "email" => "شيء خاطئ" ، / / يجب أن يكون هذا يكون البريد الإلكتروني "password" =>

هالة

التحقق من الصحة باستخدام Aura: يبدأ الفلتر بمصنع الفلتر. نحتاج إلى إنشاء ما يسمى ب "مرشح الموضوع" ، لأننا سنقوم بالتحقق من مصفوفة ، وليس قيمة فردية.

تحديد القواعد

استخدم Aura \ Filter \ FilterFactory ؛ مرشح $ = (عامل تصفية جديد) -> newSubjectFilter () ؛ $ filter-> validate ("name") -> isNotBlank () -> is ("two_words") -> setMessage ("الاسم يجب أن يكون كلمتين.")؛ $ filter-> validate ("login") -> isBlankOr ("alnum") -> setMessage ("إذا قمت بتحديد تسجيل دخول ، يجب أن يحتوي على أحرف لاتينية فقط.") ؛ $ filter-> validate ("email") -> isNotBlank () -> is ("email") -> setMessage ("الرجاء إدخال عنوان بريد إلكتروني صالح.")؛ مرشح $-> التحقق من صحة ("كلمة المرور") -> isNotBlank () -> هو ("strlenMax"، 64) -> setMessage ("الرجاء إدخال كلمة المرور.")؛ مرشح $-> التحقق ("موافق") -> هو ("رد الاتصال" ، الوظيفة (الموضوع $ ، الحقل $) (إرجاع $ subject -> ($ field) === true ؛)) -> setMessage ("أنت بحاجة الموافقة على شروط الخدمة. ") ؛

كما ترى ، فإن وصف القواعد بسيط للغاية. يوفر Aura.Filter مجموعة كاملة من القواعد المفيدة خارج الصندوق ، وقد تم استخدام بعضها في المثال أعلاه:

طريقة isNotBlank.يحدد أن الحقل لا يمكن أن يكون فارغًا.
alnum.تسمح هذه القاعدة بالأحرف اللاتينية فقط.
البريد الإلكتروني.وهذا واضح :)
سترلين ماكس.يحدد أن الحقل لا يمكن أن يتجاوز الطول المحدد بواسطة الوسيطة الثانية للطريقة is.
أتصل مرة أخرى.يشبه هذا النوع من القواعد عمليات الإغلاق من Kontrolio. يسمح لك بتعريف القاعدة كإغلاق. في هذا الإغلاق ، تقوم Aura.Filter بتمرير "الموضوع" ، واتفقنا على مجموعة البيانات الخاصة بنا من النموذج ، والحقل ، في هذه الحالة.

ربما لاحظت أنني لم أحدد قاعدة كلمتين. بطبيعة الحال ، لا توجد مثل هذه القاعدة في الهالة ، الفلتر ، لذلك نحن بحاجة إلى إنشائها. كما تقول الوثائق ، يتم ذلك من خلال فئة منفصلة للقاعدة:

/ ** * القاعدة التي تتحقق من صحة اسم المستخدم. * يتكون اسم المستخدم من كلمتين: الاسم الأول واسم العائلة ، مفصولة بمسافة واحدة. * / class UserNameRule (/ ** * التحقق من اسم المستخدم. * *param object | المصفوفة $ subject *param string $ field *param int $ max * *return bool * / public function __invoke ($ subject، $ field ، $ max = null) (القيمة $ = $ subject -> ($ field)؛ if (! is_scalar ($ value)) (إرجاع false؛) إرجاع (bool) preg_match ("/ ^ + \ s + $ / u"، قيمة $) ؛))

الخطوة الثانية هي السماح لمصنع الفلتر بمعرفة قاعدتنا الجديدة. يتم ذلك عن طريق تمرير الوسيطة الأولى كمصفوفة من القواعد إلى مصنع المرشح:

الخطوة التالية هي إخطار Aura ، فلتر أننا أنشأنا قاعدة جديدة ونريد استخدامها. يتم ذلك عن طريق تمرير مجموعة من القواعد إلى وسيطة المصنع الأولى:

استخدم Aura \ Filter \ FilterFactory ؛ قواعد $ = ["two_words" => function () (إرجاع قاعدة اسم المستخدم الجديدة ؛)] ؛ عامل التصفية $ = (new FilterFactory ($ rules)) -> newSubjectFilter () ؛

يمكن الآن استخدام قاعدة كلمتين تمامًا مثل أي قاعدة أخرى من التوزيع القياسي.

استجابة

كما تتذكر ، فإن بيانات الإدخال التي نقوم بالتحقق منها غير صالحة تمامًا ، لأن كل حقل يحتوي على قيمة غير صحيحة أو لا يحتوي عليها على الإطلاق. لذلك ، من المفترض أنه نتيجة التحقق من الصحة ، سوف نتلقى أخطاء ورسائل مقابلة عنها.

نحن نتحقق مع Aura ، قم بالتصفية على النحو التالي:

$ valid = مرشح $-> تطبيق ($ data) ؛ إذا (! $ valid) (فشل $ = مرشح $-> getFailures () ؛ رسائل $ = فشل $-> getMessages () ؛)

في رسائل $تمت كتابة المصفوفة ، لذلك نحتاج إلى اثنين من العناصر المتداخلة لعرض الرسائل:

أخطاء $) (foreach (أخطاء $ كـ $ error) (printf (""، $ error)؛))؟>

التحقق من صحة الاحترام

المكتبة الثانية التي استخدمتها في المقارنة هي حل شائع نسبيًا يسمى التحقق من صحة الاحترام. نظرًا لأن الناس يثقون بها ، أعتقد أن هناك شيئًا يمكن رؤيته هناك.

من أجل نقاء التجربة ، عند مقارنة المكتبات ، سنستخدم نفس مجموعة البيانات المحددة في البداية:

استخدم Respect \ Validation \ Validator كـ v ؛ $ data = ["name" => "Albert" ، // يجب أن تكون كلمتين "تسجيل الدخول" => "lbert" ، // "Forbidden" character @ "email" => "شيء خاطئ" ، / / يجب أن يكون هذا أن تكون "كلمة مرور" بريد إلكتروني => "" // لا توجد كلمة مرور على الإطلاق // "موافق" ليس في المصفوفة لأن المستخدم لم يحدد المربع] ؛

تحديد القواعد

كما هو الحال مع Aura.Filter ، نحتاج إلى قاعدة التحقق الخاصة بنا من اسم المستخدم ، لذلك لنبدأ بذلك:

مساحة الاسم MyNamespace ؛ استخدم Respect \ Validation \ Rules \ AbstractRule ؛ تقوم class UserNameRule بتوسيع AbstractRule (التحقق من صحة الوظيفة العامة ($ input) (إرجاع (bool) preg_match ("/ ^ + \ s + $ / u"، $ input)؛))

تتطابق واجهة برمجة التطبيقات للقواعد الخارجية تقريبًا مع Aura.Filter ، فقط الطريقة التحقق من صحة ()بدلا من السحر __يستحضر().بدا لي ، واجهة برمجة التطبيقات هذه ، أكثر بساطة ومفهومة. حسنًا ، إنها أقرب إلى Kontrolio :)

لم أجد أي ذكر لهذا في الوثائق ، ومع ذلك ، بالإضافة إلى القاعدة نفسها ، من الضروري إنشاء نوع خاص من الاستثناء لها. يجب أن يتكون اسم فئة الاستثناء من اسم فئة القاعدة و postfix استثناء.

استخدام Respect \ Validation \ exceptions \ NestedValidationException ؛ تمدد فئة UserNameRuleException NestedValidationException (//)

أخيرًا ، يمكننا التحقق من صحة بياناتنا. أولاً ، نقوم بتمرير قاعدتنا الجديدة إلى المدقق حتى يعرف عنها ، حتى نتمكن من استخدامها في المستقبل. في التحقق من الاحترام ، يتم ذلك عن طريق استدعاء الطريقة مع()مع نقل مساحة الاسم حيث توجد القواعد غير القياسية.

v :: with ("MyNamespace \\") ؛

الآن جميع القواعد غير القياسية الموجودة في مساحة الاسم mynamespace، سيتم "تحديدها" بواسطة المدقق. الخطوة التالية هي وصف القواعد المطلوبة وإجراء التحقق من الصحة.

v :: attribute ("name"، v :: userNameRule ()) -> سمة ("login"، v :: alnum ("-_")) -> سمة ("email"، v :: email ()) -> السمة ("password" ، v :: notEmpty () -> stringType () -> length (null، 64)) -> سمة ("موافق" ، v :: trueVal ()) -> تأكيد ((كائن) بيانات $) ؛

لاحظ كيف نطبق قاعدتنا على السمة اسم. هنا تم تحويل اسم فئة القاعدة إلى اسم طريقة المدقق. باقي القواعد بشكل عام بديهية.

بشكل منفصل ، تجدر الإشارة إلى سبب إحضار المصفوفة بيانات دولارللكائن. الحقيقة هي أن التحقق من صحة الاحترام يأخذ الكائنات كمدخلات وليس مصفوفات. يجب أن يؤخذ ذلك في الاعتبار عند تطوير استخدام هذه المكتبة.

استجابة

على عكس Aura.Filter ، يطرح مدقق الاحترام استثناءً عندما يفشل التحقق من الصحة. ويحتوي هذا الاستثناء على رسائل خطأ تتعلق بالتحقق من الصحة. لذلك ، يجب كتابة المثال الموضح للتو على النحو التالي:

جرب (v :: with ("RespectValidationExample \\")؛ v :: attribute ("name"، v :: userNameRule ()) -> سمة ("login"، v :: alnum ("-_")) - > السمة ("email"، v :: email ()) -> السمة ("password"، v :: notEmpty () -> stringType () -> length (null، 64)) -> سمة ("مُتفق عليها" ، v :: trueVal ()) -> تأكيد ((كائن) $ data) ؛) catch (NestedValidationException $ ex) (رسائل $ = $ ex-> getMessages () ؛)

استخدام getMessages ()، سوف نحصل على مصفوفة ثابتة من جميع الرسائل التي جمعها المدقق أثناء عملية التحقق من الصحة. بإلقاء المصفوفة ، نحصل على شيء مثل هذا:

array (5) (=> string (29) "فشل التحقق من صحة البيانات لـ٪ s" => سلسلة (60) "يجب أن يحتوي تسجيل الدخول على أحرف (a-z) وأرقام (0–9) و“ -_ ”=> سلسلة (25) "يجب أن يكون البريد الإلكتروني بريدًا إلكترونيًا صالحًا" => سلسلة (26) "يجب ألا تكون كلمة المرور فارغة" => سلسلة (32) "السمة المتفق عليها يجب أن تكون موجودة")

يمكنك تغيير الرسائل إلى رسائلك الخاصة. ربما أساء فهم هذه المكتبة بطريقة ما ، لكن هذه العملية لم تبدو واضحة جدًا بالنسبة لي: تحتاج إلى استخدام الطريقة findMessages ()في استثناء تمت معالجته حيث تحدد الرسائل ليس للسمات ولكن للقواعد.

$ ex-> findMessages (["userNameRule" => "يجب أن يكون اسم المستخدم كلمتين."، "alnum" => "لا نحب اسم المستخدم الخاص بك."، "email" => "من الواضح أنك لا تريد ذلك أعطنا بريدك الإلكتروني. "،" notEmpty "=>" أين كلمة المرور الخاصة بك؟ "،" موافق "=>" آسف لأنك لا توافق. "])؛

لا أعرف ما هو الخطأ ، لكن هناك بعض الأشياء التي ما زلت لا أفهمها. هذا ما نحصل عليه من خلال تحديد القواعد بالطريقة أعلاه:

array (5) (=> string (40) "يجب أن يكون اسم المستخدم كلمتين." => سلسلة (31) "نحن لا نحب اسم المستخدم الخاص بك." => سلسلة (25) "يجب أن يكون البريد الإلكتروني صالحًا" => سلسلة (5) "أين كلمة المرور الخاصة بك؟" => سلسلة (9) "آسف لأنك غير موافق.")

كما ترى ، لم يتم تطبيق الرسالة الخاصة بحقل البريد الإلكتروني ، وبقيت الرسالة القياسية. لكن الرسالة وراء الفهرس 4 هي عكس ذلك! وهذا بالرغم من حقيقة أنني لم أستخدم اسم القاعدة بل اسم الحقل. بينما إذا استخدمت اسم القاعدة (trueVal) ، فسوف تضيع رسالتي في مكان ما. نرحب بتعليقات المستخدمين المتمرسين في هذه المكتبة.

التحقق من صحة Sirius

حسنًا ، دعنا ننتقل إلى المكتبة التالية ونرى كيف تتعامل مع المهام المماثلة.

تحديد القواعد

مرة أخرى ، نحتاج إلى تحديد قاعدة لاسم المستخدم. سنكتبه شيئًا مثل هذا:

تمدد فئة UserNameRule AbstractRule (// Error messages const MESSAGE = "اسم المستخدم يجب أن يكون كلمتين." ؛ const LABELED_MESSAGE = "(التسمية) يجب أن تكون كلمتين." ؛ التحقق من صحة الوظيفة العامة (القيمة $ ، $ valueIdentifier = فارغة) (إرجاع ( bool) preg_match ("/ ^ + \ s + $ / u"، $ value) ؛))

انتبه إلى الاختلاف في الأساليب مقارنة بالمكتبات التي تم النظر فيها بالفعل. نحدد نوعين من الرسائل في الثوابت بدلاً من استخدام الخصائص أو الطرق أو وسيطات القاعدة.

الآن دعنا نصف منطق التحقق:

المدقق $ = المدقق الجديد؛ المدقق $ -> إضافة ("الاسم" ، "مطلوب | MyApp \ Validation \ Rule \ UserNameRule") -> إضافة ("تسجيل الدخول" ، "مطلوب | alphanumhyphen" ، فارغ ، "يمكن أن يحتوي تسجيل الدخول فقط على أحرف لاتينية وشرطات وشرطات سفلية. ") -> إضافة (" بريد إلكتروني "،" مطلوب | بريد إلكتروني "، فارغ ،" الرجاء إدخال بريد إلكتروني صالح. ") -> إضافة (" كلمة المرور "،" مطلوب | maxlength (64) "، فارغ ،" الخاص بك كلمة المرور ، سيدي. ") -> إضافة (" موافق "،" مطلوب | يساوي (صحيح) "، فارغ ،" لماذا لم توافق؟ ") ؛

كما ترى ، فإن مجموعة القواعد بسيطة للغاية ويمكن قراءتها. للأوصاف ، نستخدم أسماء مفصولة بشرطة أفقية. هذا النهج مشابه لتلك المستخدمة من قبل Laravel و Kontrolio.

حجة الطريقة الرابعة يضيف()يصف رسالة خطأ التحقق من الصحة التي يستخدمها Sirius في حالة فشل التحقق. لماذا لم نضيف رسالة لقاعدتنا الجديدة UserNameRule?

$ validator-> add ("name"، "required | MyApp \ Validation \ Rule \ UserNameRule")

هذا لأن الرسائل موصوفة بالفعل في ثوابت الفئة:

تمدد فئة UserNameRule AbstractRule (// Error messages const MESSAGE = "يجب أن يكون اسم المستخدم كلمتين." ؛ ...

خيار آخر هو استخدام طريقة addMessage () الخاصة بالمدقق نفسه:

Validator-> addMessage ("بريد إلكتروني" ، "الرجاء إدخال بريد إلكتروني صالح.")؛

لاحظ أن القواعد المخصصة يتم تحديدها من خلال الاسم الكامل لفئتها ، بينما في Kontrolio يمكنك تعيين اسم مستعار / اسم مستعار.

استجابة

لإجراء التحقق ، نسمي طريقة المدقق التحقق من صحة ()، تمرير البيانات إليه:

على عكس الاحترام ، لن يطرح Sirius استثناءً ، بل سيعود ببساطة خاطئة. يمكن استلام رسائل خطأ التحقق من الصحة عبر طريقة المدقق getMessages (). يقوم بإرجاع أخطاء مجمعة حسب السمة ، لذلك نحن بحاجة إلى حلقتين لكل منهما للتكرار خلال الأخطاء:

foreach ($ validator-> getMessages () as $ attribute => $ messages) (foreach (رسائل $ كـ $ message) (صدى $ message-> getTemplate (). "\ n" ؛))

هنا $ message هو كائن فئة Sirius \ Validation \ ErrorMessageالتي لها طريقة getTemplate ()، والتي تُرجع الرسالة ذاتها التي نحتاجها.

فاليترون

تحديد القواعد

الاختلاف الأول هو أنك لست بحاجة إلى إنشاء فئة منفصلة لإضافة قاعدة جديدة. يمكنك ببساطة استخدام الإغلاق الذي يعرض نتيجة منطقية.

هناك طريقة ثابتة لإضافة قواعد مخصصة إلى Valitron addRule ()، حيث تكون الوسيطتان الأوليان مطلوبتين والثالثة اختيارية. لقد أحببت هذه الطريقة ، لأنه هنا يتم الإشارة إلى معرف القاعدة والمنطق ورسالة الخطأ في مكان واحد في وقت واحد.

استخدام Valitron \ Validator ؛ Validator :: addRule ("two_words"، function ($ field، $ value) (return (bool) preg_match ("/ ^ + \ s + $ / u"، $ value)؛)، "يجب أن يكون اسم المستخدم كلمتين بالضبط . ") ؛

الاختلاف الثاني هو كيفية تطبيق القواعد على السمات. في جميع الحالات السابقة ، رأينا أن السمة ، كما كانت ، هي شيء أساسي.

ذهب Valitron في الاتجاه الآخر ووضع قواعد التحقق في المقام الأول. عند وصف القواعد ، يمكنك تطبيق سمات على هذه القواعد ، وليس العكس.

المدقق $ = المدقق الجديد (بيانات $) ؛ $ Validator -> rule ("two_words"، "name") -> label ("") -> قاعدة ("مطلوب" ، ["اسم" ، "تسجيل دخول" ، "بريد إلكتروني" ، "كلمة مرور" ، "متفق عليه"] ) -> القاعدة ("slug"، "login") -> القاعدة ("email"، "email") -> القاعدة ("Accept"، "Agreement") ؛

كما ترون من المثال ، في الطريقة قاعدة()نكتب أولاً اسم القاعدة ، وعندها فقط نحدد السمات التي يجب أن تتطابق مع هذه القاعدة. من الأمثلة الأكثر وضوحًا القاعدة المطلوبة ، والتي توضح كيف "تنتمي" السمات إلى القاعدة.

يوفر Valitron (مثل الحلول الأخرى التي نظرنا إليها) رسائل خطأ قياسية. إذا كنت تستخدمها فقط ، فسترى أن كل رسالة تبدأ باسم السمة المقابلة.

يستبدل Valitron أسماء السمات في نص الرسالة حتى عند استخدام رسائل خطأ غير قياسية. لهذا السبب استخدمنا طريقة label () بسلسلة فارغة لإزالة اسم السمة.

$ validator-> rule ("two_words"، "name") -> label ("")

استجابة

على وجه التحديد ، فيما يتعلق بالتحقق من الصحة ، لا تختلف واجهة برمجة تطبيقات مكتبة Valitron عمليًا عما رأيناه بالفعل في المقالة. لإجراء التحقق ، نسمي طريقة المدقق التحقق من صحة ():

Validator-> validate () ؛

يمكن الحصول على رسائل خطأ التحقق من الصحة باستخدام الطريقة getErrors ():

Validator-> errors () ؛

يتم تجميع الرسائل هنا حسب السمات بنفس الطريقة تمامًا كما في Sirius Validation ، باستثناء أنه لا توجد فئة منفصلة للرسالة ، ونحصل على مصفوفة منتظمة متعددة الأبعاد.

foreach (validator $-> errors () كـ $ attribute => $ messages) (foreach (رسائل $ كـ $ message) (echo $ message. "\ n" ؛))

مراقبة

وأخيرًا ، المكتبة الأخيرة لليوم هي مكتبة التطوير الخاصة بي والتي تسمى Kontrolio.

تحديد القواعد

مرة أخرى ، للمرة الخامسة ، سننشئ قاعدة تحقق من صحة اسم المستخدم. كل شيء بسيط نسبيًا وقياسي:

مساحة الاسم MyProject \ Validation \ Rules ؛ استخدم Kontrolio \ Rules \ AbstractRule ؛ تمدد فئة TwoWords Kontrolio \ Rules \ AbstractRule (الوظيفة العامة صالحة ($ input = null) (return (bool) preg_match ("/ ^ + \ s + $ / u"، $ input)؛))

الآن نقوم بإنشاء مصنع وتسجيل القاعدة فيه باستخدام الطريقة تمديد():

مساحة الاسم MyProject ؛ استخدام التحكم \ المصنع ؛ استخدم MyProject \ Validation \ Rules \ TwoWords ؛ $ factory = Kontrolio \ Factory :: getInstance () -> extension () ؛

بعد تسجيل القاعدة ، يمكننا استخدامها ، بما في ذلك بالاسم - two_words. لنقم بإنشاء مدقق:

$ data = ["name" => "Albert" ، // يجب أن تكون كلمتين "تسجيل الدخول" => "lbert" ، // "Forbidden" character @ "email" => "شيء خاطئ" ، / / يجب أن يكون هذا أن تكون "كلمة مرور" بريد إلكتروني => "" // لا توجد كلمة مرور على الإطلاق // "موافق" ليس في المصفوفة لأن المستخدم لم يحدد المربع] ؛ $ rules = ["name" => "two_words"، "login" => "أحيانًا | alphadash"، "email" => "email" ، "password" => "length: 1،64" ، "موافق" = > "مقبولة"] ؛ $ messages = ["name" => "يجب أن يتكون اسم المستخدم الخاص بك من كلمتين."، "login" => "نحن لا نحب تسجيل الدخول الخاص بك."، "email" => "من الواضح أنك لا تريد إعطائنا عنوان بريدك الإلكتروني. "،" password "=>" إذن أين كلمة مرورك؟ "،" موافق "=>" آسف لأنك لا توافق. " ] ؛ Validator = $ factory-> make (بيانات $ ، قواعد $ ، رسائل $) ؛

لقد وصفنا القواعد باستخدام صيغة مشابهة لتلك المستخدمة في Laravel ، على الرغم من أنه كان بإمكاننا استخدام إصدار أكثر تفصيلاً:

$ rules = ["name" => new TwoWords، "login" =>، "email" => بريد إلكتروني جديد ، "password" => new Length (1، 64)، "Agreement" => new Accepted]؛

استجابة

بدأ التحقق من الصحة بنفس الطريقة التحقق من صحة ():

Validator-> validate () ؛

الآن يمكننا الحصول على رسائل خطأ باستخدام إحدى الطرق getErrors ()أو getErrorsList (). تسمح الطريقة الأولى بإخراج خطأ أكثر تعقيدًا ، بينما تقوم الطريقة الثانية بإرجاع مصفوفة مسطحة. استخدام getErrors ()يمكننا إخراج رسائل مثل هذا:

أ مع getErrorsList ()يمكنك عمل قائمة أبسط من الرسائل:

getErrorsList () ، ؟>

حصيلة

في هذه المقالة ، عرضت أمثلة على استخدام المكتبات التالية:

هالة
التحقق من صحة الاحترام
التحقق من صحة Sirius
فاليترون
مراقبة

قد يبدو "مثال العالم الحقيقي" بسيطًا جدًا. يجب أن أوافق ، لأنه ، في الواقع ، تم استبعاد بعض ميزات المكتبات من المقالة. من حيث المبدأ ، إذا كنت مهتمًا ، يمكنك دراسة ميزاتها بنفسك.

تقدم كل مكتبة شرائحها الخاصة ، ولها جوانبها المظلمة الخاصة بها ، لذلك أعتقد أنها مسألة ذوق ومهمة - اختيار المناسب.

شكرا للقراءة. اتخذ الاختيار الصحيح.

العلامات:

تأكيد صحة البيانات
بي أتش بي
ركوب الدراجات

اضف اشارة

اسم.يجب أن يحتوي على كلمتين بالضبط ، حيث تكون الأولى هي الاسم الأول للمستخدم والثانية هي الاسم الأخير.
تسجيل الدخول.إذا تم تمرير قيمة ، فيجب أن تحتوي فقط على أحرف لاتينية وواصلات وشرطات سفلية.
البريد الإلكتروني.يجب أن يحتوي على عنوان بريد إلكتروني صالح.
كلمه السر.يجب تثبيته وألا يزيد طوله عن 64 حرفًا.
متفق عليه.مربع اختيار نموذجي يجب على المستخدم التحقق منه لتأكيد موافقته على شروط الخدمة.

هالة

تحديد القواعد

طريقة isNotBlank.يحدد أن الحقل لا يمكن أن يكون فارغًا.
alnum.تسمح هذه القاعدة بالأحرف اللاتينية فقط.
البريد الإلكتروني.وهذا واضح :)
سترلين ماكس.يحدد أن الحقل لا يمكن أن يتجاوز الطول المحدد بواسطة الوسيطة الثانية للطريقة is.
أتصل مرة أخرى.يشبه هذا النوع من القواعد عمليات الإغلاق من Kontrolio. يسمح لك بتعريف القاعدة كإغلاق. في هذا الإغلاق ، تقوم Aura.Filter بتمرير "الموضوع" ، واتفقنا على مجموعة البيانات الخاصة بنا من النموذج ، والحقل ، في هذه الحالة.

يمكن الآن استخدام قاعدة كلمتين تمامًا مثل أي قاعدة أخرى من التوزيع القياسي.

استجابة

نحن نتحقق مع Aura ، قم بالتصفية على النحو التالي:

$ valid = مرشح $-> تطبيق ($ data) ؛ إذا (! $ valid) (فشل $ = مرشح $-> getFailures () ؛ رسائل $ = فشل $-> getMessages () ؛)

في رسائل $تمت كتابة المصفوفة ، لذلك نحتاج إلى اثنين من العناصر المتداخلة لعرض الرسائل:

أخطاء $) (foreach (أخطاء $ كـ $ error) (printf (""، $ error)؛))؟>

التحقق من صحة الاحترام

من أجل نقاء التجربة ، عند مقارنة المكتبات ، سنستخدم نفس مجموعة البيانات المحددة في البداية:

تحديد القواعد

كما هو الحال مع Aura.Filter ، نحتاج إلى قاعدة التحقق الخاصة بنا من اسم المستخدم ، لذلك لنبدأ بذلك:

استخدام Respect \ Validation \ exceptions \ NestedValidationException ؛ تمدد فئة UserNameRuleException NestedValidationException (//)

v :: with ("MyNamespace \\") ؛

استجابة

التحقق من صحة Sirius

حسنًا ، دعنا ننتقل إلى المكتبة التالية ونرى كيف تتعامل مع المهام المماثلة.

تحديد القواعد

مرة أخرى ، نحتاج إلى تحديد قاعدة لاسم المستخدم. سنكتبه شيئًا مثل هذا:

الآن دعنا نصف منطق التحقق:

$ validator-> add ("name"، "required | MyApp \ Validation \ Rule \ UserNameRule")

هذا لأن الرسائل موصوفة بالفعل في ثوابت الفئة:

تمدد فئة UserNameRule AbstractRule (// Error messages const MESSAGE = "يجب أن يكون اسم المستخدم كلمتين." ؛ ...

خيار آخر هو استخدام طريقة addMessage () الخاصة بالمدقق نفسه:

Validator-> addMessage ("بريد إلكتروني" ، "الرجاء إدخال بريد إلكتروني صالح.")؛

استجابة

لإجراء التحقق ، نسمي طريقة المدقق التحقق من صحة ()، تمرير البيانات إليه:

foreach ($ validator-> getMessages () as $ attribute => $ messages) (foreach (رسائل $ كـ $ message) (صدى $ message-> getTemplate (). "\ n" ؛))

هنا $ message هو كائن فئة Sirius \ Validation \ ErrorMessageالتي لها طريقة getTemplate ()، والتي تُرجع الرسالة ذاتها التي نحتاجها.

فاليترون

تحديد القواعد

$ validator-> rule ("two_words"، "name") -> label ("")

استجابة

Validator-> validate () ؛

يمكن الحصول على رسائل خطأ التحقق من الصحة باستخدام الطريقة getErrors ():

Validator-> errors () ؛

foreach (validator $-> errors () كـ $ attribute => $ messages) (foreach (رسائل $ كـ $ message) (echo $ message. "\ n" ؛))

مراقبة

وأخيرًا ، المكتبة الأخيرة لليوم هي مكتبة التطوير الخاصة بي والتي تسمى Kontrolio.

تحديد القواعد

مرة أخرى ، للمرة الخامسة ، سننشئ قاعدة تحقق من صحة اسم المستخدم. كل شيء بسيط نسبيًا وقياسي:

الآن نقوم بإنشاء مصنع وتسجيل القاعدة فيه باستخدام الطريقة تمديد():

بعد تسجيل القاعدة ، يمكننا استخدامها ، بما في ذلك بالاسم - two_words. لنقم بإنشاء مدقق:

$ rules = ["name" => new TwoWords، "login" =>، "email" => بريد إلكتروني جديد ، "password" => new Length (1، 64)، "Agreement" => new Accepted]؛

استجابة

بدأ التحقق من الصحة بنفس الطريقة التحقق من صحة ():

Validator-> validate () ؛

أ مع getErrorsList ()يمكنك عمل قائمة أبسط من الرسائل:

getErrorsList () ، ؟>

حصيلة

في هذه المقالة ، عرضت أمثلة على استخدام المكتبات التالية:

هالة
التحقق من صحة الاحترام
التحقق من صحة Sirius
فاليترون
مراقبة

شكرا للقراءة. اتخذ الاختيار الصحيح.

العلامات: أضف علامات

يأتي Laravel مع نظام تحقق بسيط ومريح (يفحص بيانات الإدخال وفقًا للقواعد) ويستقبل رسائل خطأ - فئة Validation.

أبسط مثال على التحقق من الصحة

$ validator = Validator :: make (array ("name" => "Dale") ، صفيف ("name" => "required | min: 5")) ؛

المعلمة الأولى التي تم تمريرها إلى التابع make هي البيانات المراد فحصها. المعلمة الثانية هي القواعد التي ينبغي تطبيقها عليهم.

استخدام المصفوفات لتحديد القواعد

يمكن فصل القواعد المتعددة إما بشريط أمامي (|) أو أن تكون عناصر صفيف منفصلة.

$ validator = Validator :: make (array ("name" => "Dale") ، صفيف ("name" => array ("required"، "min: 5"))) ؛

التحقق من صحة الحقول المتعددة

$ validator = Validator :: make (array ("name" => "Dale"، "password" => "bad password"، "email" => " [بريد إلكتروني محمي]") ، صفيف (" الاسم "=>" مطلوب "،" كلمة المرور "=>" مطلوب | الحد الأدنى: 8 "،" البريد الإلكتروني "=>" مطلوب | بريد إلكتروني | فريد ")) ؛

بمجرد إنشاء نسخة Validator ، يمكن استخدام طريقة الفاشلة (أو النجاحات) لإجراء التحقق من الصحة.

إذا ($ validator-> fails ()) (// فشل التحقق من صحة البيانات المنقولة)

إذا عثر المدقق على أخطاء ، فيمكنك الحصول على رسائله على النحو التالي:

رسائل $ = المدقق $-> رسائل () ؛

يمكنك أيضًا الحصول على مجموعة من القواعد التي فشلت في التحقق بدون الرسائل نفسها:

فشل $ = المدقق $-> فشل () ؛

فحص الملفات

تحتوي فئة Validator على عدة قواعد أولية للتحقق من صحة الملفات ، مثل الحجم ، والتمثيل الصامت ، وغيرها. لإجراء التحقق من صحة الملفات ، ما عليك سوى نقل هذه الملفات مع البيانات الأخرى.

ربط بعد التحقق من الصحة

يمكن لـ Laravel ، بعد اكتمال التحقق ، تشغيل وظيفة الإغلاق ، حيث يمكنك ، على سبيل المثال ، التحقق من شيء خاص أو إضافة نوع من رسائل الخطأ الخاصة بك. يتم ذلك باستخدام طريقة after ():

Validator = Validator :: make (...)؛ $ validator-> after (function ($ validator) (if ($ this-> somethingElseIsInvalid ()) ($ validator-> errors () -> add ("field"، "هناك خطأ في هذا الحقل!") ؛) )) ؛ إذا ($ validator-> fails ()) (//)

يمكنك إضافة متعددة بعد s إذا لزم الأمر.

التحقق من صحة وحدات التحكم

كتابة رمز التحقق الكامل في كل مرة تحتاج فيها إلى التحقق من صحة البيانات أمر غير مريح. لذلك ، يوفر Laravel عدة حلول لتبسيط هذا الإجراء.

تشتمل وحدة التحكم الأساسية App \ Http \ Controllers \ Controller على سمة ValidatesRequests ، والتي تحتوي بالفعل على طرق التحقق من الصحة:

/ ** * احفظ منشور المدونة. * *param Request $ request *return Response * / public function store (Request $ request) ($ this-> تحقق ($ request، ["title" => "required | unique | max: 255"، "body" => "مطلوب" ،]) ؛ //)

إذا تم التحقق من الصحة ، فسيستمر تشغيل الكود. إذا لم يكن كذلك ، فسيتم إلقاء Illuminate \ Contracts \ Validation \ ValidationException. إذا لم تلتقط هذا الاستثناء ، فسوف يلتقطه الإطار ، ويملأ متغيرات الفلاش برسائل خطأ التحقق من الصحة ، ويوجه المستخدم إلى الصفحة السابقة بالنموذج - نفسه!

في حالة طلب AJAX ، لا توجد إعادة توجيه ، يقوم إطار العمل بإرجاع استجابة برمز HTTP 422 و JSON مع أخطاء التحقق من الصحة.

الكود أعلاه مشابه لهذا:

/ ** * احفظ منشور المدونة. * *param Request $ request *return Response * / public function store (Request $ request) ($ v = Validator :: make ($ request-> all ()، ["title" => "required | unique | max : 255 "،" body "=>" required "،])؛ if ($ v-> fails ()) (إرجاع إعادة التوجيه () -> back () -> withErrors ($ v-> errors ()) ؛) //)

تغييرات تنسيق الخطأ

إذا كنت ترغب في تخصيص رسائل خطأ التحقق من الصحة المخزنة في متغيرات فلاش الجلسة على عمليات إعادة التوجيه ، فتجاوز طريقة formatValidationErrors في وحدة التحكم الخاصة بك:

/ ** * (inheritdoc) * / تنسيق الوظيفة المحمية

طلب التحقق

لسيناريوهات التحقق الأكثر تعقيدًا ، قد يكون ما يسمى بطلبات النموذج مناسبًا لك. هذه فئات طلبات HTTP خاصة تحتوي على منطق التحقق من الصحة. يقومون بمعالجة الطلب قبل وصوله إلى وحدة التحكم.

لإنشاء فئة طلب ، استخدم الأمر make: request:

جعل الحرفي php: طلب StoreBlogPostRequest

سيتم إنشاء الفصل في مجلد التطبيق / Http / الطلبات. أضف قواعد التحقق الضرورية إلى طريقة القواعد الخاصة بها:

/ ** * احصل على قواعد التحقق التي تنطبق على الطلب. * *return array * / public function rules () (إرجاع ["title" => "required | unique | max: 255"، "body" => "required"،]؛)

من أجل أن يعترض إطار العمل الطلب أمام وحدة التحكم ، أضف هذه الفئة إلى وسيطات طريقة وحدة التحكم المطلوبة:

مع الاستخدام الصحيح للتحقق من صحة الطلب ، يمكنك التأكد من أن المدخلات التي تم التحقق من صحتها هي دائمًا في وحدات التحكم الخاصة بك!

إذا فشل التحقق من الصحة ، يملأ إطار العمل متغيرات الفلاش بأخطاء التحقق ويعيد توجيه إلى الصفحة السابقة. في حالة طلب AJAX ، يتم إرجاع الرد برمز 422 و JSON مع أخطاء التحقق من الصحة.

صلاحية التحكم صلاحية الدخول

تحتوي فئات طلب النموذج أيضًا على طريقة التفويض. في هذه الطريقة ، يمكنك التحقق مما إذا كان المستخدم مسموحًا له بتنفيذ هذا الإجراء ، وتحديث المورد المحدد. على سبيل المثال ، إذا حاول المستخدم تعديل تعليق على منشور ، فهل هو مؤلف المنشور؟

/ ** * تحديد ما إذا كان المستخدم مصرحًا له بإجراء هذا الطلب. * *return bool * / public function authorize () ($ commentId = $ this-> route ("comment") ؛ إرجاع التعليق :: حيث ("id"، $ commentId) -> حيث ("user_id"، Auth: : معرف ()) -> موجود () ؛)

لاحظ استدعاء طريقة المسار () أعلاه. تمنحك هذه الطريقة الوصول إلى المعلمات في عنوان url (في هذه الحالة (تعليق)) المحددة في المسار:

الطريق :: post ("تعليق / (تعليق)") ؛

إذا قام التابع authorize بإرجاع خطأ ، فإن إطار العمل يولد استجابة 403 HTTP ويرسلها على الفور. لم يتم تنفيذ طريقة وحدة التحكم.

/ ** * تحديد ما إذا كان المستخدم مصرحًا له بإجراء هذا الطلب. * *return bool * / public function authorize () (عودة صحيحة ؛)

تغييرات تنسيق الخطأ في متغيرات الفلاش

إذا كنت تريد تخصيص رسائل خطأ التحقق من الصحة المخزنة في متغيرات فلاش الجلسة على عمليات إعادة التوجيه ، فتجاوز طريقة formatValidationErrors في فئة الطلب الأساسية (App \ Http \ Orders \ Request):

/ ** * (inheritdoc) * / تنسيق الوظيفة المحمية

التعامل مع رسائل الخطأ

بعد استدعاء طريقة الرسائل لكائن Validator ، ستحصل على كائن MessageBag ، والذي يحتوي على مجموعة من الأساليب المفيدة للوصول إلى رسائل الخطأ.

الحصول على الرسالة الأولى للحقل

صدى رسائل $-> أولاً ("البريد الإلكتروني") ؛

الحصول على جميع الرسائل في حقل واحد

foreach ($ messages-> get ("email") كـ $ message) (//)

الحصول على جميع الرسائل لجميع المجالات

foreach (رسائل $-> الكل () كـ $ message) (//)

التحقق من وجود رسالة للحقل

إذا كان ($ messages-> has ("email")) (//)

الحصول على خطأ في تنسيق معين

صدى رسائل $-> أولاً ("البريد الإلكتروني" ، "") ؛

ملحوظة:بشكل افتراضي ، يتم تنسيق المنشورات بطريقة تناسب Twitter Bootstrap.

احصل على جميع الرسائل بتنسيق معين

foreach (رسائل $-> الكل ("

:رسالة

") كرسالة $) (//)

الأخطاء والأنماط

بمجرد الانتهاء من التحقق ، ستحتاج إلى طريقة سهلة لتمرير الأخطاء إلى القالب. يتيح لك Laravel القيام بذلك بسهولة. على سبيل المثال ، لدينا هذه المسارات:

Route :: get ("Register"، function () (return View :: make ("user.register")؛))؛ Route :: post ("Register"، function () ($ rules = array (...)؛ $ validator = Validator :: make (Input :: all ()، $ rules)؛ if (validator-> fails ( )) (إعادة توجيه الإرجاع ("تسجيل") -> withErrors ($ validator) ؛))) ؛

لاحظ أنه عند فشل عمليات التحقق ، نقوم بتمرير كائن Validator إلى كائن إعادة التوجيه باستخدام طريقة withErrors. ستخزن هذه الطريقة رسائل الخطأ في متغيرات جلسة فلاش لمرة واحدة ، مما يجعلها متاحة للطلب التالي.

ومع ذلك ، لاحظ أننا لا نجتاز View :: make ("user.register") ؛ متغيرات $ errors للقالب. يتحقق Laravel نفسه من بيانات الجلسة بحثًا عن وجود المتغيرات ويمررها تلقائيًا إلى القالب إذا كانت متوفرة. وبالتالي ، من المهم أن تتذكر أن متغير الأخطاء $ سيكون متاحًا لجميع القوالب الخاصة بك في جميع الأوقات ، عند أي طلب. . يسمح لك هذا بافتراض أن المتغير $ errors يتم تعريفه دائمًا ويمكن استخدامه بأمان. متغير $ errors هو مثيل لفئة MessageBag.

وبالتالي ، بعد إعادة التوجيه ، يمكنك استخدام متغير الأخطاء $ الذي تم تعيينه تلقائيًا في القالب:

أولا ("البريد الإلكتروني") ؛ ؟>

MessageBag مسمى

إذا كانت لديك نماذج متعددة على الصفحة ، فيمكنك اختيار اسم كائن MessageBag الذي سيتم عرض نصوص الخطأ فيه بحيث يمكنك عرضها بشكل صحيح للنموذج المطلوب.

إعادة توجيه العودة ("تسجيل") -> withErrors ($ validator، "login") ؛

احصل على نص خطأ من MessageBag باسم تسجيل الدخول:

تسجيل الدخول> أولاً ("البريد الإلكتروني") ؛ ؟>

قواعد التحقق من الصحة

فيما يلي قائمة بجميع القواعد المتاحة ووظائفها:

وافقت

يجب أن يكون الحقل ذا قيمة نعم, علىأو 1 . هذا مفيد للتحقق من قبول القواعد والتراخيص.

active_url

يجب أن يكون الحقل عنوان URL صالحًا يمكن الوصول إليه عبر وظيفة checkdnsrr.

بعد، بعدما: تاريخ

يجب أن يكون الحقل تاريخًا بعد تاريخ

ألفا

يجب أن يحتوي الحقل على أحرف أبجدية فقط.

alpha_dash

يجب أن يحتوي الحقل على أحرف أبجدية وأرقام وشرطات سفلية (_) وواصلات (-) فقط.

alpha_num

يجب أن يحتوي الحقل على أحرف وأرقام أبجدية فقط.

مجموعة مصفوفة

يجب أن يكون الحقل عبارة عن مصفوفة.

قبل: تاريخ

يجب أن يكون تاريخ الحقل أقدم من تاريخ. يتم تحويل السلاسل إلى تواريخ باستخدام وظيفة strtotime.

ما بين: دقيقة,الأعلى

يجب أن يكون الحقل في النطاق دقيقةقبل الأعلى. يتم التعامل مع السلاسل والأرقام والملفات بطريقة مماثلة لقاعدة الحجم.

قيمة منطقية

يجب أن يكون الحقل منطقيًا (منطقيًا). القيم المسموح بها هي true و false و 1 و 0 و "1" و "0".

تم تأكيد

يجب أن تتطابق قيمة الحقل مع قيمة الحقل بهذا الاسم بالإضافة إلى foo_confirmation. على سبيل المثال ، إذا تم التحقق من حقل كلمة المرور ، فيجب أن يتم تمرير حقل تأكيد password_confirmation المطابق كمدخل.

تاريخ

يجب أن يكون الحقل تاريخًا صالحًا وفقًا لوظيفة strtotime.

صيغة التاريخ: صيغة

يجب أن يتطابق الحقل مع تنسيق التاريخ صيغةوفقًا لوظيفة date_parse_from_format.

مختلف: مجال

يجب أن تكون قيمة الحقل تحت التحقق مختلفة عن قيمة الحقل مجال.

البريد الإلكتروني

يجب أن يكون الحقل عنوان بريد إلكتروني صالحًا.

موجود: الطاولة,عمودي

يجب أن يكون الحقل موجودًا في جدول قاعدة البيانات المحدد.

استخدام بسيط:

"state" => "موجود: الدول"

تحديد اسم حقل في جدول:

"state" => "موجود: حالات ، اختصار"

يمكنك أيضًا تحديد المزيد من الشروط لإضافتها إلى الاستعلام "WHERE":

"البريد الإلكتروني" => "موجود: فريق العمل ، البريد الإلكتروني ، معرف الحساب ، 1"

صورة

يجب أن يكون الملف الذي تم تحميله صورة بتنسيق jpeg أو png أو bmp أو gif أو svg.

في: فو,شريط,...

يجب أن تكون قيمة الحقل واحدة من ( فو, شريطإلخ.).

عدد صحيح

يجب أن يحتوي الحقل على قيمة عدد صحيح صالحة.

IP

يجب أن يكون الحقل عنوان IP صالحًا.

الأعلى: القيمة

يجب أن تكون قيمة الحقل أقل من أو تساوي القيمة

التمثيل الصامت: فو,شريط,...

يجب أن يكون نوع MIME للملف الذي تم تحميله أحد الأنواع المدرجة.

استخدام بسيط:

"الصورة" => "التمثيل الصامت: jpeg ، bmp ، png"

الحد الأدنى: القيمة

يجب أن تكون قيمة الحقل أكبر من القيمة. يتم التعامل مع الأسطر والأرقام والملفات بشكل مشابه لملف.

ليس في: فو,شريط,...

قيمة الحقل ليسيجب أن يكون واحدًا من القوائم المدرجة فو, شريطإلخ.).

عددي

يجب أن يحتوي الحقل على قيمة عددية أو كسرية صالحة.

regex: نمط

يجب أن يتطابق الحقل مع التعبير العادي المحدد.

انتباه:عند استخدام هذه القاعدة ، قد يكون من الضروري تعداد القواعد الأخرى كعناصر مصفوفة ، خاصةً إذا كان التعبير يحتوي على حرف الأنبوب (|).

مطلوب

يجب أن يكون الحقل تحت التحقق موجودًا وقيمة غير فارغة.

مطلوب_إذا: مجال,القيمة,...

يجب أن يكون الحقل تحت التحقق موجودًا وأن يحتوي على قيمة غير فارغة إذا كان هناك حقل آخر مجالموجود وله أي من القيم القيمة.

مطلوب مع: فو,شريط,...

يوجد حقل واحد على الأقل من الحقول المدرجة وقيمة غير فارغة ( فو, شريطإلخ.).

مطلوب_مع_ الكل: فو,شريط,...

يجب أن يكون الحقل قيد الاختبار موجودًا وقيمة غير فارغة ، ولكن فقط في حالة وجود جميع الحقول المدرجة وقيمة غير فارغة ( فو, شريطإلخ.).

مطلوب_بدون: فو,شريط,...

يجب أن يكون الحقل تحت التحقق موجودًا وقيمة غير فارغة ، ولكن فقط إذا كان ليسواحد على الأقل من الحقول المدرجة موجود أو فارغ ( فو, شريطإلخ.).

مطلوب_بدون_كل: فو,شريط,...

يجب أن يكون الحقل تحت التحقق موجودًا وقيمة غير فارغة ، ولكن فقط إذا كان ليسجميع الحقول المدرجة موجودة أو فارغة ( فو, شريطإلخ.).

نفس: مجال

يجب أن يكون للحقل نفس قيمة الحقل مجال.

بحجم: القيمة

يجب أن يتطابق الحقل القيمةالحجم. للسلاسلانها تقف على طول ، للأرقام- رقم، للملفات- الحجم بالكيلو بايت.

وحدة زمنية

يجب أن يحتوي الحقل على معرّف المنطقة الزمنية (المنطقة الزمنية) ، أحد تلك المُدرجة في php-function timezone_identifiers_list

فريدة من نوعها: الطاولة,عمودي,إلا,idColumn

يجب أن تكون قيمة الحقل فريدة في جدول قاعدة البيانات المحدد. إذا لم يتم تحديد العمود ، فسيتم استخدام اسم الحقل.

سهل الاستخدام

"البريد الإلكتروني" => "فريد: المستخدمون"

تحديد اسم حقل في جدول

"email" => "unique: users، email_address"

تجاهل معرف معين

"email" => "unique: users، email_address، 10"

إضافة شروط إضافية

يمكنك أيضًا تحديد المزيد من الشروط لإضافتها إلى الاستعلام "WHERE":

"email" => "unique: users، email_address، NULL، id، account_id، 1"

في القاعدة أعلاه ، سيتم تضمين الصفوف التي تحتوي على account_id من 1 فقط في الشيك.

عنوان url

يجب أن يكون الحقل عنوان URL صالحًا.

ملحوظة:تم استخدام وظيفة PHP filter_var

القواعد الشرطية

تحتاج أحيانًا إلى التحقق من صحة حقل فقطعندما يكون موجودًا في الإدخال. للقيام بذلك ، أضف القاعدة أحيانًا:

$ v = Validator :: make ($ data، array ("email" => "أحيانًا | مطلوب | بريد إلكتروني"))؛

في المثال أعلاه ، لن يتم تشغيل التحقق من صحة حقل البريد الإلكتروني إلا عند وجود $ data ["email"].

قواعد شرطية معقدة

في بعض الأحيان ، تريد فقط أن يكون للحقل قيمة إذا كان هناك حقل آخر يحتوي على قيمة أكبر من 100 مثلاً. أو قد تطلب حقلين فقط عندما يتم تحديد حقل ثالث أيضًا. يتم تحقيق ذلك بسهولة من خلال القواعد الشرطية. أولاً ، أنشئ كائن Validator بمجموعة من القواعد الثابتة التي لا تتغير أبدًا:

$ v = Validator :: make ($ data، array ("email" => "required | email"، "games" => "required | numeric"،))؛

لنفترض الآن أن طلبك مكتوب لهواة جمع الألعاب. إذا كان هناك جامع لديه أكثر من 100 سجل لعبة ، فإننا نريد أن نسألهم لماذا يحتاجون إلى الكثير. على سبيل المثال ، قد يكون لديهم متجر أو قد يستمتعون فقط بجمعها. لذلك ، لإضافة مثل هذه القاعدة الشرطية ، نستخدم طريقة Validator.

$ v-> أحيانًا ("reason"، "required | max: 500"، function ($ input) (return $ input-> games> = 100؛))؛

المعلمة الأولى لهذه الطريقة هي اسم الحقل الذي نتحقق منه. المعلمة الثانية هي القاعدة التي نريد إضافتها إذا كانت دالة الإغلاق التي تم تمريرها (المعلمة الثالثة) ترجع صحيحًا. تسهل هذه الطريقة إنشاء قواعد معقدة للتحقق من صحة الإدخال. يمكنك حتى إضافة نفس القواعد الشرطية إلى حقول متعددة في نفس الوقت:

$ v-> أحيانًا (مجموعة ("سبب" ، "تكلفة") ، "مطلوب" ، وظيفة (إدخال $) (إرجاع $ input-> ألعاب> = 100 ؛)) ؛

ملحوظة:المعلمة $ input التي تم تمريرها إلى الإغلاق هي كائن Illuminate \ Support \ Fluent ويمكن استخدامها لقراءة المدخلات والملفات التي تم التحقق من صحتها.

رسائل الخطأ الخاصة

يمكنك توفير رسائل خطأ مخصصة بدلاً من الرسائل الافتراضية. هناك عدة طرق للقيام بذلك.

تمرير رسائلك إلى المدقق

رسائل $ = مجموعة ("مطلوب" => "الحقل: يجب ملء السمة."،)؛ Validator = Validator :: make ($ input، $ rules، $ messages)؛

ملحوظة:السلسلة: سيتم استبدال السمة باسم الحقل الذي يتم التحقق منه. يمكنك أيضًا استخدام سلاسل متغيرة أخرى.

استخدام متغيرات السلسلة الأخرى

$ messages = array ("same" => ": attribute و: يجب أن تتطابق القيم الأخرى."، "size" => "يجب أن يكون حقل: attribute مساويًا تمامًا: size."، "between" => ": يجب أن تكون قيمة السمة من: min إلى: max."، "in" => "Field: يجب أن تحتوي السمة على إحدى القيم التالية: القيم"،)؛

تحديد رسالة مخصصة لحقل واحد

قد تحتاج أحيانًا إلى تقديم رسالة مخصصة لحقل معين.

رسائل $ = مجموعة ("email.required" => "نحتاج إلى معرفة عنوان بريدك الإلكتروني!"،)؛

تحديد رسائلك الخاصة في ملف الترجمة

من الممكن أيضًا تحديد رسائل التحقق من الصحة في ملف الترجمة بدلاً من تمريرها مباشرةً إلى المدقق. للقيام بذلك ، أضف رسائل إلى المصفوفة المخصصة لملف الترجمة app / lang / xx / validation.php.

"custom" => array ("email" => array ("required" => "نحتاج إلى معرفة عنوان بريدك الإلكتروني!" ،) ،) ،

قواعد التحقق الخاصة

تسجيل قاعدة التحقق الخاصة بك

يأتي Laravel بالعديد من القواعد المفيدة خارج الصندوق ، لكن قد تحتاج إلى إنشاء قواعد خاصة بك. تتمثل إحدى طرق تسجيل قاعدة تعسفية في طريقة Validator :: extension.

Validator :: extension ("foo"، الوظيفة ($ attribute، $ value، $ parameters) (إرجاع $ value == "(! LANG: foo"; }); !}

ملحوظة:يجب أن يكون اسم القاعدة في format_with_underscores.

يأخذ الإغلاق الذي تم تمريره ثلاث معاملات: اسم حقل السمة $ للتحقق ، وقيمة حقل القيمة $ ، وصفيف المعلمات $ للمعلمات التي تم تمريرها إلى القاعدة.

بدلًا من الوظيفة ، يمكنك تمرير مرجع إلى طريقة الفئة إلى التابع extension:

Validator :: extension ("foo"، " [بريد إلكتروني محمي]");

لاحظ أنك ستحتاج أيضًا إلى تحديد رسالة خطأ للقاعدة الجديدة. يمكنك القيام بذلك إما عن طريق تمريرها كمصفوفة من السلاسل إلى Validator ، أو عن طريق كتابتها في ملف الترجمة.

تمديد فئة Validator

بدلاً من استخدام وظائف الإغلاق لتوسيع مجموعة القواعد المتاحة ، يمكنك توسيع فئة Validator نفسها. للقيام بذلك ، أنشئ فئة ترث Illuminate \ Validation \ Validator. يمكنك إضافة طرق تحقق جديدة ببدء اسمها بالتحقق.

تسجيل فئة أداة تحقق جديدة

تحتاج بعد ذلك إلى تسجيل امتداد التحقق هذا. يمكنك القيام بذلك ، على سبيل المثال ، في مزود الخدمة الخاص بك أو في ملفات البداية الخاصة بك.

Validator :: الحل (الوظيفة (مترجم $ ، بيانات $ ، قواعد $ ، رسائل $) (إرجاع CustomValidator جديد (مترجم $ ، بيانات $ ، قواعد $ ، رسائل $) ؛)) ؛

في بعض الأحيان ، عند إنشاء فئة التحقق الخاصة بك ، قد تحتاج إلى تحديد سلاسل المتغيرات الخاصة بك (مثل ": foo") لاستبدالها في رسائل الخطأ. يتم ذلك عن طريق إنشاء فئة كما هو موضح أعلاه وإضافة وظائف بأسماء مثل replaceXXX.

وظيفة محمية replaceFoo (رسالة $ ، سمة $ ، قاعدة $ ، معاملات $) (إرجاع str_replace (": foo"، $ parameters، $ message)؛)

إذا كنت تريد إضافة رسالتك بدون استخدام Validator :: extension ، يمكنك استخدام طريقة Validator :: replacer:

Validator :: replacer ("rule"، function ($ message، $ attribute، $ rule، $ parameters) (//))؛