يكتب الموظف كود العميل 00127، ثم يراه في التصدير 127. قد يبدأ العيب من اعتبار المعرّف كمية عددية في إحدى طبقات النظام. الرقم هنا اسم لسجل، وليس قيمة تريد زيادتها أو حساب متوسطها. اختيار نوع الحقل يجب أن يتبع هذا المعنى.
شكل الأرقام لا يحدد نوع البيانات
توضح MDN لحقل number أنه مناسب للأعداد التي يفيد زيادتها وإنقاصها، وليس لكل قيمة تتألف من أرقام مثل بعض الرموز البريدية. ويمكن لحقل نصي استخدام inputmode مناسب؛ لكن inputmode تلميح للوحة الإدخال وليست قاعدة تحقق.
في مثال افتراضي، يتكون مرجع العميل من خمسة أرقام ويجب الاحتفاظ بأصفاره. يمكن أن يظل نصًا في الواجهة وعقد API وقاعدة البيانات. استخدام type=text وحده لن يحميه إذا حوّل الخادم أو أداة التصدير قيمته إلى عدد لاحقًا.
اختبر الرحلة كاملة
| القيمة المصطنعة | نقطة المراجعة |
|---|---|
| 00127 | تظل بالقيمة نفسها بعد الحفظ وإعادة الفتح والتصدير |
| قيمة ناقصة الطول | رفض مفهوم وفق سياسة الكود |
| لصق بمسافات طرفية | تطبيع معلن أو رفض متسق |
| أرقام عربية وهندية | سلوك متفق عليه في البحث والتحقق والتخزين |
ضع سياسة التطبيع قبل تنفيذها
هل يقبل النظام أكثر من شكل لكتابة الرقم؟ هل يحولها إلى تمثيل واحد أم يرفض غير المتوقع؟ هذا قرار يحتاج توثيقًا واختبارات، لا حذفًا عشوائيًا لأي محرف لا يطابق تعبيرًا جاهزًا. اسمح باللصق ثم قدم خطأ محددًا إذا خالفت القيمة العقد.
راجع اتجاه العرض في النموذج العربي كي يقرأ المستخدم الكود كما حُفظ. لا تضف محددات اتجاه إلى القيمة المخزنة لمجرد علاج شكلها البصري. ويظل التحقق في الخادم مطلوبًا حتى لو بدت لوحة الهاتف رقمية.
اعتمد الكود في البحث أيضًا
في أنظمة CRM افحص البحث والتكامل والاستيراد بجانب النموذج. وتراجع تجربة الاستخدام الاسم والوصف ورسائل الخطأ ببيانات تجريبية. معيار القبول تطابق المعرّف عند كل انتقال، لا مجرد نجاح كتابة خمسة محارف على جهاز واحد.
