1. معلومات عامة

ملف PDF للوثيقة متاح |هنا|.

1.1. الأهداف

في هذه المقالة، سوف نستكشف إطار عمل تطويري يُسمى Struts. Jakarta Struts هو مشروع تابع لمؤسسة Apache Software Foundation (www.apache.org) مصمم لتوفير إطار عمل قياسي لتطوير تطبيقات الويب بلغة Java استنادًا إلى بنية MVC (Model-View-Controller).

1.2. نموذج MVC

يسعى نموذج MVC إلى فصل طبقات العرض والمعالجة والوصول إلى البيانات. سيتم تنظيم تطبيق الويب الذي يتبع هذا النموذج على النحو التالي:

تُسمى هذه البنية بنية ثلاثية الطبقات أو ثلاثية المستويات:

واجهة المستخدم هي V (العرض)
منطق التطبيق هو C (وحدة التحكم)
مصادر البيانات هي M (النموذج)

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

عند تطبيق هذا النموذج مع السيرفلتات وصفحات JSP، تنتج البنية التالية:

في كتلة [منطق التطبيق]، نميز

بين السيرفلت، وهو نقطة دخول التطبيق ويُسمى أيضًا وحدة التحكم
كتلة [فئات الأعمال]، التي تحتوي على فئات Java الضرورية لمنطق التطبيق
كتلة [Data Access Classes]، التي تحتوي على فئات Java اللازمة لاسترداد البيانات المطلوبة من قبل السيرفلت، وغالبًا ما تكون بيانات ثابتة (قاعدة بيانات، ملفات، خدمة ويب، إلخ)
كتلة صفحات JSP، التي تشكل طرق عرض التطبيق.

1.3. نهج تطوير MVC باستخدام السيرفلت وصفحات JSP

لقد حددنا نهجًا لتطوير تطبيقات الويب Java يتبع نموذج MVC الموصوف أعلاه. سنستعرضه هنا.

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

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

يمكننا رسم مخطط بياني لعمليات الإدخال/الإخراج لكل عرض

المدخلات هي البيانات التي يجب أن يوفرها السيرفلت لصفحة JSP، سواء في الطلب أو في الجلسة.
المخرجات هي البيانات التي يجب أن توفرها صفحة JSP إلى السيرفلت. وهي جزء من نموذج HTML، وسيقوم السيرفلت باستردادها باستخدام عملية مثل request.getParameter(...).

سنكتب كود Java/JSP لكل عرض. وسيكون في الغالب بالشكل التالي:

<%@ page ... %>    // importations de classes le plus souvent
<%!
    // variables d'instance de la page JSP (=globales)
    // nécessaire que si la page JSP a des méthodes partageant des variables (rare)    
    ...    
%>
<%
    // récupération des données envoyées par la servlet
    // soit dans la requête (request) soit dans la session (session)
    ...
%>

<html>
...
        // on cherchera ici à minimiser le code java
</html>

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

يجب إنشاء سياق التطبيق في ملف server.xml الخاص بـ Tomcat. يمكننا البدء باختبار هذا السياق. لنفترض أن C هو هذا السياق و DC هو المجلد المرتبط به. سننشئ ملفًا ثابتًا باسم test.html ونضعه في مجلد DC. بعد تشغيل Tomcat، سنطلب عنوان URL http://localhost:8080/DC/test.html في متصفح.
يمكن اختبار كل صفحة JSP. إذا كانت صفحة JSP تسمى formulaire.jsp، فسنطلب عنوان URL http://localhost:8080/DC/formulaire.jsp في متصفح. تتوقع صفحة JSP قيمًا من السيرفلت الذي يستدعيها. هنا، نستدعيها مباشرةً، لذا لن تتلقى المعلمات المتوقعة. لضمان إمكانية إجراء الاختبار، سنقوم يدويًا بتهيئة المعلمات المتوقعة في صفحة JSP باستخدام الثوابت. تتحقق هذه الاختبارات الأولية من صحة بناء جمل صفحات JSP.

