وسيلة اخرى لتعقيد الامور!

صار موقعنا يستخدم ما قررناه في البداية:
– التقسيم حسب صنف اللعبة
– تحديد البيئات المتعلقة بكل مقال
– ادارة انواع المقالات

في المرحلة التالية، سننشئ وسائل تصفح متوازية (التصفح حسب بيئة معينة او حسب نوع معين من المقالات).

لكن قبل الشروع في تطوير وسائل التصفح العرضية هذه، دعنا نعقّد الامور قليلاً بإضافة عنصرين ضروريين في مواقع العاب الفيديو:
– اعطاء علامة لكل لعبة
– تاريخ الصدور الرسمي للعبة

لا شك ان هذين العنصرين سهلا التثبيت بفضل نظام المفاتيح. فسيوفران، هما ايضاً، اساليب تصفح عرضية (مثلاً صفحة تعرض الالعاب التي حصلت على افضل العلامات وصفحة اعلان عن ظهور الالعاب).

اعطاء علامة لكل لعبة

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

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

نقرر اعتباطياً ان تكون العلامة من 10 (اي 1 من 10 للرديئ الى 10 من 10 للممتاز).

عودة الى صفحة ادارة المفاتيح:
– ننشئ مجموعة مفاتيح اسمها «علامة»
– في هذه المجموعة ندخل عشرة مفاتيح اسمها «01» و«02» و... و«10». مما يعطي:

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

هكذا، وقبل نشر اي اختبار، نضيف على تحديد مفتاح نوع المقال (اي «اختبار») والبيئات المدعومة، تحديد العلامة. واذا اردنا اداءً متماسكاً يجب اختيار علامة واحدة فقط لكل مقال.

ادراج العلامة في الصفحة النموذجية

اما الحلقة التي تتيح عرض علامة مقال، فهي بسيطة للغاية:

