وحدات التحكم
توجيه الطلب، وإنتاج الصفحة، وإعادة التوجيه بالطريقة الصحيحة.
وحدات التحكم والعروض
تبدو وحدة التحكم (Controller) في Spring MVC شبيهة بفئة Java عادية إلى حدّ أننا ننسى حجم العمل الذي يقوم به الإطار من حولها. تعلن الدالة عن @PathVariable Long id, @RequestParam int page, Model model فتتلقى ثلاث قيم جاهزة للاستخدام، مستخرجة من ثلاثة مواضع مختلفة في الطلب، ومحوَّلة إلى النوع الصحيح، ومتحقَّقًا منها. ولا يظهر أيٌّ من هذه التحويلات في شيفرتك.
لهذا الاختصار ثمن: عندما يحدث خطأ ما، يكون السبب غالبًا خفيًّا لأنه كامن في اصطلاح لم تكن تعرفه. متغيّر مسار يصل فارغًا لأن اسمه لا يطابق. معامل مفقود يُطلق الخطأ 400 مع أنك أردته اختياريًّا. إعادة توجيه بعد إرسال نموذج تفقد رسالة التأكيد. كائن أُضيف إلى النموذج (Model) لكنه غير موجود في القالب.
تشترك هذه الحالات كلها في الأصل نفسه: العقد بين دالتك والإطار يقوم على الأسماء والأنواع، لا على شيفرة صريحة. وفهم هذا العقد يعني معرفة أين تنظر حين لا يُحترم.
يفصّل هذا الدرس هذا العقد في الاتجاهين — ما يمكن أن تتلقاه الدالة، وما يمكن أن تُرجعه — ثم ينتقل إلى عرض Thymeleaf: التكرار، والأجزاء القابلة لإعادة الاستخدام، وآلية سمات Flash التي تحسم مرة واحدة مشكلة رسالة التأكيد بعد إعادة التوجيه.
التعليقات
التعليقات مدعومة عبر GitHub Discussions
سجّل الدخول باستخدام GitHub للمشاركة في النقاش