بعد ذلك، نكتب كود السيرفلت. يحتوي على طريقتين متميزتين:

طريقة init، التي تُستخدم من أجل:
- استرداد معلمات تكوين التطبيق من ملف web.xml الخاص به
- إنشاء مثيلات محتملة لفئات الأعمال التي سيحتاج إلى استخدامها لاحقًا
- معالجة أي قائمة بأخطاء التهيئة التي سيتم إرجاعها إلى مستخدمي التطبيق في المستقبل. قد تتضمن معالجة الأخطاء هذه إرسال بريد إلكتروني إلى مسؤول التطبيق لإخطاره بوجود خلل
طريقة doGet أو doPost، اعتمادًا على كيفية استلام السيرفلت للمعلمات من عملائه. إذا كان السيرفلت يتعامل مع نماذج متعددة، فمن الأفضل أن يرسل كل نموذج معلومات تحدد هويته بشكل فريد. يمكن القيام بذلك باستخدام سمة مخفية في النموذج من النوع <input type="hidden" name="action" value="...">. يمكن أن يبدأ السيرفلت بقراءة قيمة هذه المعلمة ثم يفوض معالجة الطلب إلى طريقة داخلية خاصة مسؤولة عن معالجة هذا النوع من الطلبات.
يجب تجنب وضع منطق الأعمال في السيرفلت قدر الإمكان. فهذا ليس الغرض الذي صُمم من أجله. يعمل السيرفلت كنوع من قائد الفريق (وحدة التحكم) الذي يتلقى الطلبات من عملائه (عملاء الويب) ويقوم بتنفيذها بواسطة الكيانات الأكثر ملاءمة (فئات الأعمال). عند كتابة السيرفلت، ستقوم بتعريف واجهة فئات الأعمال المراد إنشاؤها (المنشئات، الطرق). ينطبق هذا إذا كانت فئات الأعمال هذه بحاجة إلى الإنشاء. إذا كانت موجودة بالفعل، فيجب أن يتكيف السيرفلت مع الواجهة الموجودة.
سيتم ترجمة كود السيرفلت.

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

public ArrayList getCodes(){
    String[] codes= {"code1","code2","code3"};
    ArrayList aCodes=new ArrayList();
    for(int i=0;i<codes.length;i++){
        aCodes.add(codes[i]);
    }
        return aCodes;
}

يمكننا الآن المضي قدماً في اختبار السيرفلت.

يجب إنشاء ملف تكوين web.xml الخاص بالتطبيق. يجب أن يحتوي على جميع المعلومات التي تتوقعها طريقة init الخاصة بالبرنامج الخادم (<init-param>). بالإضافة إلى ذلك، نقوم بتعيين عنوان URL الذي سيتم من خلاله الوصول إلى البرنامج الخادم الرئيسي (<servlet-mapping>).
يتم وضع جميع الفئات الضرورية (البرنامج الخادم، وفئات الأعمال) في WEB-INF/classes.
يتم وضع جميع مكتبات الفئات الضرورية (.jar) في WEB-INF/lib. قد تحتوي هذه المكتبات على فئات الأعمال وبرامج تشغيل JDBC وما إلى ذلك.
يتم وضع طرق عرض JSP في جذر التطبيق أو في مجلد مخصص. وينطبق الأمر نفسه على الموارد الأخرى (HTML، الصور، الصوت، مقاطع الفيديو، إلخ).
بمجرد الانتهاء من ذلك، يتم اختبار التطبيق وتصحيح الأخطاء الأولية. في نهاية هذه المرحلة، تصبح بنية التطبيق جاهزة للعمل. قد تكون مرحلة الاختبار هذه صعبة نظرًا لعدم توفر أداة تصحيح أخطاء مع Tomcat. ولهذا، سيحتاج Tomcat إلى أن يتم دمجه في أداة تطوير (JBuilder Developer، Sun One Studio، إلخ). يمكنك استخدام عبارات System.out.println("....")، التي تكتب إلى وحدة تحكم Tomcat. أول شيء يجب التحقق منه هو أن طريقة init تسترد بنجاح جميع البيانات من ملف web.xml. للقيام بذلك، يمكننا كتابة قيم هذه المعلمات في نافذة Tomcat. وبالمثل، سنتحقق من أن طريقتي doGet و doPost تستردان المعلمات بشكل صحيح من نماذج HTML المختلفة للتطبيق.

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