– في ملف «article.html»، نضع علامة المقال تحت توقيع المؤلف (اي قبل الملاحظة PS# والحواشي NOTES#):

	<BOUCLE_rating(MOTS){id_article}{inverse}{type=علامة}>
		[<p align="right"><b>العلامة: (#TITRE)/10</b>]
	</BOUCLE_rating>

دعنا نضيف ايضاً ذكر العلامة في «اختبارات اللعبة الاخرى». سيتم اذاً تغيير حلقة BOUCLE_tests هكذا:

	<B_tests><p>إختبارات اللعبة:
	<ul>
	<BOUCLE_tests(ARTICLES){id_rubrique}{titre_mot=إختبار}>
		<li>
		<BOUCLE_tests_platforms(MOTS){id_article}{type=البيئة}>
			[(#LOGO_MOT)]
		</BOUCLE_tests_platforms>
		<a href="#URL_ARTICLE">#TITRE</a> 
		<BOUCLE_other_rating(MOTS){id_article}{type=علامة}{inverse}>

			[ - العلامة: (#TITRE)/10]
		</BOUCLE_other_rating>
		- [(#DATE|affdate)]
		</BOUCLE_tests>
	</ul>
	</B_tests>

– في ملف الاقسام «rubrique.html»، يتم استبدال الحلقة BOUCLE_tests مباشرة.

هكذا لم يستغرق ادراج علامة للاختبارات دقائق معدودة. كل ذلك كان سهلاً وسنرى في ما بعد كيف يمكننا استغلال العلامة المعطاة الى الالعاب في امكنة اخرى.

تاريخ الصدور الرسمي للالعاب

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

هناك وسيلة وهي استخدام تاريخ اول نشر لبعض المقالات. ولكن السؤال هنا هو اي مقالات؟

– تواريخ صدور الالعاب معروفة (تقريباً) مسبقاً وبالتالي فلا يمكن الانتظار حتى يصبح هناك مقالات حول اللعبة للتمكن من إعلان تاريخ صدورها.

– يمكن لمقالات لعبة معينة ان تتطرق لبيئة واحدة او اكثر. الا ان تواريخ الصدور حسب البيئات تختلف في ما بينها. بالتالي لا نستطيع استخدام مقال مشترك بين عدة بيئات للإعلان عن التاريخ. على سبيل المثال، تتشابه نسختا لعبة Alone in the Dark: the new nightmare الداعمتان لبيئتي بلاي ستيشن 2 ودريم كاست كثيراً في ما بينهما، لذلك يكون من المنطقي تخصيص اختبار واحد لكلتيهما. في المقابل يختلف تاريخا صدور النسختين بحيث لا يمكن ذكرهما في المقال.

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

اذاً، في بنية موقعنا يمكن اعتبار تاريخ الصدور معلومة مستقلة عن سائر المعلومات (اختبارات، استعراضات، الخ)، بالتالي لا يمكننا استخدام «تاريخ النشر الاول» لمقال آخر للإعلان عن تاريخ صدور اللعبة. سنتصرف كالتالي (لا شك ان هناك طرق اخرى):

– نقوم بإنشاء نوع جديد من المقالات (اضافة الى الاختبارات والاستعراضات الخ) ونضعه في مجموعة «نوع المقال» ونطلق عليه اسم «تاريخ_الصدور».

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

– نخصص لكل مقال مرتبط بـ«تاريخ_الصدور» مفتاح البيئة المناسبة لتاريخ الصدور.

هنا، على سبيل المثال طريقة التعامل مع لعبة Resident Evil: Code Veronica:

– انشاء مقال جديد في قسم «Code Veronica»
– ادخال عنوان: صدور Veronica لبيئة دريم كاست (عنوان لا تتعدى اهميته امكان التعرّف على المقال في المجال الخاص)
– تخصيص المقال بالمفتاحين «دريم كاست» و«تاريخ_الصدور»
– «نشر» المقال وتعديل تاريخه ليصبح «ايار 2002» (اذا كان التاريخ غير معروف يمكن اختيار «غير معروف» في القائمة المنسدلة)

– تكرار العملية مع مقال جديد «صدور Veronica لبيئة بلاي ستايشن 2»
– تخصيص المقال بالمفتاحين «بلاي ستايشن 2» و«تاريخ_الصدور»
– نشره وتغيير تاريخه (13 ايلول 2003)

نحصل للمقال الاول على:

مؤلف المقال هنا غير مهم بتاتاً (فمن غير النافع اضاعة الوقت في حذفه لأنه لن يُستخدم).

لاحظ اهمية طريقتنا في عرض مقالات القسم بالاعتماد على انواع مقالات معينة (اختبارات، استعراضات...): فلا يتم عرض المقالات المرتبطة بمفتاح «تاريخ_الصدور» (بخلاف الصفحات النموذجية القياسية التي تأتي مع SPIP والتي تعرض هذه «المقالات» الفارغة مثل غيرها).

عرض التاريخ في المقالات

عندما نكون داخل مقال (احدى الالعاب)، يكون تاريخ (تواريخ) الصدور في مقالات مرتبطة بمفتاح «تاريخ_الصدور» وموجودة في القسم نفسه. ولمعرفة تاريخ صدور لعبة معينة من داخل مقال اختبار (مثلاً)، يتحتم جلب المقال (او المقالات) المرتبط بالمفتاح «تاريخ_الصدور» والموجود في القسم نفسه.

في الصفحة النموذجية «article.html»، نقوم بإدخال التالي (بعد العنوان مباشرة مثلاً):

		<BOUCLE_out(ARTICLES){id_rubrique}{titre_mot=تاريخ_الصدور}>
		<li> #TITRE:
		[<b>(#DATE|affdate)</b>]
		</BOUCLE_out>

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

	<BOUCLE_out(ARTICLES){id_rubrique}{titre_mot=تاريخ_الصدور}>
	<li> تاريخ الصدور
		<BOUCLE_platform_out(MOTS){id_article}{type=البيئة}{"، "}>#TITRE</BOUCLE_machine_out>:
	[<b>(#DATE|affdate)</b>]
	</BOUCLE_out>

مما يعطي لدى زيارة الصفحة:
– تاريخ الصدور بلاي ستايشن 2: 13 ايلول 2003
– تاريخ الصدور دريم كاست: ايار 2002

لسنا راضين تماماً بعد (انه تدريب ويحق لنا ان نكون متطلبين): تعرض حلقة BOUCLE_out تواريخ الصدور لكل البيئات. الا ان مقالنا قد لا يتطرق الى كل البيئات. بالتالي، نريد عرض تواريخ الصدور المناسبة للبيئات التي يتطرق لها المقال وحسب.

هنا تتعقد الامور بعض الشيء ويجب استخدام احدى ميزات الحلقات:

<BOUCLE_plat2(MOTS){id_article}{type=البيئة}>
	<BOUCLE_out(ARTICLES){id_rubrique}{titre_mot=تاريخ_الصدور}>
	<BOUCLE_verify_key(ARTICLES){id_article}{id_mot}>
	<li> تاريخ الصدور
		<BOUCLE_platform_out(MOTS){id_article}{type=البيئة}{"، "}>#TITRE</BOUCLE_platform_out>:
	[<b>(#DATE|affdate)</b>]
	</BOUCLE_verify_key>
	</BOUCLE_out>
</BOUCLE_plat2>

تجد هنا حلقة BOUCLE_out وحلقة BOUCLE_platform_out المذكورتين سابقاً والتي لم يدخل عليهما اي تعديل. في المقابل، ظهرت حلقتان:

(1) تم وضع الكتلة كلها داخل حلقة BOUCLE_plat2 التي تقوم بجلب مفاتيح البيئات المرتبطة بهذا المقال. هكذا نحصل، داخل هذه الحلقة، على قيمة معينة لـ«id_mot» (اي معرّف كل بيئة مرتبطة بالمقال).

(2) حلقة BOUCLE_out لم تتغير وتقوم بجلب كل مقالات القسم المرتبطة بالمفتاح «تاريخ_الصدور». لاحظ ان هذه الحلقة لا تستخدم «id_mot»، بالتالي فإن مقالات هذه الحلقة هي في الوقت نفسه مقالات مرتبطة بمفتاح «id_mot» ومقالات غير مرتبطة. ثاني نقطة مهمة: هذه الحلقة هي من نوع (ARTICLES) ولا تسترجع اي معلومات حول المفاتيح. بالتالي، تبقى قيمة «id_mot» المحددة في حلقة BOUCLE_plat2 دون تغيير داخل هذه الحلقة.

(3) الحلقة BOUCLE_verify_key نهفة شيقة. فهي حلقة من نوع (ARTICLES) تختار المقال المعرّف بـ«id_article». الا اننا داخل حلقة BOUCLE_out التي كانت قد استرجعت مقالاً، بالتالي تسترجع حلقة BOUCLE_verify_key النتيجة نفسها! الا ان الفرق هنا هو ان حلقة BOUCLE_verify_key تضع معياراً اضافياً هو {id_mot} وبالتالي تفرض على المقال ان يكون مرتبطاً بالمفتاح المعرّف بـ«id_mot». والنتيجة هي كالتالي: اذا كان المقال الذي استرجعته حلقة BOUCLE_out مرتبطاً بالمفتاح المعرّف بـ«id_mot»، نتابع، اما اذ كان هذا المقال غير مرتبط بـ«id_mot»، نتوقف وننتقل الى المقال التالي.

– يمكننا اذا اعتبار حلقة BOUCLE_verify_key كمرشح: تأخذ المقال وتتأكد من انه يخضع لمعيار المفتاح.

– يمكننا عرض الامر بطريقة مختلفة: لا تتعدى حلقة BOUCLE_verify_key كونها معيار اختبار اضافي لحلقة BOUCLE_out. والابسط بالطبع، عدم استخدام حلقة BOUCLE_verify_key واضافة معيار آخر لحلقة BOUCLE_out هكذا:

<BOUCLE_out(ARTICLES){id_rubrique}{id_mot}{titre_mot=تاريخ_الصدور}>

اي، استرجاع مقالات القسم المرتبطة بالبيئة المعرّفة بـ«id_mot» والمفتاح «تاريخ_الصدور». هكذا يكون الامر مباشر اكثر، للأسف لا يقبل SPIP بهذا النوع من التركيب (يجب استخدام معيار واحد فقط يتعلق بالمفاتيح في الحلقة). بالتالي، فـSPIP سيرفض حلقة كهذه.

تلاحظ اننا قمنا بتكديس اربع حلقات متتالية لعرض معلومة قليلة الاهمية مثل تاريخ صدور اللعبة! هذا شيء قد يكون مؤسفاً ولكن نفضل اعتبار انه في حال فهمنا جيداً عمل الحلقات، نكتشف ان امكانات SPIP اوسع بكثير مما توحي به الصفحات النموذجية القياسية.

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