1.4. نهج تطوير STRUTS

سعى مبتكرو منهجية STRUTS إلى تحديد طريقة تطوير قياسية تتوافق مع بنية MVC لتطبيقات الويب المكتوبة بلغة Java. هناك جانبان لمشروع STRUTS:

طريقة التطوير. سنرى أنها تشبه إلى حد كبير الطريقة الموصوفة أعلاه لـ servlets وصفحات JSP
الأدوات التي تسمح لنا بتطبيق طريقة التطوير هذه. وهي عبارة عن مكتبات فئات Java متوفرة على موقع مؤسسة Apache (www.apache.org).

1.4.1. طريقة التطوير

تتمثل بنية MVC التي يستخدمها STRUTS فيما يلي:

تعد وحدة التحكم (Controller) قلب التطبيق. تمر جميع طلبات العميل من خلالها. وهي عبارة عن سيرفلت عام يوفره STRUTS. في بعض الحالات، قد تحتاج إلى توسيعها. أما في الحالات البسيطة، فهذا ليس ضروريًا. يسترد هذا السيرفلت العام المعلومات التي يحتاجها من ملف يُسمى غالبًا struts-config.xml.
إذا كان طلب العميل يحتوي على معلمات نموذج، يتم وضعها في كائن Bean. يُقال إن الفئة من نوع Bean إذا كانت تتبع قواعد الإنشاء التي سنناقشها لاحقًا. يتم تخزين كائنات Bean التي تم إنشاؤها بمرور الوقت في جلسة عمل العميل أو طلبه. هذا الإعداد قابل للتكوين. لا يلزم إعادة إنشائها إذا كانت قد تم إنشاؤها بالفعل.
في ملف التكوين struts-config.html، يرتبط كل عنوان URL سيتم معالجته بواسطة البرنامج (وبالتالي لا يتوافق مع عرض JSP يمكن طلبه مباشرة) بمعلومات معينة:
- اسم الفئة من نوع Action المسؤولة عن معالجة الطلب. هنا مرة أخرى، يمكن تخزين كائن Action الذي تم إنشاء مثيل له في الجلسة أو الطلب.
- إذا كان عنوان URL المطلوب معلمًا (كما هو الحال عند إرسال نموذج إلى وحدة التحكم)، يتم تحديد اسم bean المسؤول عن تخزين بيانات النموذج.
مسلحًا بهذه المعلومات المقدمة من ملف التكوين الخاص به، عند تلقي طلب URL من عميل، يمكن لوحدة التحكم تحديد ما إذا كان يلزم إنشاء bean وأي واحد. بمجرد إنشاء مثيل، يمكن لـ bean التحقق مما إذا كانت البيانات التي خزنها — والتي تأتي من النموذج — صالحة أم لا. يتم استدعاء طريقة في الكائن تسمى `validate` تلقائيًا بواسطة وحدة التحكم. يتم إنشاء الكائن بواسطة المطور. لذلك، يضع المطور الكود الذي يتحقق من صحة بيانات النموذج داخل طريقة validate. إذا تبين أن البيانات غير صالحة، فلن تواصل وحدة التحكم العمل. ستنقل التحكم إلى عرض يجد اسمه في ملف التكوين الخاص به. عندئذٍ يكتمل التفاعل. لاحظ أن المطور يمكنه اختيار عدم التحقق من صحة النموذج. ويتم ذلك أيضًا في ملف struts-config.html. في هذه الحالة، لا يستدعي وحدة التحكم طريقة validate الخاصة بالبيان.
إذا كانت بيانات الكائن صحيحة، أو إذا لم يكن هناك تحقق من الصحة، أو إذا لم يكن هناك كائن، فإن وحدة التحكم تمرر التحكم إلى كائن Action المرتبط بعنوان URL. وتقوم بذلك عن طريق استدعاء طريقة execute الخاصة بهذا الكائن، وتمرر له المرجع إلى الكائن الذي ربما يكون قد أنشأه. وهنا يقوم المطور بما يجب القيام به: فقد يحتاج إلى استدعاء فئات الأعمال أو فئات الوصول إلى البيانات. في نهاية المعالجة، يعيد كائن Action إلى وحدة التحكم اسم العرض الذي يجب أن ترسله استجابةً للعميل.
يرسل وحدة التحكم هذا الرد. وبذلك يكتمل التفاعل مع العميل.

تبدأ منهجية تطوير STRUTS في التبلور:

تحديد طرق العرض. نميز بين طرق العرض التي تمثل نماذج وطرق العرض الأخرى.
- يولد كل عرض نموذج تعريفًا في ملف struts-config.xml. يتم تعريف المعلومات التالية هناك:
  - اسم فئة Bean التي ستحتوي على بيانات النموذج، بالإضافة إلى إشارة إلى ما إذا كان يجب التحقق من صحة البيانات أم لا. إذا كان التحقق من الصحة مطلوبًا وتبين أن البيانات غير صالحة، فيجب تحديد العرض الذي سيتم إرساله إلى العميل في هذه الحالة.
  - اسم فئة Action المسؤولة عن معالجة النموذج.
  - أسماء جميع طرق العرض التي قد يتم إرسالها إلى العميل بمجرد معالجة الطلب. ستقوم فئة Action باختيار إحداها بناءً على نتيجة المعالجة.
- كل عرض يتوافق مع صفحة JSP. سنرى أنه في العروض — وخاصة عروض النماذج — نستخدم أحيانًا مكتبة من العلامات الخاصة بـ Struts.
كتابة فئات JavaBean المطابقة لعروض النماذج
كتابة فئات Action المسؤولة عن معالجة النماذج
كتابة أي منطق أعمال أو فئات الوصول إلى البيانات

1.4.2. أدوات تطوير STRUTS

مشروع Struts هو أحد مشاريع مؤسسة Apache Software Foundation. تم تجميع العديد من هذه المشاريع تحت اسم Jakarta وهي متاحة على الرابط http://jakarta.apache.org:

يُنصح بقراءة هذه الصفحة. العديد من هذه المشاريع تهم مطوري Java. إذا اتبعنا رابط Struts أعلاه، فسنصل إلى الصفحة الرئيسية للمشروع:

هنا أيضًا، يُنصح بقراءة الصفحة الرئيسية. لتنزيل مكتبات Struts لـ Java، اتبع رابط "Binaries" أعلاه:

بالنسبة لمستخدمي Windows، استخدم الرابط 1.1.zip؛ وبالنسبة لمستخدمي Unix، استخدم الرابط 1.1.tar.gz (نوفمبر 2003). بمجرد فك ضغط ملف 1.1.zip، سترى بنية الدليل التالية:

تحتوي بنية الدليل هذه على مكتبات فئات Java المطلوبة لتطوير Struts. يتم تخزينها في ملفات .jar أو .war، وهي تشبه ملفات .zip. يمكن فتحها باستخدام نفس الأدوات المساعدة. توجد معظم المكتبات الضرورية في المجلد lib أعلاه:

بالإضافة إلى مكتبات فئات .jar، توجد ملفات .dtd (تعريف نوع المستند) التي تحتوي على قواعد التحقق من صحة ملفات XML. يمكن لملف XML الإشارة إلى ملف DTD من هذا النوع في محتواه. سيستخدم البرنامج (المسمى محلل) الذي يحلل محتوى ملف XML قواعد التحقق من الصحة الموجودة في ملف DTD المشار إليه لتحديد ما إذا كان ملف XML صحيحًا من الناحية النحوية. على سبيل المثال، يحدد ملف struts-config_1_1.dtd قواعد إنشاء ملف التكوين struts-config.xml لإصدار Struts 1.1.

لنلقِ نظرة الآن على مكان وضع العناصر المختلفة لهيكل دليل Struts لنشر تطبيق Struts على خادم Tomcat.

1.5. نشر تطبيق Struts

تطبيق Struts هو تطبيق ويب مثل أي تطبيق آخر. لذلك فهو يتبع قواعد النشر الخاصة بالحاوية التي يعمل فيها. هنا، سيتم تشغيل تطبيق — سنسميه strutspersonne — بواسطة خادم Tomcat الإصدار 4.x. يتم تضمين إجراء النشر الخاص بـ Tomcat الإصدار 5.x في الملحق. هنا، سنتبع قواعد النشر الخاصة بـ Tomcat 4.x:

نحدد سياق strutspersonne في ملف التكوين server.xml الخاص بـ Tomcat:

                <Context path="/strutspersonne" docBase="e:/data/serge/web/struts/personne" />

بمجرد الانتهاء من ذلك، نعيد تشغيل Tomcat إذا لزم الأمر حتى يأخذ السياق الجديد في الاعتبار. يمكننا التحقق من صحة السياق عن طريق طلب عنوان URL http://localhost:8080/strutspersonne:

إذا لم تظهر لنا صفحة خطأ، فهذا يعني أن السياق صحيح.

نقوم بإنشاء المجلد الفرعي WEB-INF في المجلد الفعلي المرتبط بسياق strutspersonne.
في مجلد WEB-INF الخاص بالتطبيق، نحدد ملف تكوين web.xml الخاص بالتطبيق:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
    <servlet>
      <servlet-name>action</servlet-name>
    <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
    <init-param>
        <param-name>config</param-name>
      <param-value>/WEB-INF/struts-config.xml</param-value>
    </init-param>
  </servlet>

  <servlet-mapping>
      <servlet-name>action</servlet-name>
    <url-pattern>*.do</url-pattern>
  </servlet-mapping>

</web-app>

فئة وحدة التحكم (servlet) للتطبيق هي فئة Struts محددة مسبقًا تسمى ActionServlet. وهي موجودة في ملف struts.jar. لضمان أن يتمكن Tomcat من العثور على هذه الفئة، سنضع struts.jar في المجلد <tomcat>\common\lib، وهو أحد المجلدات التي يبحث فيها Tomcat عند البحث عن الفئات. في الواقع، سنضع جميع ملفات .jar الموجودة في المجلد <struts>\lib هناك، حيث <struts> هو المجلد الجذر لشجرة دليل Struts.

سنضع أيضًا ملفات struts-el.jar و jstl.jar الموجودة في <struts>\contrib\struts-el\lib:

هنا، لدينا إمكانية الوصول إلى خادم الويب. وهذا ليس هو الحال دائمًا. إذا قمت بنشر تطبيق ويب/جافا في حاوية ويب لا تديرها بنفسك، فمن الأفضل أن يتضمن التطبيق جميع المكتبات التي يحتاجها. يجب بعد ذلك وضع هذه المكتبات في المجلد WEB-INF/lib، الذي يجب عليك إنشاؤه.
لاحظنا أن وحدة التحكم تتطلب معلومات معينة، والتي تجدها عادةً في ملف struts-config.xml الموجود في نفس المجلد الذي يوجد فيه ملف web.xml. في الواقع، يمكن تكوين اسم هذا الملف. المعلمة config المذكورة أعلاه هي التي تحدد هذا الاسم.
تشير العلامة <servlet-mapping> إلى أنه سيتم الوصول إلى وحدة التحكم عبر جميع عناوين URL التي تنتهي باللاحقة .do. هذا التعيين مطلوب من قبل Struts. سيتم بعد ذلك تصفية عناوين URL هذه بواسطة وحدة التحكم، التي لن تقبل سوى عناوين URL المعلنة في ملف التكوين struts-config.xml الخاص بها

في الوقت الحالي، ملف web.xml الخاص بنا كافٍ.

سنطلب عنوان URL /main.do من تطبيق strutspersonne. وفقًا لملف web.xml السابق، سيتم تمرير عنوان URL هذا إلى servlet org.apache.struts.action. سيتم إنشاء مثيل لفئة ActionServlet واستدعاء طريقة init الخاصة بها. تحاول هذه الطريقة قراءة ملف التكوين المحدد بواسطة المعلمة config. لذلك يجب أن يكون هذا الملف موجودًا. نقوم بإنشاء ملف struts-config.xml التالي:

<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE struts-config PUBLIC
          "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN"
          "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">

<struts-config>
    <action-mappings>
      <action
          path="/main"
          parameter="/main.html"
          type="org.apache.struts.actions.ForwardAction"
      />
    </action-mappings>
</struts-config>

لاحظ أن ملف DTD الخاص بـ struts-config.xml يختلف عن ملف web.xml، مما يشير إلى أنهما لا يمتلكان نفس البنية. لكل عنوان URL يجب على وحدة التحكم معالجته، نحتاج إلى تعريف علامة <action>. تُستخدم هذه العلامة لإخبار وحدة التحكم بما يجب القيام به عند تلقي طلب لهذا العنوان. هنا، نحدد العناصر التالية:

path="/main": يحدد اسم عنوان URL الذي تم تكوينه بواسطة علامة <action>. اللاحقة .do ضمنية.
type="org.apache.struts.actions.ForwardAction": يحدد اسم فئة Action التي يجب أن تتعامل مع الطلب. هنا، نستخدم فئة Action محددة مسبقًا في Struts. لا تقوم هذه الفئة بأي شيء من تلقاء نفسها، بل تقوم بإعادة توجيه طلب العميل إلى عنوان URL المحدد في سمة parameter.
parameter="/main.html": اسم عنوان URL الذي يجب إعادة توجيه الطلب إليه. هنا، هو ملف HTML ثابت.

باختصار، عندما يطلب المستخدم عنوان URL /main.do، سيتم توجيهه إلى عنوان URL /main.html.

سيكون ملف main.html كما يلي:

<html>
    <head>
      <title>Application strutspersonne</title>
  </head>
  <body>
      Application strutspersonne active ....
  </body>
</html>

يوجد هذا الملف في مجلد التطبيق strutspersonne/views:

يمكن الوصول إليه مباشرة عبر عنوان URL http://localhost:8080/strutspersonne/main.html:

هنا، لم يتدخل وحدة التحكم Struts الخاصة بالتطبيق، لأنها لا تتدخل إلا عند طلب عنوان URL من النوع *.do. ومع ذلك، في هذه الحالة، طلبنا عنوان URL /vues/main.html.

يجب وضع ملف struts-config.xml الذي تم إنشاؤه مسبقًا في نفس مجلد WEB-INF الذي يوجد فيه ملف web.xml:

سنقوم الآن بالتحقق من أن وحدة التحكم في التطبيق strutspersonne تعمل بشكل صحيح عن طريق طلب عنوان URL /main.do بعد إعادة تشغيل Tomcat إذا لزم الأمر.

هنا، تدخلت وحدة التحكم Struts لأننا طلبنا عنوان URL من النوع *.do. وقد نجحنا في الحصول على الصفحة المتوقعة (main.html). وأصبح لدينا الآن المكونات الأساسية اللازمة لتشغيل تطبيقنا: سياق strutspersonne، وملفات التكوين web.xml وstruts-config.xml، ومكتبات Struts.

ماذا كان سيحدث لو طلبنا عنوان URL مثل /toto.do؟ وفقًا لملف web.xml الخاص بتطبيق strutspersonne، يتم استدعاء وحدة التحكم Struts للتعامل مع الأمر. ثم تتحقق من ملف التكوين struts-config.html الخاص بها ولا تجد أي تكوين لعنوان URL /toto. ماذا تفعل إذن؟ دعونا نجرب:

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