البحث في الموقع

مصطلح إطار العمل أو الفريم وورك Framework يعد أحد المصطلحات الفنية والبرمجية التي تربك المبتدئين على وجه الخصوص في بداية مشوار تعلم البرمجة والتي لا يستطيع فهم دلالتها ولا إدراك مدى أهميتها بشكل جيد. وكثيرًا ما يتساءل المبرمج المبتدئ عن معنى إطار العمل Framework وعن مزايا ومحدويات استخدام أطر العمل Frameworks في عمله البرمجي وعملية البرمجة عمومًا، وهل يتوجب عليه تعلم إطار عمل للغة برمجة محددة، أم أن تعلمه للغة البرمجة نفسها يكفيه في سوق العمل، وهل تعلم إطار العمل صعب ويستغرق وقتًا، ومالفرق بين إطار العمل والمكتبة، وغيرها من الأسئلة من هذا القبيل. فإذا كنت مهتمًا بعرفة الإجابة على كل هذه التساؤلات فتابع قراءة هذا المقال للنهاية. ما هو إطار العمل Framework؟ إطار العمل Framework في البرمجة هو ببساطة آلية يتم من خلالها إعداد وتجهيز كافة الوظائف الضرورية والشائعة التي تستخدم بكثرة عند تطوير التطبيقات والأنظمة وإتاحتها للمبرمج ليستخدمها ويستفيد منها في عمله دون أن يحتاج لإعادة كتابة هذه الوظائف بنفسه من الصفر وبهذا نستنتج أن استخدام إطار العمل يختصر الكثير من الوقت ويجعل العمل البرمجي أكثر كفاءة. لتفهم الأمر بصورة أفضل تخيل أنك تحتاج لكتابة سيرتك الذاتية، سيكون أمامك خياران إما أن تفتح مستندًا فارغًا وتبدأ بكتابة كل شيء وتنسيقه بنفسك من الصفر، أو تعتمد على قالب جاهز للسيرة الذاتية يكون مقسمًا ومنسقًا وكل ما عليك هو ملء البيانات الضرورية الخاصة بك فقط دون أن تشغل بالك بالكثير من التفاصيل الأخرى سيكون الخيار الثاني أفضل وأسرع بالتأكيد. يساعدك إطار العمل في مشروعك البرمجي بطريقة مشابهة فهو يعمل كقالب أو هيكل أساسي عليك الالتزام به لإنشاء التطبيقات الخاصة بك، ويوفر لك مجموعة من الأدوات أو المكونات أو الحلول البرمجية الجاهزة لبناء تطبيقات مخصصة بطريقة آمنة وسريعة ومنظمة. ستجد الكثير من أطر عمل لكل لغات البرمجة الشائعة مثل جافاسكريبت وبايثون و PHP وجافا، ومن أجل استخدام أي إطار منها عليك بداية تعلم كيفية تطوير المشاريع في كل إطار منها والاستفادة من التسهيلات الكثيرة التي توفرها لك هذه الأطر. ما الفرق بين إطار العمل والمكتبة؟ كثيرًا ما يتم الخلط بين مفهوم إطار العمل Framework ومفهوم مشابه له في البرمجة وهو المكتبة Library ورغم التشابه بينهما في طريقة العمل واستخدامهما بالتبادل في بعض الأحيان، إلا أن مفهوم المكتبة أبسط وأكثر محدودية فالمكتبة تركز على توفير وظيفة محددة في حين يوفر إطار العمل مجموعة متكاملة من الميزات التي تمكنك من برمجة تطبيقات في مجال محدد. تُعرَّف المكتبة بأنها عبارة عن مجموعة من التعليمات البرمجية المختبرة القابلة لإعادة الاستخدام والتي تنفذ وظيفة معينة وتحل مشكلة محددة، في حين ينفذ إطار العمل حزمة وظائف متكاملة أو يوفر مخططًا عامًا لبناء التطبيقات في حين لا توفر المكتبات هذه الميزة كما تحدد أطر العمل قواعد وإرشادات كتابة التعليمات البرمجية الخاصة بك وتنظم الملفات والمجلدات الخاصة بمشاريعك، ويمكن أن تتضمن مجموعة من المكتبات وتستخدمها لتنفذ مهام معينة. على سبيل المثال من بين المكتبات الشائعة نذكر مكتبة ريآكت React وهي مكتبة برمجية مبنية بلغة جافاسكربت ومتخصصة في بناء واجهات المستخدم ومكتبة jQuery التي تختصر العديد من الأكواد والتعليمات البرمجية المكررة في جافا سكريبت لتسهيل عملية البرمجة، ومن بين أطر العمل الشائعة نذكر أنجولار Angular وفيو Vue.js وهما إطارا عمل بلغة جافا سكريبت مختصان في تصميم واجهات مواقع الويب. ما الفرق بين إطار العمل ولغة البرمجة؟ يمكن للمطور أن يستخدم لغة البرمجة ويكتب كافة التعليمات البرمجية اللازمة لبناء التطبيقات من الصفر كما يمكنه إن شاء الاستعانة بإطار عمل Framework مخصص لتطوير برامجه وتطبيقاته. ورغم أن استخدام إطار العمل يفيد المطورين ويسرع وتيرة عملهم، إلا أنه يحد من حريتهم في كتابة التعليمات البرمجية ويقيد إمكانيات التطوير ويمكنهم من بناء تطبيقات لأغراض محددة فقط، في حين أن استخدام لغة برمجة يمكنهم من تطوير ما يشاؤون من تطبيقات متنوعة، حتى إطار العمل نفسه تم بناؤه في النهاية بإحدى لغات البرمجة. باختصار لغة البرمجة هي الأساس ومن خلال تعلمها يمكنك بناء ما تشاء من تطبيقات، أما إطار العمل فهو مصمم لنوع محدد من التطبيقات مثل تطبيقات الويب أو تطبيقات الجوال أو تطبيقات علم البيانات أو الذكاء الاصطناعي وإنترنت الأشياء …إلخ ويفضل أن تتعلم استخدامه بعد أن تتعلم البرمجة وتتمكن من أساسياتها. أهمية إطار العمل في البرمجة تبرز أهمية إطار العمل framework بشكل أساسي في كونه يتيح لك إعادة استخدام التعليمات البرمجية بدلًا من إعادة كتابتها من جديد، وفيما يلي جملة من الفوائد التي يمكن أن يوفرها استخدام إطار العمل: يساعد على توفير كود أكثر أمانًا لكونه يتضمن شيفرات تتحقق من المصادقات والصلاحيات وتحمي تطبيقك من الاختراق وتعالج الكثير من الثغرات الأمنية الشائعة مثل CSRF و XSS و SQL Injection. تركيز الجهود على كتابة التعليمات البرمجية الخاصة بالمشروع فقط بدلًا من برمجة وظائف متكررة وشائعة الاستخدام. توحد أنماط وقواعد كتابة التعليمات البرمجية وتوفر مخططًا عامًّا يمكن لكافة الفرق البرمجية فهمه بسهولة. يساعد في تطوير مشروعك وإضافة ميزات جديدة له بسهولة دون الحاجة للتعديل على الكود الأساسي لإطار العمل. يغني عن إعادة اختراع العجلة ويوفر لك الوقت والتكلفة اللازمين لتطوير المشاريع والتطبيقات. يساعد في كتابة كود نظيف وغير مكرر. يسهل عملية اختبار الكود وتصحيح الأخطاء البرمجية. يقلل بالعموم من كمية الأخطاء البرمجية لأنك ستكتب كود أقل وبالتالي ستنتج لديك أخطاء برمجية أقل. محدوديات إطار العمل لا شكَّ أن استخدام إطار العمل يفيدك كمطور ويساعدك على تسريع وتحسين العمل البرمجي، إلا أن الاعتماد على أطر العمل وحدها يفرض عليك بعض القيود وإليك أبرزها: يوفر وظائف محددة ويختص في بناء تطبيقات في مجالات معينة فقط. الاعتماد عليها قد يعيق المبرمج من فهم لغات البرمجة بشكل متعمق وواضح. بعض أطر العمل معقدة ويستغرق تعلمها وفهمها بشكل جيد وتطوير التطبيقات باستخدامها الكثير من الوقت. نحتاج إلى اختيار إطار العمل المناسب للتطبيق فاختيار الإطار غير الملائم قد يؤثر سلبًا على أداء تطبيقاتك وتجربة المستخدمين. تصدر لها تحديثات جديدة بشكل دوري، لذا سيتوجب عليك البقاء على اطلاع دائم على كل جديد ومعرفة كل الميزات الجديدة المضافة للإطار والمميزات التي تم الاستغناء عنها في كل إصدار. توقف تحديث إطار العمل أو تغيره ينعكس على سير عملية تطوير التطبيق المبرمج فيه وأمانه مثلما حصل مع إطار العمل AngularJS عندما قررت غوغل التوقف عن تطويره وإطلاق نسخة عنه مختلفة تمامًا. صفات إطار العمل الجيد تتوافر عشرات أطر العمل في المجالات البرمجية المختلفة الأمر الذي يشعرك بالحيرة في تحديد الإطار الأفضل لمشروعك ويجعلك تتساءل كيف أختار إطار العمل المناسب؟ بالعموم يتصف إطار العمل الجيد بثلاث صفات أساسية وهي: التوثيق الجيد توفير الوظائف المطلوبة لعملك الشهرة والدعم المجتمعي لنوضح بمزيد من التفصيل كل صفة من هذه الصفات وأهميتها في اختيار إطار العمل الأفضل. التوثيق الجيد اختر إطار عمل موثقًا بشكل جيدًا كي تتمكن من العودة إليه عندما تحتاج لمعرفة المزيد من المعلومات حول استخدام ميزة معينة أو حل مشكلة تواجهك في استخدامه، فالتوثيق الجيد يوفر عليك الكثير من الوقت والجهد. توفير الوظائف المطلوبة لعملك ضع في اعتبارك أن لكل إطار عمل حدود معينة لذا من الضروري أن تبحث بشكل جيد في ميزات الإطار الذي تريد اعتماده وتتأكد من أنه يلبي متطلبات مشروعك ويحقق لك كافة الوظائف والميزات التي تحتاج لتحقيقها بالشكل الأنسب، وبنفس الوقت لا تختر إطار عمل شديد التعقيد أو مكتظًا بالميزات التي قد لا تحتاجها على الإطلاق! الشهرة والدعم المجتمعي لاشك أن شهرة إطار العمل ووجود مجتمع داعم له يدل على قوته والطلب الكبير عليه في سوق العمل، لذا احرص على استخدام إطار عمل معروف وله قاعدة مستخدمين نشطة ويفضل بعض المبرمجين الاعتماد على أطر عمل حرة ومفتوحة المصدر وغير مقيدة أو مدعومة من شركات معينة لتخوفهم من انعكاس أي طارئ يحصل لها أو تغير في سياستها على إطار العمل. ولذلك السبب ترى البعض يميل إلى استخدام إطار العمل Vue.js الذي انبثق من أروقة المجتمع الحر بدلًا من إطار العمل Angular الذي ولد بين أروقة شركة غوغل مثلًا، ولكن هنالك طرف مقابل يشير إلى تنظيم وقوة وسرعة تطوير أطر العمل التي تقف خلفهم الشركات نظرًا لدعمهم السخي طويل الآجل عادةً خصوصًا إن وقفت شركات تقنية كبيرة خلفهم والحديث يطول في هذه النقطة وهي خارج موضوع المقال فقط أحببت الإشارة إليها نظرًا لأهميتها في أي نقاش يدور حول المفاضلة بينها. أنواع أطر العمل frameworks في البرمجة هناك عدة أنواع من أطر العمل حيث يختص كل إطار بمجال استخدام معين، وفيما بعض أهم أنواع أطر العمل حسب التطبيقات أو الوظائف التي يؤديها: 1. أطر عمل تطوير الويب Web development frameworks تستخدم هذه الأطر في تطوير تطبيقات الويب ومن أشهرها إطار عمل أنجولار Angular وفيو جي إس Vue.js وهي أطر عمل جافا سكريبت شائعة تستخدم لتطوير الواجهات الأمامية للويب، وإطاري عمل إكسبرس Express و NestJS وهي أطر عمل Node.js لتطوير الواجهات الخلفية للويب، وإطاري عمل جانغو Django وفلاسك Flask وهي أطر عمل مفتوحة المصدر مكتوب بلغة بايثون مخصصة لتطوير الواجهات الخلفية للويب، وإطار عمل Ruby on Rails الذي يوفر لك كل ما تحتاجه لإنشاء تطبيق ويب بسهولة وسرعة وأمان وإطار عمل لارافيل Laravel المبني بالاعتماد على لغة PHP. 2. أطر عمل تطوير الجوال Mobile development frameworks من أشهرها في تطوير تطبيقات الجوال نذكر إطار عمل React Native مفتوح المصدر مكتوب بلغة جافا سكريبت طورته فيسبوك لتطوير تطبيقات جوال متوافقة مع كافة الأنظمة الأساسية، وإطار أيونيك Ionic الذي يستخدم تقنيات الويب HTML و CSS وجافا سكريبت من أجل تطوير تطبيقات الجوال وهو يتكامل مع أطر تطوير الواجهات الأمامية مثل Angular و Vue، وإطار عمل فلاتر Flutter وهو إطار عمل مفتوح المصدر للغة دارت Dart من جوجل لتطوير تطبيقات الجوال وهو يدعم أنظمة iOS و Android ويحتوي على عناصر واجهة مستخدم قابلة للتخصيص بالكامل، وإطار عمل أباتشي كوردوفا Apache Cordova الذي يمكنك من تطوير تطبيقات هجينة للهاتف الجوال. 3. أطر عمل علم البيانات Data science frameworks تعرف هذه الأطر كذلك بأطر التعلم الآلي Machine Learning Frameworks وهي تساعد علماء البيانات على إنشاء نماذج تعلم آلي وتصميمها بشكل أسرع وأسهل واستخراج المعلومات المفيدة من مجموعات البيانات بالاستفادة من تقنيات البرمجة والذكاء الاصطناعي والتعلم الآلي. وهناك العديد من أطر عمل علم البيانات ومن ضمنها scikit-Learn و XGBoost و TensorFlow و PyTorch. 4. أطر إدارة المحتوى Content management frameworks تعرف أيضًا باسم نظم إدارة المحتوى Content Management Systems أو اختصارًا CMS هي برمجيات توفر مكونات قابلة لإعادة الاستخدام لإنشاء وإدارة محتوى الويب وعرضه ضمن مدونات أو مواقع إلكترونية أو تطبيقات جوال وهي توفر ميزات أخرى مثل سهولة الاستخدام وتحسين محركات البحث والأمان. ومن أشهر هذه النظم نذكر نظام ووردبريس WordPress الشهير المستخدم في إنشاء ما يقارب من نصف المواقع الإلكتروني ودروبال Drupal الذي يعد نظام مثالي لتطوير المواقع التي تحتوي على الكثير من المحتوى وهو يتطلب معرفة تقنية أكثر من بقية نظم إدارة المحتوى. 5. أطر عمل أتمتة الاختبار Test Automation frameworks يستخدم مطورو البرمجيات أطر عمل الأتمتة من أجل إنشاء حالات اختبار التطبيقات والتأكد من سير عملها بكفاءة وتوفر لهم أدوات وتوصيات للتحقق من جودة البرمجيات واتباع معايير الترميز المناسبة. من أشهر أطر الاختبار نذكر سيلينيوم Selenium وهو إطار مفتوح المصدر لأتمتة اختبار تطبيقات الويب، وCypress المبني بجافا سكريبت والمخصص لاختبار الواجهة الأمامية لتطبيقات الويب، و Playwright للاختبار الشامل لتطبيقات الويب. هل يمكن البدء باستخدام إطار العمل دون تعلم لغة البرمجة؟ لاشك أن إطار العمل يوفر لك كمطور أداة قيمة لتطوير البرامج التطبيقات المختلفة، لكن السؤال الذي يطرح نفسه هل يغني تعلم أطر العمل واستخدامها في بناء التطبيقات العملية عن تعلم لغات البرمجة وفهمها بشكل متعمق؟ في الواقع حتى لو لم تكن ترغب في تطوير التطبيقات بإحدى لغات البرمجة وتميل للاستفادة من ميزات أحد أطر العمل فلا غنى لك عن تعلم لغة البرمجة وفهم أساسياتها إلى جانب إطار العمل فكلما فهمت لغة البرمجة بشكل أفضل سيسهل عليك فهم أطر العمل. كما أن تعلّم البرمجة يوسع أفق عملك ويمكنك من بناء العديد من التطبيقات في مختلف المجالات، أما إطار العمل فهو مصمم كما ذكرنا سابقًا لغرض واحد فقط وبالتالي سيقيدك بنوع محدد من التطبيقات. ويمكن باختصار أن نلخص الإجابة على هذا السؤال بجملة واحدة: يمكنك استخدام أطر العمل، لكن قبل ذلك تعلم أساسيات لغة البرمجة واتقنها ثم استفد من ميزات إطار العمل الخاص بتلك اللغة كما يحلو لك. الخلاصة تعرفنا اليوم على مفهوم إطار العمل Framework ودوره المهم في توفير الوظائف القياسية وتحديد الخطوط العريضة التي تنظم المشاريع البرمجية وتوفر وقت وجهد المطورين والمبرمجين، واكشتفنا أهم الفروقات بين أطر العمل وبين أدوات تطوير البرامج الأخرى مثل المكتبات ولغات البرمجة، وتعلمنا طريقة اختيار أفضل إطار عمل يناسب متطلباتنا وعددنا أهم صفات إطار العمل الجيد، وأخيرًا استعرضنا قائمة بأهم أطر العمل المستخدمة في مجالات مختلفة كتطبيقات الويب وتطبيقات الجوال وغيرها من المجالات. هل تستخدم في عملك أحد أطر العمل التي وردت في سياق المقال أو أطر عمل أخرى؟ ما هو هذا الإطار وفي أي مجال تستخدمه؟ هل هناك أي مشاكل تواجهها في التعامل مع هذا الإطار أم أنك راضٍ عن أدائه. شاركنا تجربتك في التعليقات أسفل المقال. اقرأ أيضًا تعلم أساسيات البرمجة قواعد البرمجة ببساطة للمبتدئين أسهل لغات البرمجة مهندس البرمجيات من هو وما هي مهامه تعرف على تخصص هندسة البرمجيات

تعرّفنا في الدّرس السّابق على كيفيّة تهيئة بيئة التّطوير وكيفيّة إنشاء تطبيق يقبل قيما من المُستخدم ويُعالجها ثمّ يُرجع النّتيجة على شكل صفحة HTML ليقرأها المُتصفّح، لكنّنا لم نستخدم لغة HTML كما يجب لأنّنا وضعنا شيفراتها داخل ملفّ app.py المكتوب بلغة بايثون. ما يعني بأنّنا جمعنا لغتين في ملفّ واحد، وهذا أمر غير مُناسب ولا يُمثّل مُمارسة جيّدة، الطريقة الأنظف هي بجعل شيفرات بايثون مُستقلّة عن شيفرات لغة HTML. وهذا بالضّبط ما سنتعلّمه في هذا الدّرس. استعمال قوالب HTML يُمكن فصل ملفّات HTML عن ملفّ لغة بايثون بوضعها داخل مُجلّد باسم templates (اسم المُجلّد مهم)، ويكون هذا المُجلّد في نفس مسار الملف app.py. بعد ذلك يُمكن تقديم الملفّ من قبل التّطبيق المكتوب بلغة بايثون عبر الدّالة render_template (يجب استيرادها في البداية) مع تمرير اسم الملفّ. أولا ادخل إلى مُجلّد flask_app ثمّ أنشئ مجلّدا جديدا باسم templates بعدها أنشئ ملفّا باسم index.html داخل هذا المُجلّد، وضع به شيفرة HTML التّاليّة: <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>الصّفحة الرّئيسيّة</title> </head> <body style="direction: rtl;"> <h1>السّلام عليكم ورحمة الله</h1> </body> </html> يُمكننا الآن أن نجعل التّطبيق app.py يُقدم هذه الشّيفرة، وذلك أولا باستيراد الدالة render_template واستدعائها مُباشرة بعد جُملة return. # -*- coding:utf8 -*- from flask import Flask, render_template app = Flask(__name__) # Home Page @app.route("/") def home(): return render_template('index.html') if __name__ == "__main__": app.run(debug=True) بعد تشغيل التّطبيق زر العنوان http://127.0.0.1:5000. ستُلاحظ بأنّ مُحتوى الصّفحة هو نفسه مُحتوى الملفّ index.html، ويُمكنك مُشاهدة مصدر الصّفحة بالضّغط على زر الفأرة الأيمن واختيار الخيار View Page Source. تمرير متغير وعرض قيمته يُمكن تمرير المُتغيّرات إلى ملفّ HTML لعرض قيمها بإضافتها كمُعاملات للدّالة render_template. # Home Page @app.route("/") def home(): return render_template('index.html', page = u"الصّفحة الرّئيسيّة") لاحظ بأنّنا قُمنا بإضافة المُتغيّر page وأسندنا له القيمة "الصّفحة الرّئيسيّة"، يُمكننا الآن عرضه في ملفّ HTML بإحاطته بعلامات {{ }}، في المثال التّالي، نعرض قيمة المُتغيّر page داخل وسم h3 مُباشرة بعد الجملة الرّئيسيّة. <body style="direction: rtl;"> <h1>السّلام عليكم ورحمة الله</h1> <h3>{{ page }}</h3> </body> بعد تعديل الملفّ وحفظه ستُلاحظ بأنّ السّطر {{ page }} قد تغيّر إلى عبارة "الصّفحة الرّئيسيّة". عند مُشاهدة مصدر الصّفحة ستُلاحظ بأنّ السّطر: <h3>{{ page }}</h3> قد تحوّل إلى السّطر: <h3>الصّفحة الرّئيسيّة</h3> وهذا هو العمل الرّئيسي لمُحرّك القوالب Jinja2. يُمكن كذلك تقديم نفس ملفّ HTML عبر أكثر من توجيه، كما يُمكن أن تكون قيم المُتغيّرات المُمرّرة مُختلفة، فمثلا المُوّجه الرّئيسي / سيؤدي إلى تقديم الصّفحة index.html مع مُتغيّر يحمل القيمة "الصّفحة الرّئيسيّة". ويُمكن إضافة توجيه آخر /hello، مع تقديم نفس الملفّ ومُتغيّر page بالقيمة "صفحة التّرحيب". وبالتالي سيُصبح التطبيق الكامل كالآتي: # -*- coding:utf8 -*- from flask import Flask, render_template app = Flask(__name__) # Home Page @app.route("/") def home(): return render_template('index.html', page = u"الصّفحة الرّئيسيّة") # Hello Page @app.route("/hello") def hello(): return render_template('index.html', page = u"صفحة التّرحيب") if __name__ == "__main__": app.run(debug=True) يُمكنك كذلك عرض قيمة المُتغيّر في أكثر من موضع، مثلا يُمكنك وضعه كعنوان للصّفحة داخل الوسم title. <head> <meta charset="UTF-8"> <title>{{ page }}</title> </head> بعد تشغيل التّطبيق، سنتمكّن من الوصول إلى صفحتين تُقدّمان نفس ملفّ HTML مع اختلاف في قيمة المُتغيّر page (أي اختلاف في مُحتوى الوسم h3 وعنوان مُناسب لكلّ صفحة). الصّفحة الرّئيسيّة: http://127.0.0.1:5000 صفحة التّرحيب: http://127.0.0.1:5000/hello التعليقات يُمكن وضع تعليقات في مُحرّك القوالب Jinja2 بإحاطتها بعلامات {# تعليق #}، والتّعليق لن يظهر حتى بعد النّظر إلى مصدر الصّفحة، ويُمكن استعماله كالتّالي: <body style="direction: rtl;"> <h1>السّلام عليكم ورحمة الله</h1> {# هذا تعليق لن يظهر للزائر #} <h3>{{ page }}</h3> </body> الجمل الشرطية في محرك القوالب Jinja2 تعرّفنا إلى الآن على طريقة تقديم ملفّات HTML وكيفيّة تمرير المُتغيّرات من ملفّ بايثون إلى ملفّ HTML وكيفيّة عرض قيّمها. لكن مُحرّك القوالب Jinja2 ليس لهذا الغرض فقط، بل يُمكّننا كذلك من استعمال خصائص لغة بايثون، مثل الجمل الشّرطية وحلقة التّكرار for وغير ذلك. انتبه فقط إلى حقيقة أنّ بنية الجمل Syntax الخاصة بلغة بايثون مُختلفة عن بنية الجملة في مُحرّك القوالب Jinja2. فمثلا جملة شرطيّة في لغة بايثون ستكون كالتّالي: x = 10 if x == 10: print x أمّا في Jinja2 فستكون كالتّالي: {% set x = 10 %} {% if x == 10 %} {{ x }} {% endif %} أول فرق قد تُلاحظه هو أنّ جميع الشيفرات مُحاطة بالعلامات {% %} وعرض المُغيّر يكون داخل علامات {{}}. وبالنّسبة لتعريف مُتغيّر وإسناد قيمة له فيلزمه كلمة set. كما يجب إنهاء الجملة الشّرطية بجملة endif، كما أنّ الإزاحة ليست ضروريّة في مُحرّك Jinja2. مُلاحظة: يُفضّل عدم تعريف المُتغيّرات مُباشرة في ملفّات HTML إلا لحاجة، ومن الأفضل تعريفها داخل ملفّات بايثون. لإضافة جملتي elif و else يُمكن القيام بالتّالي: {% set x = 6 %} {% if x == 10 %} x يُساوي 10 {% elif x == 5 %} x يُساوي 5 {% else %} x يُساوي شيئا آخر {% endif %} جرّب تغيير قيمة المُتغيّر x وانظر إلى النّتيجة. حلقة for تعرّفنا على كيفيّة عرض مُتغيّر يحمل قيمة واحدة فقط، لكن ماذا لو أردنا أن نعرض عناصر قائمة ما، بحيث يعرض كلّ عنصر داخل وسم مُعيّن، يُمكن ذلك عبر حلقة for ويُمكن كتابتها كالآتي: {% for item in list %} <h1> {{ item }} </h1> {% endfor %} بحيث list هي القائمة مُتعدّدة العناصر. مثال لنفترض بأنّه لدينا قائمة مقالات لعرضها للزائر، بحيث تكون القائمة كالتّالي: posts = [ u"مُحتوى المقال الأول", u"مُحتوى المقال الثاني", u"مُحتوى المقال الثالث", u"مُحتوى المقال الرابع" ] سنقوم أولا بإنشاء توجيه جديد باسم posts إلى ملفّ app.py وسنُمرّر ملفّ index.html مع تمرير القائمة إلى الملف. # Posts Page @app.route("/posts") def posts(): posts = [ u"مُحتوى المقال الأول", u"مُحتوى المقال الثاني", u"مُحتوى المقال الثالث", u"مُحتوى المقال الرابع" ] return render_template('index.html', posts = posts, page = u"صفحة عرض المقالات") لاحظ بأنّ المُعامل الثاني للدّالة render_template هو posts = posts، الأمر يعني بأنّ القائمة المُمرّرة للقالب اسمها posts وستحمل قيّم القائمة posts المتواجدة في الأعلى. يُمكن عرض كل مقال داخل وسم p بالطّريقة التّاليّة: {% for post in posts %} <p> {{ post }} </p> {% endfor %} يُمكنك الآن زيارة مُدوّنتك المُتواضعة عبر الرّابط http://127.0.0.1:5000/posts. إذا قُمت بعرض مصدر الصّفحة فستُلاحظ ما يلي: <h3>صفحة عرض المقالات</h3> <p> مُحتوى المقال الأول </p> <p> مُحتوى المقال الثاني </p> <p> مُحتوى المقال الثالث </p> <p> مُحتوى المقال الرابع </p> لاحظ بأنّ الوسم p قد تكرّر مع عرض كلّ عنصر. تنسيق الصفحات، إضافة الملفات الساكنة الملفّات السّاكنة هي الصّور وملفّات CSS أو Javascript وتوضع في مُجلّد باسم static بجانب المُجلّد templates. في هذا القسم سنُضيف ملفّ CSS لتنسيق عرض المقالات أعلاه. أنشئ مُجلّدا باسم static داخل مُجلّد المشروع (بجانب المُجلّد templates). بعدها أنشئ 3 مُجلّدات داخل هذا المُجلّد أسماؤها كالتّالي: static ---| css # هنا توضع ملفّات التّنسيق ---| js # في هذا المُجلّد يُمكنك وضع ملفّات جافاسكريبت ---| img # ضع الصّور في هذا المُجلّد بعد إنشاء المُجلّدات أنشئ ملفّ تنسيق باسم style.css داخل مُجلّد css، وضع به ما يلي: body { text-align: center; } h3 { color:#1383EA; } p { font-size: 14px; } للرّبط بين ملفّ css وملفّ HTML، يُمكننا الاعتماد على دالة url_for التّي يُقدّمها مُحرّك القوالب Jinja2 لإعطاء مرونة أكثر في التّعامل مع ملفّات مُتعدّدة، واستخدامها يكون كالتّالي: {{ url_for('static', filename='path/to/file') }} مع تغيير path/to/file إلى مسار الملفّ. وبالتّالي لتضمين ملفّ style.css داخل ملفّ index.html فسيتوجّب علينا إضافة السّطر التّالي إلى وسم head. <link rel="stylesheet" href="{{ url_for('static', filename='css/style.css')}}"> بعد حفظ الملفّ ستُلاحظ بأنّ المُحتوى أصبح يتوسّط الصّفحة، وستُلاحظ كذلك بأنّ لون عنوان الصّفحة قد تغيّر إلى الأزرق. مُلاحظة: عند التّعديل على ملفّ التنسيق وحفظه قد تحتاج إلى إعادة تحميل الصّفحة كاملة بتركيبة المفاتيح CTRL+SHIFT+R وذلك لأنّ المُتصفّح يخبّئ الملف عند أول مرّة تزور فيها الصّفحة وبالتالي فسيعطيك نفس الملف غير المُعدّل في كلّ مرّة تعيد فيها تحميل الصّفحة، والحلّ هو بإعادة تحميل كاملة لجميع الملفّات. ربط ملفات Javascript مثلما هو عليه الحال مع ملفّات css يُمكنك ربط ملفّات جافاسكريبت بوضعها داخل وسم script واستخدام الدّالة url_for. إليك مثالا: <script src="{{ url_for('static', filename='js/main.js')}}"></script> مع مُلاحظة بأنّ ملفّ main.js يجب أن يكون داخل المُجلّد js وليس في مكان آخر. عرض الصور يُمكن كذلك استعمال الدّالة لعرض الصّور، كلّ ما عليك فعله هو وضع الصّورة داخل المُجلّد img وعرضها بالدّالة url_for داخل وسم img، مثلا ضع صورة حسب رغبتك داخل المجلّد img وسمّها logo.png. لعرضها أعلى الصّفحة يُمكن إضافة السّطر التّالي مُباشرة بعد وسم body. <img src="{{ url_for('static', filename='img/logo.png')}}" /> بهذا سيُصبح التّطبيق كالتّالي: يُمكنك تصفّح ملفّات التّطبيق من هذا الرّابط. خاتمة بعد أن تعرّفنا على طريقة تمرير قيم المُتغيّرات من بايثون إلى ملفّات HTML أصبح بإمكاننا أن نستعمل قاعدة بيانات تحتوي على جدول للمقالات عوضا عن استعمال قائمة أو قاموس، في الدّرس القادم سنتعرّف على قاعدة البيانات SQLite يُمكن استخدامها لحفظ المقالات.

سيكون هذا الدرس مُتابعة لدروس Boostrap الّتي قدّمتها الأكاديميّة، وفيه سيتمّ تجهيز وتخطيط صفحة عامّة تصلح لمُختلف الأغراض والاحتياجات. يعود استخدام أُطر العمل (frameworks) بالنفع الكبير على المُطوّر، حيثُ لم يَعد على المُطوّر التفكير بالمشاكل المُتكرّرة ورُبما التافهة، وهي مشاكل قد تمّ حلها بالفعل من قبل صانعي أُطر العمل، فعلى السبيل المثال، التوافقيّة بين المُتصفّحات، دعم أبعاد أو أحجام الشاشة المُختلفة (التجاوبية)، إلى آخره من المشاكل الأخرى، ويُسرّع هذا الأسلوب أو هذا النمط من التطوير كثيرًا من عمليّة تخطيط وتطوير الموقع. يتميّز إطار العمل Bootstrap بشهرته الواسعة الّتي يتمتّع بها، الأمر الّذي يجعل من صيانة وتنقيح شيفرة أي مُطوّر سهلةً في التعديل من قِبل أي مطوّرٍ آخر، مع عدم إغفال الدعم والتوثيق القويّ الّذي يملكه على الإنترنت. تبرز مساوئ استخدام أُطر العمل في حقيقة أنّ على الصّفحة تحمّل أعباء مُجمل شيفرة الإطار (مُجمل التنسيقات الزائدة)، وحتّى عند استخدام جزء صغير من الإطار، على الجهة الأُخرى، فإن أُطر العمل هي أداةٌ فعّالة في بناء نماذج أوليّة للمشاريع (prototyping)، أو في إنشاء صفحات يكون فيها جماليّة التصميم أمرًا ثانويًّا، كما هو الأمر مع صفحات إدارة الموقع (administration pages)، ولكن عند الرغبة في إنشاء تصميم مُحدّد وذو مواصفات مُعيّنة، فإن استخدام هذه الأُطر قد يُصعب من عمليّة التصميم أكثر مما هو عليه الأمر من بناء التصميم من نقطة الصفر، ومع ذلك فهو أمرٌ مُمكن وليس مُستحيلًا. سيكون المشروع النهائيّ على الشكل التّالي: ملاحظة حول استخدام Bootstrap يوجد طرقٌ عدّة للتعامل مع تنسيقات إطار العمل Bootstrap، سواءً بدون استخدام LESS أو باستخدام LESS. استخدام Bootstrap بدون LESS يُستحسن للمُبتدئين في التعامل مع Bootstrap تنزيل نسخة Bootstrap المُترجمة/المُجمّعة (compiled) وإرفاقها في المشروع، ومن ثمّ القيام بإنشاء ملفّ CSS فارغ وربطه مع المشروع بعد ملفّ bootstrap.css: <link href="css/bootstrap.min.css" rel="stylesheet"> <link href="css/styles.css" rel="stylesheet"> ولكي يتمّ التغيير من تنسيقات bootstrap الافتراضيّة، فيجب الكتابة في الملفّ style.css: a { color: #00ff00 } block { background-color: #dddddd } إن مساوئ استخدام الأسلوب السابق كما هو واضح هو أنّ على المُطوّر البحث يدويًّا عن التنسيق الصحيح عند التغيير، ولن يكون الأمر سهلًا في مُعظم الأحيان، باعتبار أنّ بعض المُعامِلات (parameters) تُطبّق على العديد من المُحدّدات (selectors) عند التعديل، مع العلم أن أداة التخصيص الخاصّة بالإطار قد تساعد المُطوّر بعض الشيء، حيثُ أنها تستطيع ترجمة جميع تغييرات المُطوّر، ولمرّة واحدة، ولكن عند رغبة المُطوّر في تغيير مُعامل جديد، فعليه إعادة تحديث جميع قيم الحقول لكي يُعاد ترجمتها مرّةً أُخرى. استخدام Bootstrap مع LESS تعمل هذه الطريقة بجعل جميع متغيّرات Bootstrap مخزّنة في ملفّات ذات اللاحقة .less، وعلى المُطوّر العمل مع هذه المتغيّرات وترجمتها إلى ملفّات ذات اللاحقة .css (يدويًّا أو آليًّا) وكما تقتضي الضرورة. مع العلم أنّ في ملفّ HTML كل ما يجب عمله هو ربط ملفّات CSS المُترجمة، ولذلك فإن هذه الطريقة هي الطريقة الأفضل والأكثر مرونةً. يوجد العديد من الطرق في تجميع أو ترجمة ملفّات LESS، وحرية الاختيار للمطوّر، مع العلم أنّ Bootstrap نفسه يستخدم Grunt في تجميع ملفّات less، ومن الخيارات المُتاحة هو WinLess لمُستخدمي ويندوز، أو SimpLESS لمُستخدمي أنظمة Mac، أو Koala لمُستخدمي لينكس، وتعمل جميع هذه الأدوات الأمر نفسه، وذلك عبر الوصول إلى ملفّات LESS والانتظار لحدوث أي تغيير فيها، وعندما يقوم المُطوّر بإجراء هذا التغيير، ستقوم الأداة بتجميع وإنشاء ملفّ CSS الموافق، ولذلك ليس على المُطوّر إجراء التجميع أو الترجمة يدويًّا بعد كل تغيير، فبكل بساطة يتم إجراء التغييرات ومن ثم الحفظ، لتظهر النتائج بشكل مُباشر على الموقع وهي بالفعل مُترجمة (compiled) ومضغوطة (compressed). إنشاء المشروع باستخدام Bootstrap سيتمّ في البداية إنشاء بُنيان وهيكليّة ملفّات المشروع وذلك عبر: إنشاء مُجلّد باسم المشروع وليكن whitesquare-bootstrap. إنشاء مجلدان فرعيان: الأول src للملفّات المصدريّة، والثّاني www لملفّات الموقع النهائيّة. إنشاء مجلد فارغ بالاسم images وملفّ فارغ بالاسم index.html داخل المُجلّد www. تنزيل Bootstrap ونسخ مُحتويات الملفّ المضغوط إلى مُجلّد www. تنزيل الملفّات المصدريّة الخاصّة بـ Bootstrap ونَسخ منها المُجلّد less، ووضعه في المُجلّد src الخاصّ بالمشروع. إنشاء ملفان بجانب المُجلّد less/bootstrap، يحمل الأوّل الاسم styles.less ويحمل الثّاني الاسم variables.less، ليتم استخدامهم في تعديل خصائص Bootstrap الأساسيّة، وهذا يُقدّم سرعة في التحديث والتعديل على التنسيق. سيتمّ في الخطوة التّالية إعداد عمليّة ترجمة ملفّات LESS إلى CSS. سيتمّ العمل على الأداة WinLess، وهي سهلة الاستخدام، فكل ما يجب عمله هو اختيار ‘Add folder’ منها، ومن ثُمّ تحديد مسار المُجلّد الّذي يحتوي ملفّات LESS: C:\whitesquare-bootstrap\src\less يحتوي المُجلد السابق على قائمة بجميع الملفّات، سيتمّ اختيار الملفين الأخيرين: styles.less و variables.less، ومن ثُمّ الضغط بالزر الأيمن واختيار من القائمة المُنسدلة الاختيار ‘Select output file’، ومن ثُم تحديد مسار ملفّات CSS. ..\..\www\css\styles.css ..\..\www\css\variables.css بعد ذلك، وعند إجراء أي تعديل على ملفّات LESS، سيتمّ إعادة الترجمة من جديد للحصول على ملفّات CSS مُترجمة وبالتعديلات الجديدة. ملاحظات أصبحت تركيبة وبنية المشروع جاهزة بعد إنشاء الملفّات السابقة، ولكن على المُطوّر الأخذ بعين الاعتبار الأمور التّالية قبل الشروع في التصميم: كيف ستقدّم الصّور، كيف سيتمّ توزيعها وتقسيمها في أرجاء الصّفحة. كيف سيتمّ استخدام المُكوّنات (components). ما هي التنسيقات الأساسيّة. ما هو المُخطّط النهائي. بعد الإجابة على الأسئلة السابقة من المُمكن المُتابعة مع التصميم. إعداد صور الموقع سيتمّ في هذه المرحلة تجهيز الصور والّتي ستستخدم في جميع الصفحات وليس لها علاقة بالمُحتوى، وستكون هذه الصور في المشروع الحالي على الشكل التّالي: الصورة الّتي تعرض عنوان الموقع (خريطة): images/map.png صور شعار الموقع: images/logo.png images/footer-logo.png صور الخلفيّة: /images/bg.png /images/h1-bg.png صور الأيقونات الاجتماعية، وهي مُقسّمة على صورتين ليتم استخدام أسلوب sprite معهم بهدف تحميل الصّفحة بشكل أسرع: /images/social.png /images/social-small.png المُكوّنات (Components) يَكمن الاختلاف بين تصميم الموقع باستخدام Bootstrap وبين التصميم باستخدام الأدوات الأصليّة (native) في أنّ Bootstrap يُقدّم مفهوم المُكوّنات (components)، وتُمثل هذه المُكوّنات أجزاءً شائعة من HTML مُعدّة بشكل مُسبق مع تنسيقها، وتَستخدم في بعض الأحيان هذه المُكوّنات جافا سكريبت، ومن المُمكن استخدام مكوّنات Bootstrap كما هي، أو يُمكن إعادة تنسيق هذه المُكوّنات، فكل ما يحتاجه الأمر هو تغيير قيم المُتغيّرات في Bootstrap لذلك، ولكن عند الرغبة في المزيد من المرونة في التغيير، فيُمكن للمُطوّر دائمًا تغيير وتعديل HTML و CSS كما يَحلو له، وفي العودة إلى المشروع، يُمكن مُلاحظة أنّه سيتمّ الحاجة إلى المُكوّنات التّالية: من أجل تصميم الأعمدة (columns) وتوزيعها، سيتمّ استخدام النّظام الشبكي (row, col). من أجل إجراء حقل البحث، والذي هو نموذج (form) من النوع "ضمن السطر" (inline) سيتمّ استخدام (form-inline - input-group - btn) من أجل التنقّل (navigation)، سيتمّ استخدام الوسم <nav> مع الصنف (navbar). من أجل القوائم الفرعيّة، سيتمّ استخدام قائمة مُجمّعة (group list) وباستخدام الصنف list-group. من أجل لوحة الظهور (panel) سيتمّ استخدام النصف panel. من أجل لوحة ظهور كبيرة سيتمّ استخدام الصنف jumbotron. من أجل إطارات الصور، سيتمّ استخدام thumbnail. تظهر جميع المُكونات السابقة في توثيق المكوّنات الخاصّ بـ Bootstrap. تنسيق أساسي يَملك Bootstrap بالفعل مُعظم التنسيقات المطلوبة للمشروع، ولكن سيتمّ الحاجة فقط إلى التعديل عليهم عند الحاجة، ويُمكن عمل ذلك بالتعديل على الملفّ src/less/variables.css. سيتمّ أوّلًا إضافة بعض المُتغيّرات والّتي لم يتمّ إعدادها افتراضيّا في Bootstrap، ولكي يتمّ استخدامها فيما بعد: يَضبط المُتغيّر التّالي الخط المُستخدم في المشروع: @brand-font: 'Oswald',sans-serif; كما سيتمّ التعديل على خيارات Bootstrap للتوافق مع رؤية المشروع، والّتي ستكون في مُعظمها تخصّ الألوان: /* gray background of the page */ @body-bg: #f8f8f8; /* blue background */ @ brand-primary: #29c5e6; /* background of panels */ @panel-bg: #f3f3f3; /* frame color of panels */ @panel-inner-border: #e7e7e7; /* remove rounding in blocks */ @border-radius-base: 0; /* primary buttons have blue background */ @btn-primary-bg: @brand-primary; /* if the screen width is more then 992px, then the container width is 960px */ @container-md: 960px; /* if the screen width is more 1200px, then the container width is 960px again */ @container-lg: @container-md; /* main font is Tahoma */ @font-family-base: Tahoma, sans-serif; /* base font size */ @font-size-base: 12px; /* main color of text */ @text-color: #8f8f8f; /* gray background of text fields */ @input-bg: @panel-bg; /* gray frame of text fields */ @input-border: @panel-inner-border; /* gray color of the text in the fields */ @input-color: #b2b2b2; سيتمّ البدء في كتابة التنسيقات الخاصّة بالمشروع، بعد أنّ تمّ الانتهاء من المُتغيّرات، وذلك في الملفّ styles.less، لكن يجب أوّلًا استيراد ملفّ Bootstrap العامّ وملفّ المُتغيّرات: @import "bootstrap/bootstrap.less"; @import "variables.less"; يَجدر الذكر هنا، أنّ ليس جميع التنسيقات (التي تكون مُعدّة من قبل الإطار نفسه) من المُمكن تغييرها باستخدام المُتغيّرات، بل يجب تغييرها يدويًّا: p { margin: 20px 0; } .form-control { box-shadow: none; } .btn { font-family: @brand-font; } body { border-top: 5px solid #7e7e7e; background-image: url(../images/bg.png); } ستقوم السطور السابقة بإزالة ظل عناصر النموذج (form elements)، وتحديد خطّ خاصّ للنصّ داخل الزر، وإضافة صورة خلفيّة لكامل الصّفحة وحدّ (border) علوي لها. لن يتمّ بعد الآن ذكر مكان وضع التنسيقات، فستكون دائمًا على الشكل التّالي: المُتغيرات في الملفّ variables.less، وجميع التنسيقات المُخصّصة ستكون في الملفّ styles.less. هيكل HTML يبدأ مُخطط الموقع عادةً بما يُسمى هيكل HTML أو HTML skeleton، وهو على الشكل التّالي: <!DOCTYPE html> <html> <head> <title>Bootstrap 3 page layout</title> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <link href="css/styles.css" rel="stylesheet"> <!--[if lt IE 9]> <script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script> <script src="https://oss.maxcdn.com/libs/respond.js/1.3.0/respond.min.js"></script> <![endif]--> </head> <body> </body> </html> تمّ في السطور السابقة العمل على بُنيان مُستند HTML5 الرئيسي، حيثُ تمّ في الوسم title الإشارة إلى عنوان الصّفحة، وهو ‘Bootstrap 3 page layout’، وفي الوسم <meta> تحديد عرض الصّفحة على أجهزة الهاتف المحمول ليكون مساويًا إلى عرض الشاشة، وضبط مُستوى التكبير (zoom level) في التحميل الأوّل للصفحة، ومن ثُم تمّ ربط صفحة التنسيق (stylesheet)، ومن أجل المُتصفّح Internet Explorer (قبل الإصدار التاسع) تم كتابة سكريبت يَسمح بعرض مُخطّط الصّفحة بشكل مُلائم. مُخطّط الصّفحة يتألّف مُخطّط الصّفحة من جزئيين: الحاوية الرئيسيّة للمُحتوى الرئيسي، والّتي تتمركز الشاشة وذيل الصّفحة (footer)، وتتألّف الحاوية الرئيسيّة من عمودين: المُحتوى الرئيسي، والشريط الجانبي (sidebar)، ويأتي من الجهة العلويّة رأس الصّفحة (header)، وشريط التنقل (nav)، وعنوان الصّفحة (heading). سيتمّ إضافة الشيفرة (الكود) التّالية إلى جذع الصّفحة (body): <body> <div class="wrapper container"> <header></header> <nav></nav> <div class="heading"></div> <div class="row"> <aside class="col-md-7"></aside> <section class="col-md-17"></section> </div> </div> <footer></footer> </body> تقدّم الشيفرة السابقة التقسيم العام الخاصّ بالأعمدة (columns)، وهي مُحتوات داخل الصنف (class) المُسمى صفّ (row)، وتبدأ أصناف الأعمدة بالبادئة col-، ومن ثم حجم الشاشة وهو أحد أربع (xs, sm, md, lg)، ومن ثم تنتهي بقيمة عرض العمود. يُمكن للأعمدة أنّ تُحدّد معًا وبقيم أصناف مُختلفة للشاشات، وتُعبّر هذه الأصناف عن عرض العمود لقياسات الشاشة المُختلفة، فمثلًا: class="col-xs-12 col-md-8" سيتمّ تطبيق الصنف col-xs-12 مع الشاشات كبيرة الحجم، وتطبيق الصنف col-md-8 على الشاشات الصغيرة، وتُطبّق هذه الأصناف على عرض الشاشات الأكبر والمساوي لقيمة الصنف المُحدّد، وعليه فإن تطبيق الصنف col-md-* على العنصر، سوف لن يؤثر على أجهزة الشاشات المُتوسطة فقط بل أيضًا على أجهزة الشاشات الكبيرة، وذلك في حال عدم حضور صنف من أصناف الشاشات الكبيرة (col-lg-*). تمّ في الشيفرة السابقة استخدام الأصناف col-md-7 و col-md-17 والّتي تُشير إلى أنّ كتلة <aside> ستستحوذ على عرض عمود ذو قياس 7 في الشاشات المُتوسطة، وستستحوذ الكتلة <section> على عرض عمود ذو قياس 17، وذلك نسبةً إلى الحاوية الأب (parent container)، مع العلم أنّ مجموع سعات الأعمدة في Bootstrap هو 12، ولكن تمّ زيادة العدد (إلى الضعف) وذلك بهدف الحصول على مزيد من المرونة في التوزيع، ولكن بشكل عام استخدام 12 عمود هو مناسب لمعظم التصاميم. سيتمّ في الشيفرة التّالية إضافة بعض الحشوة لمُلائمة التنسيق، وذلك إلى الصنف .wrapper، ورأس الصّفحة: body { ... .wrapper { padding: 0 0 50px 0; } header { padding: 20px 0; } } تمّ في الشيفرة السابقة الاستفادة من المعالج المُسبق (preprocessor) وذلك في صياغة التنسيق، حيثُ يَسمح لنا ذلك بكتابة تنسيقات مُتداخلة (nested) وبدون تكرار، والذي سيتمّ صياغتها بعد الترجمة إلى: body .wrapper {...} body header {...} يَسمح هذا الأسلوب من الإعداد في رؤية بُنيان HTML الصحيح داخل CSS، ويُقدّم نوعًا من الفرز والتنظيم في كتابة شيفرة CSS. الختام تمّ في هذا الجزء التعرّف على Bootstrap، وإعداد بيئة العمل، وكيفية بناء بُنيان ملفّات المشروع، في الجزء الثّاني سيتمّ الدخول في تصميم كل جزء من أجزاء الصّفحة. ترجمة – وبتصرّف – للمقال Page layout with Bootstrap 3.

نظرة عامة أباتشي كوردوفا (Apache Cordova) هي منصّة مفتوحة المصدر لتطوير تطبيقات الموبايل. تمكّنك من استخدام تقنيات الويب المعياريّة مثل HTML5, CSS3, وJavaScript للتطوير متعدد المنصّات “cross-platform development” حيث تنفذ التطبيقات من خلال محزّم مخصص لكل منصّة، ويعتمد على الواجهات البرمجيّة القياسيّة للوصول إلى موارد الأجهزة كالحسّاسات، البيانات، وحالة الشبكة. قم باستخدام Apache Cordova إذا كنت: مطوّر تطبيقات موبايل وتريد أن توسّع قدرة تطبيقك ليعمل على أكثر من منصّة، بدون الحاجة إلى إعادة تنفيذه بلغة ومجموعة الأدوات الخاصّة بكل منصّة. مطوّر تطبيقات ويب، وتريد أن تنشر تطبيق محزّم للتوزيع على متاجر تطبيقات متنوعة. مطوّر تطبيقات موبايل مهتم بدمج مكونات التطبيق الأصليّة بطريقة عرض الويب WebView (نافذة تصفح خاصّة) يمكنها الوصول إلى الواجهات البرمجية للتطبيقات على مستوى الأجهزة (device-level APIs)، أو إذا كنت تودّ تطوير واجهة إضافة (plugin interface) بين المكونات الأصليّة ومكونات الويب. البنية يتواجد العديد من المكونات لتطبيقات Cordova, يبيّن المخطط التالي نظرة عالية المستوى على بنية تطبيق Cordova. عرض الويب WebView WebViewالمدعم بـ Cordova يمكن أن يزود التطبيق بكل واجهات المستخدم الخاصّة به، كما يمكن أن يكون في بعض المنصّات كمكوّن ضمن تطبيق مختلط أكبر يدمج WebView مع مكوّنات التطبيق الأصليّة تطبيق الويب Web App هو الجزء الذي تتوضع فيه شفرة تطبيقك، التطبيق بحد ذاته ينفذ كصفحة ويب، وبشكل افتراضي هو الملف المسمّى index.html والذي يرتبط بـ JavaScript ، CSS، صور، ملفات وسائط متعددة، أو مصادر أخرى ضرورية لتشغيله. ينفذ التطبيق في WEBVIEW ضمن محزّم البرنامج الأصلي, الذي قمت بتوزيعه على متاجر التطبيقات. ويحتوي أيضًا على ملف مهم للغاية وهو config.xml والذي يؤمّن معلومات عن التطبيق ويحدّد البارامترات التي تؤثر على كيفية عمله، كتحديد فيما إذا كان يستجيب لتغيرات الاتجاه. الإضافات Plugins تشكل الإضافات جزء أساسي من النظام الوظيفي لـ Cordova. فهي تؤمن الواجهة لـ Cordova والمكونات الأساسيّة للاتصال فيما بينها، وعملية التغليف إلى واجهات تطبيقات الجهاز القياسيّة APIS ، وهذا يمكنك من استدعاء الشفرة الأصليّة للبرنامج من خلال Javascript. مشروع Apache Cordova يدير مجموعة من الإضافات تسمّى الإضافات الجوهرية Core Plugins. هذه الإضافات تمكّن تطبيقك من الوصول إلى موارد جهازك (كالبطارية، الكاميرا، جهات الاتصال، ..الخ). وبالإضافة إلى المكونات الجوهريّة يوجد العديد من الإضافات التابعة لجهات أخرى third-party plugins والتي تؤمّن تغليفات إضافية لخصائص قد لا تكون متوافرة بالضرورة في جميع الأجهزة. يمكنك البحث عن إضافات Cordova باستخدام (plugin search(npm، كما يمكنك أيضًا تطوير إضافاتك الخاصة. يمكن أن تكون الإضافات ضروريّة . كمثال، من أجل الاتصال بين Cordova والمكونات الاصليّة العاديّة. لا تؤمن Cordova أي أدوات واجهات UI widgets أو بنى تعتمد عرض النماذج MV* frameworks. تؤمن لها فقط زمن التشغيل الذي يمكنها التنفيذ خلاله. إذا كنت تريد استخدام أدوات الواجهات أو بيئة عرض النماذج، يتوجب عليك اختيارهم وتضمينهم في تطبيقك. مسارات التطوير Development Paths تزودك Cordova بمخططي عمل workflow أساسيين من أجل إنشاء تطبيق موبايل، بينما يمكنك غالبًا استخدام أيّ منهما لإنجاز نفس المهمة، فإنّ كل منهم يقدم خصائص إيجابية: مخطط عمل موجه الأوامر متعدد المنصات (Cross-platform (CLI) workflow) استخدم هذا المخطط إذا كنت تودّ أن يعمل تطبيقك على أنظمة تشغيل مختلفة قدر الامكان. مع حاجة قليلة للتطوير المتعلق بالمنصة (platform-specific development) يركّز مخطط العمل هذا على موجه الأوامر في كوردوفا (Cordova CLI)، والذي هو عبارة عن أداة عالية المستوى تمكنك من بناء مشاريع لمنصّات متعددة في نفس الوقت. تستخرج العديد من خصائص سكربتات شيل(الصدفة) الأقل المستوى lower-level shell .scripts يقوم CLI بنسخ مجموعة من تجهيزات الويب الشائعة إلى مجلدات فرعية لكل منصّة موبايل، القيام بتغيير الإعدادات الضرورية لعمل كل منها، وتشغيل سكريبتات البناء لتوليد الملفات التنفيذية للتطبيقات. يؤمن CLI أيضًا واجهة عامة لتنصيب الإضافات على تطبيقك. إذا لم تكن بحاجة إلى مخطط مخصّص لمنصّة محددة يفضل اعتماد المخطط لمنصّات متعددة. مخطط العمل المتعلق بمنصّة Platform-centered workflow قم باستخدام هذا المخطط إذا كنت تودّ إنشاء تطبيق مخصّص لمنصّة واحدة, ولديك حاجة لأن تكون قادرًا على تعديله بالمستويات الأدنى. وكمثال إذا كنت تريد من تطبيقك أن يدمج المكونات الأصلية العادية مع مكونات Cordova المعتمدة على الويب (web-based Cordova components)، كما نوقش في تضمين WebViews. وكقاعدة متعارف عليها، استخدم هذا المخطط إذا كنت تريد تعديل المشروع من خلال حزمة تطوير النظام الخاصّة به SDK. هذا CLI مجموعة على مجموعة من سكريبتات المستوى الأدنى التي تم تعديلها لتلائم كل من المنصّات المدعومة. بالإضافة إلى أداة منفصلة (Plugman) تمكّنك من تنصيب الإضافات. بالرغم من أنّه يمكنك استخدام هذا المخطط لإنشاء تطبيقات لمنصّات متعددة، لكن ذلك يتم عادة بصعوبة أكبر، وذلك بسبب أن نقص أدوات المستوى الأعلى يعني دورات بناء منفصلة وتعديلات على الإضافة لكل منصّة. في بداية العمل، من الأسهل البدء باستخدام مخطط العمل متعدد المنصّات لإنشاء التطبيق، يمكننا بعدها الانتقال إلى مخطط العمل المخصص لمنصّة إذا كنت تريد تحكم أوسع يتم تأمينه من قبل حزمة تطوير النظام الخاصة بالتطبيق SDK. تدير CLI مجموعة شائعة من الشفرات المصدرية متعددة المنصّات، تستخدمها في كل عمليّة بناء للكتابة فوق الشفرة المخصصة لمنصّة واحدة. للحفاظ على أيّة تعديلات قمت بإجرائها على المكونات المخصصة لمنصّة، يتوجب عليك الانتقال إلى استخدام أدوات شيل المخصصة لتلك المنصّة التي تتجاهل الشفرات المصدريّة متعددة المنصّات وتقوم بدلاً عن ذلك بالاعتماد على شفرات مصدريّة مخصصة لمنصّة واحدة. تنصيب Cordova يختلف تنصيب Cordova بحسب مخطط العمل الذي تختاره. مخطط العمل متعدد المنصّات: (سنتعرّف عليه في الدرس القادم) مخطط العمل المخصص لمنصّة. بعد تنصيب Cordova, يفضل الاطلاع على قسم (Develop for Platforms) لمنصّات الموبايل التي تطوّر التطبيق من أجلها. ترجمة -وبتصرّف- للمقال Architectural overview of Cordova platform للمساهمين في كتابة المقال على GitHub هذا المقال منشور تحت الرخصة Apache License, Version 2.0

ريلز أو Ruby on Rails هو أحد أكثر الإطارات المعروفة للمطورين الذين يتطلعون إلى إنشاء مواقع وتطبيقات ويب، التي تجمع بين لغة برمجة روبي مع إطار العمل ريلز framework Rails مما جعل إنشاء التطبيقات الويب أكثر بساطة. لتثبيت ريلز يمكنك استخدام أداة سطر الأوامر rbenv التي ستوفر لك بيئة صلبة لتطوير تطبيقات ريلز تتيح لك التبديل بسهولة بين إصدارات Ruby و إبقاء فريقك بأكمله على نفس الاصدار. توفر لك rbenv دعما لتحديد اصدارات روبي الخاصة بالتطبيق وتغيرها لكل مستخدم، كما تسمح لك باستخدام متغير لإعادة تحديد إصدار روبي. سوف يوضح لك هذا المقال عملية تثبيت ريلز باستخدام rbenv. ## المتطلبات الأساسية من أجل متابعة هذا المقال تحتاج إلى: إعداد خادم اوبنتو 18.04 و تملك مستخدم غير جذري (non-root) يملك صلاحيات sudo و مثبت عليه جدار حماية. يمكنك اعداده بالعودة إلى مقال الإعداد الأولي لخام اوبنتو قم بثبيت Node.js باستخدام official PPA كما هو موضح في كيفية تثبيت Node.js على 18.04 اوبنتو إذ تعتمد بعض ميزات ريلز مثل خط أنابيب الأصول Asset Pipeline ومُشغل جافاسكربت الآني runtime JavaScript على ما يوفره Node.js. الخطوة الأولى: تثبيت rbenv ومتطلباته تعتمد Ruby على عدة حزم يمكنك تثبيتها من خلال apt-get وبمجرد تثبيتها يمكنك تثبيت rbenv واستخدامه لتثبيت روبي. أولاً، قم بتحديث قائمة الحزمة الخاصة بك: $ sudo apt update من قم بتثبيت المتطلبات اللازمة لتشغيل روبي بتنفيذ الأمر التالي . $ sudo apt install autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm5 libgdbm-dev بمجرد الانتهاء من تثبيت المتطلبات يمكنك البدء بتثبيت rbenv من GitHub ووضعه داخل المجلد rbenv ./~: $ git clone https://github.com/rbenv/rbenv.git ~ / .rbenv بعد ذلك لابد من تعريف PATH$ الخاص بك على rbenv لاستخدامها في واجهة سطر الأوامر ويكون ذلك بإضافة الملف rbenv/bin./~ إلى PATH$ الخاص بك داخل الملف bashrc./~ ولكن تذكر من أجل ظهور التغيرات لابد من إنهاء ومن ثم إعادة تشغيل واجهة سطر الأوامر؛ انظر للأمر التالي: $ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc الآن أضف الأمر "(-eval "$(rbenv init إلى الملف bashrc./~ من أجل أن يتم تجميل rbenv تلقائيا: $ echo 'eval "$(rbenv init -)"' >> ~/.bashrc لتطبيق التغييرات التي أجرتها على الملف bashrc./~ على جلسة الصدفة shell الحالية نفذ الأمر التالي: $ source ~/.bashrc للتحقق من إعدادات rbenv أنه تم تثبيتها بشكل صحيح استخدم الأمر type الذي سيعرض المزيد من المعلومات حول rbenv: $ type rbenv سوف يعرض الأمر ما يلي: rbenv is a function rbenv () { local command; command="${1:-}"; if [ "$#" -gt 0 ]; then shift; fi; case "$command" in rehash | shell) eval "$(rbenv "sh-$command" "$@")" ;; *) command rbenv "$command" "$@" ;; esac } بعد ذلك قم بتنزيل ruby-build وهو عبارة عن إضافة plugin، إذ تضيف الأمر rbenv install الذي يسهل عملية تنزيل الإصدارات الجديدة من روبي: $ git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build في هذه المرحلة تم تثبيت كل من rbenv و ruby-build لنبدأ الآن بتثبيت روبي: الخطوة الثانية: تثبيت روبي مع ruby-build بعد تثبيت ruby-build يمكنك الآن تثبيت إصدارات روبي التي تحتاج بأمر بسيط. اولا سنعرض جميع الإصدارت المتاحة من روبي: $ rbenv install -l ستظهر لك قائمة كبيرة من الإصدارات التي يمكن تثبيتها، لنقم بتثبيت الإصدار 2.5.1 المتوفر وقت كتاب هذا المقال: $ rbenv install 2.5.1 من أجل تثبيت إصدار روبي الذي قمنا بتثبيته كإصدار الافتراضي استخدم الرمز global كجزء من الأمر: $ rbenv global 2.5.1 للتحقق من أن التثبيت تم بشكل صحيح تحقق من رقم اصدار روبي: $ ruby -v إذا قمت بتثبيت نفس الاصدار السابق لابد ان تظهر لك المخرجات التالية: ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux] لتثبيت إصدار مختلف من روبي قم تنفيذ الأمر rbenv مع رقم إصدار مختلف مثل: rbenv install 2.3.0 ثم rbenv global 2.3.0. الآن لديك إصدار واحد على الأقل من روبي قم بتثبيته و تعينه باصدار افتراضي لروبي فبعد ذلك سوف نبدأ بإعداد ريلز والجواهر gems الخاصة بها. الخطوة الثالثة: العمل مع الجواهر Gems الجواهر Gems هي الطريقة التي يتم بها توزيع مكتبات روبي، استخدام الأمر gem لإدارة هذه gems كما سوف نستخدم هذا الأمر لتثبيت ريلز. أثناء تثبيت gem تعمل عملية التثبيت بإنشاء وثائق محلية مما يضيف وقت أطول أثناء عملية تثبيت كل gem، لذلك سنوقف هذه العملية عن طريق إنشاء ملف يسمى gemrc./~ الذي يحتوي على الاعدادت اللازمة لإيقاف هذه الميزة: $ echo "gem: --no-document" > ~/.gemrc المُحزِّم Bundler هي عبارة عن أداة يستخدمها gem لإدارة ما يعتمد عليه المشاريع، بالأمر التالي سنثبت Bundler الذي يعتمد عليه ريلز. $ gem install bundler ستظهر المخرجات التالية: Fetching: bundler-1.16.2.gem (100%) Successfully installed bundler-1.16.2 1 gem installed يمكنك استخدام الأمر gem env (كلمة env بالأمر هي اختصار من كلمة environment) لمعرفة المزيد حول من البيئات والإعدادات ب gems، بإمكانك معرفة مكان تثبيت gems باستخدام متغير home انظر للمثال : $ gem env home سوف يعرض لك الناتج التالي: /home/sammy/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0 بمجرد الإنتهاء من إعدادات gems يمكنك تثبيت ريلز بالخطة التالية: الخطوة الرابعة: تثبيت ريلز من أجل تثبيت ريلز استخدم الأمر gem install مع الراية ‎-v لتحديد الإصدار، في هذا المقال التعليمي، سنثبت الإصدار 5.2.0: $ gem install rails -v 5.2.0 يقوم الأمر gem بتثبيت الجواهر المحددة وكذلك كل ما تعتمد عليه. تُعد ريلز لتطوير الويب معقدة إذ تعتمد على العديد التبعيات ، لذلك تستغرق عملية التثبيت بعض الوقت،و لكن بالنهاية سترى رسالة تفيد بأن ريلز مثبت، بالإضافة إلى كل ما تعتمد عليه: Successfully installed rails-5.2.0 38 gems installed ملاحظة: إذا كنت ترغب في تثبيت إصدار مختلف من ريلز، يمكنك عرض الإصدارات الصالحة من ريلز من خلال إجراء عملية بحث، مما يؤدي إلى لإظهار قائمة طويلة من الإصدارات، يمكننا بعد ذلك تثبيت إصدار معين، مثل 4.2.7: $ gem search '^rails$' --all $ gem install rails -v 4.2.7 في حال كنت ترغب في تثبيت أحدث إصدار من ريلز نفذ الأمر دون تحديد رقم الاصدار: $ gem install rails يعمل rbenv عن طريق إنشاء مجلد shims، والذي يشير إلى الملفات المستخدمة بإصدار ريلز المفعل حاليًا،من خلال الأمر الفرعي rehash يقوم rbenv بإصلاح shims في هذا المجد لربط كل أمر في روبي عبر كل إصدار مثبت من روبي على الخادم الخاص بك. كلما تم تثبيت إصدار جديد من روبي أو gem نفذ هذا الامر. $ rbenv rehash تحقق من تثبيت ريلز بشكل صحيح عن طريق طباعة اصداره باستخدام هذا الأمر: $ rails -v إذا تم تثبيته بشكل صحيح ، سترى إصدار ريلز الذي تم تثبيته: Rails 5.2.0 في هذه المرحلة سنقوم بالبدء في اختبار تثبيت ريلز والبدء في تطوير تطبيقات الويب، حافظ على تحديث rbenv باستمرار. الخطوة الخامسة: تحديث rbenv نظرًا لأنك قمت بتثبيت rbenv يدويًا باستخدام Git، يمكنك تحديثه إلى الإصدار الأحدث في أي وقت باستخدام أمر git pull في المجلد rbenv./~: $ cd ~/.rbenv $ git pull هكذا سنضمن أننا نستخدم أحدث إصدار من rbenv المتاحة. الخطوة السادسة: إلغاء تثبيت إصدارات روبي أثناء تنزيل إصدارات إضافية من روبي يمكنك تجميع إصدارات أكثر مما تريد في المجلد rbenv/versions./~ استخدم الأمر uninstall الموجود ب ruby-build لإزالة أي من الإصدارات السابقة على سبيل المثال إزالة الاصدار 2.1.3: $ rbenv uninstall 2.1.3 باستخدام الأمر `rbenv uninstall` يمكنك من إزالة الإصدارات القديمة من روبي بحيث لا يكون لديك تثبيت أكثر مما تستخدمه حاليًا. الخطوة السابعة: إلغاء تثبيت rbenv إذا قررت أنك لم تعد ترغب في استخدام rbenv، فيمكنك إزالته من نظامك ،من أجل القيام بذلك افتح أولاً ملف `bashrc./~` في المحرر الخاص بك: $ nano ~/.bashrc ابحث عن السطرين التاليين من الملف ‎~/.bashrc ثم قم بحذفها: export PATH="$HOME/.rbenv/bin:$PATH" eval "$(rbenv init -)" احفظ الملف واخرج من المحرر،ثم قم بإزالة rbenv وجميع إصدارات روبي المثبتة بهذا الأمر: rm -rf rbenv root سجل الخروج وقم بالعودة لحفظ التغييرات على الصدفة shell الخاص بك. الخلاصة في هذا المقال التعليمي قمت بتثبيت rbenv وريلز ويمكن الآن الانتقال إلى توثيق ريلز على موسوعة حسوب لمزيد من المعلومات. ترجمة -وبتصرف- للمقال How To Install Ruby on Rails with rbenv on Ubuntu 18.04 لصاحبيه Brian Hogan و Lisa Tagliaferri

يعتبر دوكر Docker من أشهر التطبيقات مفتوحة المصدر لإنشاء وإدارة ونشر استنساخ التطبيقات باستخدام الحاويات، فالحاوية هي حزمة تحتوي على متطلبات التطبيق للعمل على مستوى نظام التشغيل أي أن التطبيق المنشور باستخدام Docker يعمل في بيئته الخاصة ويُتعامل مع متطلباته بشكل منفصل. أما Flask فهو إطار ويب مصغّر (micro-framework) مبني باستخدام لغة بايثون، وتعود تسميته بالإطار المصغّر لأنه لا يحتاج إلى أدوات محدّدة أو مكونات إضافيّة لكي يعمل، بالإضافة إلى أنه يتميّز بالخفّة والمرونة وبدرجة عالية من التنظيم مما يجعل المبرمجين يفضلونه على بقية الإطارات. سيسمح لك نشر تطبيق Flask باستخدام Docker باستنساخ التطبيق على مختلف الخوادم بأقل إعدادات ممكنة، لذا سنرى كيفية إنشاء تطبيق Flask و نشره باستخدام Docker بالإضافة إلى كيفية تحديث التطبيق بعد نشره. المتطلبات الأساسية لمتابعة هذا الدرس، ستحتاج إلى ما يلي: مستخدم عادي - ليس جذر - مع صلاحيات sudo معّد باستخدام هذا الدليل خادم أوبنتو 18.04 مع Docker، يمكنك إعداده عن طريق اتباع الخطوات في هذا الدرس أو عن طريق استخدام ميّزة التثبيت الخاصة بـ DigitalOcean في هذا الدرس تثبيت Nginx بإتباع الخطوة الأولى من هذا الدرس الخطوة الأولى - إعداد تطبيق Flask ستحتاج إلى إنشاء هيكل مجلدات تطبيقك، لذلك أنشئ مجلدًا في ‎/var/www وسمّهِ على سبيل المثال TestApp: sudo mkdir /var/www/TestApp ثم انتقل إلى هذا المجلد باستخدام الأمر: cd /var/www/TestApp وبعد ذلك، أنشئ المجلد الرئيسي لتطبيق Flask: sudo mkdir -p app/static app/templates تشير راية ‎-p إلى أن mkdir سينشئ المجلد مع جميع المجلدات الرئيسية غير الموجودة، وفي هذه الحالة، سينشئ mkdir مجلد الأب app حتى يتمكن من إنشاء مجلدات static و templates داخله. سيحتوي المجلد app على جميع الملفات المتعلّقة بتطبيق Flask مثل الواجهات (views) والمخططات الأوليّة (blueprints). فالواجهة هي الشيفرة البرمجيّة التي تكتبها للاستجابة إلى طلبات تطبيقك، أما المخططات الأوليّة فتنشئ مكونات التطبيق وتدعم الأنماط الشائعة داخل التطبيق أو عبر تطبيقات مختلفة. ستضع جميع الأصول مثل الصور وملفات CSS وملفات جافاسكربت في مجلد static ، وأما بالنسبة لقوالب HTML فستضعهم في مجلد templates. والآن، بعد أن أنشأنا هيكل المجلدات الأساسية، فسننشئ الملفات التي نحتاجها لتشغيل تطبيق Flask. أنشئ أولًا ملف ‎__init__.py داخل مجلد app، سيجعل هذا الملف مفسر بايثون يتعامل مع مجلد app كحزمة. أنشئ ملف ‎__init__.py باستخدام الأمر التالي: sudo nano app/__init__.py تسمح لك الحزم في بايثون بجمع الوحدات إلى مساحات أسماء منطقيّة أو تسلّسلات هرميّة لكي تتمكن من تقسيم الشيفرة البرمجيّة إلى كتل منفصلة قابلة للإدارة ذات وظائف معيّنة. بعد ذلك، ستضيف شيفرة برمجيّة إلى ‎__init__.py لإنشاء نسخة من Flask واستدعاء المنطق الموجود في ملف views.py، والذي ستنشئه بعد إنهائك لهذا الملف. أضف الشيفرة البرمجيّة التاليّة إلى الملف الجديد: from flask import Flask app = Flask(__name__) from app import views ستنشئ الآن ملف views.py في مجلد app، سيحتوي هذا الملف على أغلب منطق التطبيق. sudo nano app/views.py بعد ذلك أضف هذه الشيفرة البرمجيّة إلى ملف views.py، ستُعيد هذه الشيفرة البرمجيّة السلسلة النصيّة ‎hello world!‎ إلى زوار صفحة الويب. from app import app @app.route('/') def home(): return "hello world!" يسمى السطر ‎@app.route‎‏ فوق الدالة بالمزخرِف ويعمل على تعديل الدالة التي بعده، وفي هذه الحالة، سيخبر المزخرِف Flask أي رابط URL ستنفّذ دالة home‎‎()‎، وأما بالنسبة إلى النص hello world المُعاد من الدالة home فسيظهر للمستخدم في المتصفّح. الآن، بعد الانتهاء من ملف views.py، فنحن مستعدين لإنشاء ملف uwsgi.ini الذي سيحتوي على إعدادات uWSGI لتطبيقنا وهذا الأخير عبارة عن خيار نشر لـ Nginx والذي هو خادم لكل من البروتوكول والتطبيق، أي يخدم بروتوكولات uWSGI و FastCGI و HTTP. استخدم الأمر التالي لإنشاء هذا الملف: sudo nano uwsgi.ini بعد ذلك، أضف هذه الإعدادات إلى الملف لإعداد خادم uWSGI: [uwsgi] module = main callable = app master = true تعرّف هذه الشيفرة البرمجية الوحدة التي سيعمل منها تطبيق Flask، والتي هي في هذه الحالة ملف main.py، ولقد أشرنا إليه بـ main. وبالنسبة إلى خيار callable فهو يخبر uWSGI باستخدام نسخة من app المصدّر من التطبيق الرئيسي. ويسمح الخيار master للتطبيق أن يعمل دائمًا ولن يتوقف إلا لبعض الوقت عند إعادة تحميل التطبيق كاملًا. بعد ذلك، أنشئ ملف main.py ليكون مدخل تطبيقك، فالمدّخل يخبر uWSGI عن كيفية التعامل مع تطبيقك. sudo nano main.py والآن، أضف السطر التالي إلى الملف حيث أن هذا الأخير سيستدعي نسخة من Flask يسمى app من حزمة التطبيق التي أنشأناها سابقًا. from app import app وفي النهاية، أنشئ الملف requirements.txt لتحديد الاعتماديات التي سيثبتها مدير الحزم pip إلى نشر Docker الخاص بك: sudo nano requirements.txt أضف السطر التالي في الملف ‎/var/www/TestApp/app/requirements.txt لإضافة Flask كتبعيّة: Flask==1.0.2 يحدد هذا السطر نسخة Flask التي يجب تثبيتها، والتي هي في وقت كتابة هذا المقال، النسخة 1.0.2، ويمكنك التأكد من التحديثات على الموقع الرسمي لـ Flask. والآن لقد أنتهيت من إعداد تطبيق Flask ومستعد لإعداد Docker. الخطوة الثانية - إعداد Docker سننشئ في هذه الخطوة ملفين، Dockerfile و start.sh لإنشاء نشر Docker الخاص بك، فملف Dockerfile هو مستند نصي يحتوي على الأوامر التي تُستخدم لتجميع الصورة (image) وأما بالنسبة لملف start.sh فهو سكربت shell الذي سيبني الصورة وسينشئ الحاوية من ملف Dockerfile. أنشئ أولًا ملف Dockerfile: sudo nano Dockerfile بعد ذلك، أضف إعداداتك التي ترغب بها إلى Dockerfile، ستحدّد هذه الأوامر كيف ترغب ببناء الصورة وكيف ستضاف المتطلبات الإضافيّة. الملف ‎/var/www/TestApp/Dockerfile: FROM tiangolo/uwsgi-nginx-flask:python3.6-alpine3.7 RUN apk --update add bash nano ENV STATIC_URL /static ENV STATIC_PATH /var/www/app/static COPY ./requirements.txt /var/www/requirements.txt RUN pip install -r /var/www/requirements.txt في هذا المثال، سنبني صورة Docker (أي image) من صورة موجودة بالفعل وهي tiangolo/uwsgi-nginx-flask ويمكنك إيجادها على DockerHub وتعتبر هذه الصورة من أفضل الصور الموجودة لأنها تدعم العديد من نسخ بايثون بالإضافة إلى أنظمة التشغيل المختلفة. أول سطرين سيحددان الصورة الرئيسيّة التي ستستخدمها لتشغيل التطبيق وتثبيت معالج أوامر Bash والمحرّر النصي nano، وستثبت أيضًا عميل git للسحب والدفع إلى خدمات استضافة التحكّم بالإصدارات مثل GitHub و GitLab و Bitbucket. أما بالنسبة إلى ENV STATIC_URL /static فهو متغيّر البيئة الخاص بصورة Docker الحالية ويحدد الملف الثابت (static) الذي سيحتوي على جميع الأصول مثل الصور وملفات CSS و ملفات جافا سكربت. بالنسبة لآخر سطرين فستنسخ الملف requirements.txt إلى الحاوية ومن ثم ستثبّت التبعيات. والآن، بعد أن أنهينا ملف Dockerfile، أصبحنا مستعدين لإنشاء ملف start.sh الذي سيبني حاوية Docker، وقبل كتابة سكربت start.sh، تأكد من وجود منفذ (port) مفتوح لاستخدامه في الإعدادات، ويمكنك التأكد من ذلك عن طريق تشغيل الأمر التالي: sudo nc localhost 56733 < /dev/null; echo $? إذا كانت مخرجات الأمر السابق هي 1 فهذا المنفذ مفتوح ويمكن استخدامه، وخلافا ذلك، ستحتاج إلى اختيار منفذ آخر لاستخدامه في ملف إعدادات start.sh. بمجرّد أن تجد منفذ مفتوح للاستخدام، أنشئ سكربت start.sh: sudo nano start.sh سيبني سكربت start.sh ملف Dockerfile وينشئ الحاوية من صورة Docker، ولهذا سنضيف إلى الملف ‎‎/var/www/TestApp/start.sh‎ الإعدادات التالية: #!/bin/bash app="docker.test" docker build -t ${app} . docker run -d -p 56733:80 \ --name=${app} \ -v $PWD:/app ${app} يسمى السطر الأول بـ shebang، وهو يحدد أن هذا الملف هو ملف bash وستُنفّذ أوامره، وأما السطر الثاني فيحدّد اسم الصورة والحاوية وستُحفظ على شكل متغيّر يسمى app. أما السطر التالي فيخبر Docker ببناء الصور من ملف Dockerfile الموجود في المجلّد الحالي، وفي هذا المثال، سينشئ صورة تسمى docker.test. الأسطر الثلاثة الأخيرة تنشئ حاوية تسمى docker.test والتي تعمل على المنفذ 56733، وفي النهاية، تربط المجلد الحالي بمجلد ‎‎‎/var/www في الحاوية. يمكنك استخدام الراية ‎-d لتشغيل الحاوية في وضع العفريت (daemon mode) أو كعملية خلفيّة (background process)، ويمكنك تضمين الراية ‎-p لربط منفذ الخادم إلى منفذ معيّن في حاوية Docker، وفي هذه الحالة ستربط منفذ 59733 بمنّفذ 80 في حاوية Docker. بالنسبة إلى الراية ‎-v ‏(volume) ‏فيحدد مكان Docker لوصله في الحاوية. شغّل سكربت start.sh لإنشاء صورة Docker وبناء حاوية من الصورة: sudo bash start.sh بمجرّد الانتهاء من الأمر السابق، استخدم الأمر التالي لعرض جميع الحاويات التي تعمل: sudo docker ps سيظهر لك شيء مشابه لهذا: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 58b05508f4dd docker.test "/entrypoint.sh /sta…" 12 seconds ago Up 3 seconds 443/tcp, 0.0.0.0:56733->80/tcp docker.test سترى أن حاوية docker.test تعمل، والآن لنزور عنوان IP في المنفذ الذي اخترناه في متصفحك: http://ip-address:56733 ستشاهد صفحة مشابهة لهذه الصفحة: في هذه الخطوة نجحنا في نشر تطبيق Flask على Docker، سنستخدم في الخطوة التالية القوالب لعرض المحتوى إلى المستخدمين. الخطوة الثالثة - خدمة ملفات القوالب القوالب هي ملفات لعرض محتوى ثابت وحيوي لزوار تطبيقك، في هذه الخطوة، سننشئ قالب HTML لإنشاء الصفحة الرئيسية لتطبيقك. إبدأ بإنشاء ملف home.html في مجلد app/templates: sudo nano app/templates/home.html أضف الشيفرة البرمجية إلى قالبك لإنشاء صفحة HTML5 تحتوي على عنوان وبعض النصوص. الملف ‎/var/www/TestApp/app/templates/home.html: <!doctype html> <html lang="en-us"> <head> <meta charset="utf-8"> <meta http-equiv="x-ua-compatible" content="ie=edge"> <title>Welcome home</title> </head> <body> <h1>Home Page</h1> <p>This is the home page of our application.</p> </body> </html> بعد ذلك، عدّل على ملف app/views.py لخدمة الملف المنشئ حديثًا: sudo nano app/views.py أضف أولا السطر التالي إلى بداية ملفك لإستدعاء أسلوب render_template من Flask والذي يرمّز صفحة HTML لتصيير (render) صفحة ويب للمستخدم. from flask import render_template ... أضف مسار (route) آخر في نهاية الملف لتصيير ملف القالب حيث ستحدّد هذه الشيفرة البرمجية أن المستخدمين سيخدمون بمحتوى ملف home.html عند زيارة مسار ‎/template في تطبيقك. ... @app.route('/template') def template(): return render_template('home.html') سيبدو ملف app/views.py بعد تحديثه كالتالي: from flask import render_template from app import app @app.route('/') def home(): return "Hello world!" @app.route('/template') def template(): return render_template('home.html') من أجل تفعيل هذه التغييرات، ستحتاج إلى إيقاف وإعادة تشغيل حاويات Docker. شغّل الأمر التالي لإعادة بناء الحاوية: sudo docker stop docker.test && sudo docker start docker.test زر تطبيقك الآن على http://your-ip-address:56733/template لمشاهدة خدمة القالب الجديد. في هذه الخطوة أنشأت ملف قالب Docker لخدمة زوار تطبيقك وفي الخطوة القادمة سنرى كيف يمكنك تفعيل التغييرات دون الحاجة إلى إعادة تشغيل حاوية Docker. الخطوة الرابعة - تحديث التطبيق ستحتاج في بعض الأحيان إلى القيام ببعض التغييرات في تطبيقك مثل تثبيت متطلبات جديدة، تحديث حاوية Docker أو تغيير شيفرة HTML أو المنطق، لذلك، سنتحدّث الآن عن إعداد touch-reload للقيام بهذه التغييرات دون الحاجة إلى إعادة تشغيل حاوية Docker. يراقب بايثون autoreloading نظام الملفات للتغييرات وتحديث التطبيق عند إيجاد تغيير، وهذه العملية غير منصوح بها عند مرحلة الإنتاج (production) لأنها ستستهلك الكثير من الموارد. سنستخدم touch-reload لمراقبة التغييرات لملف معيّن وإعادة التحميل عند تحديث أو استبدال هذا الملف. لفعل ذلك، نبدأ بفتح ملف uwsgi.ini: sudo nano uwsgi.ini ونضيف هذا السطر الأخير إلى نهاية ملف uwsgi.ini كما هو موضح في الشيفرة التالية: module = main callable = app master = true touch-reload = /app/uwsgi.ini يحدد هذا السطر الملف الذي يجب التعديل عليه لإعادة تحميل كامل التطبيق. لمشاهدة هذا، غيّر قليلا في تطبيقك، فعلى سبيل المثال، افتح ملف app/views.py: sudo nano app/views.py استبدل السلسلة النصيّة التي تعود من الدالة home: from flask import render_template from app import app @app.route('/') def home(): return "<b>There has been a change</b>" @app.route('/template') def template(): return render_template('home.html') والآن، إذا فتحت الصفحة الرئيسية لتطبيقك على http://ip-address:56733 ستلاحظة عدم ظهور التغييرات، وهذا بسبب أن شرط إعادة التحميل هو تغيير ملف uwsgi.ini، لذا استخدم touch لتفعيل هذا الشرط: sudo touch uwsgi.ini أعد تحميل صفحة الرئيسية في تطبيقك على متصفحك مرّة أخرى، ستظهر لك التغييرات: في هذه الخطوة، أعددت شرط touch-reload لتحديث تطبيقك بعد القيام بتغييرات. الخلاصة في هذا الدرس، أنشأت ونشرت تطبيق Flask على حاوية Docker، ولقد أعددّت touch-reload لإعادة تحميل التطبيق دون الحاجة إلى إعادة تشغيل الحاوية. يمكنك الآن التوسع أكثر واكتشاف Docker بطريقة معمّقة، ويمكنك البدء بالتوثيق الرسمي ترجمة -وبتصرف- للمقال How To Build and Deploy a Flask Application Using Docker on Ubuntu 18.04 لصاحبه Michael Okoh

وصلنا إلى ختام هذه السلسلة وفي الدرس الأخير منها سنتحدث عن لوحة التحكم التي يقدّمها إطار العمل Django بشكل جاهز مع كل مشروع تقوم بإنشائه، ويمكن الاستفادة من لوحة التحكم هذه في إدارة النماذج Models المستخدمة في المشروع إضافة إلى إدارة مجموعات المستخدمين وصلاحياتهم في إجراء التعديلات على الموقع اﻹلكتروني. الولوج إلى لوحة التحكم لنستعرض المسارات الموجودة في ملف mysite/urls.py: urlpatterns = [ url(r'^admin/', admin.site.urls), url(r'^polls/', include(polls_urls)), ] نلاحظ هنا وجود مسارين رئيسيين في مشروعنا هذا، وكما هو واضح فإنّ الولوج إلى لوحة التحكم يتطلب استخدام مسار يتضمن الكلمة admin/، وللتأكد من ذلك ابدأ بتشغيل الخادوم الخاص بـ Django ثم توجّه في المتصفّح إلى العنوان التالي: http://127.0.0.1:8000/admin ستظهر الشاشة التالية: ما تراه على متصفحك هو صفحة الولوج log-in إلى لوحة التحكم الخاصة بالمشروع، ومن الواضح أننا نحتاج إلى اسم مستخدم وكلمة مرور لنتمكن من الدخول إلى لوحة التحكم. لإنشاء حساب مستخدم يمكنه الولوج إلى لوحة التحكم توجّه إلى سطر اﻷوامر ونفذ الأمر التالي: python manage.py createsuperuser سيُطلب منك إدخال اسم المستخدم، ويمكنك استخدام الاسم الذي ترغب به: Username: admin ثم سيُطلب منك إدخال عنوان بريدك اﻹلكتروني: Email address: admin@example.com والخطوة اﻷخيرة هي إدخال كلمة المرور مرتين: Password: ********** Password (again): ********** Superuser created successfully. واﻵن توجه إلى نفس العنوان السابق في المتصفّح، ثم أدخل الاسم وكلمة المرور التي قمت بإدخالها قبل قليل، وستكون قادرًا اﻵن على الولوج إلى لوحة التحكم والتي ستظهر بالشكل التالي: نلاحظ في هذه الصفحة إمكانية تعديل بعض اﻷمور الخاصة بالمستخدمين ومجموعات المستخدمين، ولكن لا نرى ذكرًا لتطبيقنا على اﻹطلاق. سنحتاج في الواقع إلى القيام بخطوة إضافية، وهي إخبار لوحة التحكم بأنّ عناصر الصنف Question في ملف النماذج models.py تمتلك واجهة لوحة تحكم، وللقيام بذلك توجّه إلى ملف polls/admin.py وأضف إليه اﻷسطر التالية: from .models import Question admin.site.register(Question) والآن قم بإعادة تحميل الصفحة الرئيسية للوحة التحكم، وسترى ظهور التطبيق ضمن عناصر الواجهة: ﻻحظ أن Django قادر على تمييز أسماء النماذج واستخلاص أسماء ذات مدلولات أوضح بالنسبة للمستخدم، فقد تعرّف Django في مثالنا هذا على النموذج Question باعتباره نموذجًا يحتوي على عدد من العناصر المتمثلة باﻷسئلة، لذا أضاف (s) الجمع إلى الاسم المعروض في لوحة التحكم. واﻵن انقر على Questions وسترى قائمة باﻷسئلة التي أضفناها برمجيًا إلى النموذج Question في الدروس السابقة. يمكنك كذلك النقر على نص السؤال لتتمكن من تعديله أو حذفه: ﻻحظ كيف أن Django قد قام بإنشاء استمارة Form خاصة بالسؤال تتضمن جميع الحقول التي أضفناها في الصنف Question في الملف polls/models.py، إضافة إلى ذلك، يستخدم Django عناصر HTML المناسبة لكل نوع من أنواع الحقول. كذلك يضيف Django بعض شيفرات Javascript مع كل حقل من نوع DateTimeField لاختيار الوقت والتاريخ حسب الحاجة. تخصيص لوحة التحكم رأينا كيف قام Django ببناء لوحة التحكم والاستمارات الخاصة بالنموذج Question بشكل آلي، ولكن سنحتاج غالبًا إلى تخصيص مظهر لوحة التحكم وآلية عملها، ويمكننا القيام بذلك عند تسجيل النموذج في ملف polls/admin.py؛ لذا توجّه إلى هذا الملف وعدّله بالشكل اﻵتي: from django.contrib import admin from .models import Question class QuestionAdmin(admin.ModelAdmin): fields = ['pub_date', 'question_text'] admin.site.register(Question, QuestionAdmin) عرفنا في الشيفرة السابقة صنف model admin وقمنا بتمريره كمعامل ثانٍ للدالة register(). ستعمل هذه الشيفرة على تبديل مواقع حقلي تاريخ نشر السؤال ونص السؤال، ليحل أحدهما محل اﻵخر: يمكن كذلك تقسيم الحقول إلى مجموعات fieldsets وذلك بالشكل التالي: from django.contrib import admin from .models import Question class QuestionAdmin(admin.ModelAdmin): fieldsets = [ (None, {'fields': ['question_text']}), ('Date information', {'fields': ['pub_date']}), ] admin.site.register(Question, QuestionAdmin) التعامل مع الاختيارات المرتبطة بالسؤال؟ لم نتعامل لحدّ اﻵن مع الاختيارات المرتبطة باﻷسئلة في تطبيق الاقتراعات، وفي الواقع هنا طريقتان للقيام بذلك: الطريقة اﻷولى هي اتباع نفس الخطوات التي قمنا باتباعها في تسجيل الصنف Question وذلك بتعديل ملف polls/admin.py ليصبح بالشكل التالي: from .models import Choice, Question # ... admin.site.register(Choice) قمنا في هذا الشيفرة باستيراد الصنف Choice إضافة إلى الصنف Question، بعد ذلك سجّلنا الصنف Choice باستخدام الدالة register(). واﻵن ستظهر الصفحة الرئيسية للوحة التحكم بالشكل التالي: ويمكن إضافة اختيارات جديدة بالضغط على أيقونة Add Choice أو Add وستظهر صفحة إضافة الاختيار بالشكل التالي: ﻻحظ أنّه يمكنك اختيار السؤال الذي تودّ ربط الاختيار به وذلك من القائمة المنسدلة المعنونة بـ Question، كما يمكنك إضافة سؤال جديد من هذه الصفحة وذلك بالضغط على علامة (+) الخضراء إلى جانب القائمة المنسدلة، أو تحرير السؤال الذي اخترته بالضغط على أيقونة القلم اﻷصفر. لا تبدو هذه الطريقة مفيدة من الناحية العملية، إذ يجب إضافة السؤال الجديد، ثم إضافة الاختيارات وربطها واحدًا تلو اﻵخر بالسؤال. إذًا، أليس من اﻷفضل أن نقوم بإضافة الاختيارات مباشرة عند إضافة السؤال؟ هذه هي الطريقة الثانية. للقيام بذلك توجّه إلى ملف polls/admin.py ثم عدّله ليصبح بالشكل التالي: from django.contrib import admin from .models import Choice, Question class ChoiceInline(admin.StackedInline): model = Choice extra = 3 class QuestionAdmin(admin.ModelAdmin): fieldsets = [ (None, {'fields': ['question_text']}), ('Date information', {'fields': ['pub_date'], 'classes': ['collapse']}), ] inlines = [ChoiceInline] admin.site.register(Question, QuestionAdmin) تخبر الشيفرة السابقة Django بأن الاختيارات يتم تحريرها في صفحة التحكم بالسؤال، إضافة إلى تقديم الحقول اللازمة ﻹضافة 3 اختيارات مع كل سؤال. بناء على ذلك ستظهر صفحة إضافة سؤال جديد بالشكل التالي: ستبرز هنا مشكلة صغيرة وهي أنّه في حال وجود عدد كبير من الاختيارات، فإن المساحة التي ستشغلها هذه الاختيارات ستكون كبيرة جدًّا. يقدّم Django طريقة أخرى لعرض الاختيارات وهي على شكل جدول، ويمكن الوصول إليها بتعديل المعامل في الصنف ChoiceInline ليصبح بالشكل التالي: class ChoiceInline(admin.TabularInline): ستظهر صفحة إضافة سؤال جديد بالشكل التالي: واﻵن بعد أن أجرينا التعديلات اللازمة على صفحة إضافة اﻷسئلة، لنجر بعض التعديلات كذلك على الصفحة الرئيسية التي يتم من خلالها عرض جميع اﻷسئلة المتوفرة في التطبيق. في البداية تظهر هذه الصفحة بالشكل التالي: يستخدم Django بصورة افتراضية مخرجات دالة str() لكل حقل من حقول قاعدة البيانات التي يتم عرضها في الصفحة الرئيسية، ولكننا بحاجة هنا إلى عرض جميع الحقول وليس حقل نصّ السؤال فقط. وللقيام بذلك نستخدم الصف list_display والذي سنضمنه أسماء الحقول التي نرغب في عرضها على شكل أعمدة في الصفحة الرئيسية. توجّه إلى ملف polls/admin.py وعدّل الصنف QuestionAdmin لصبح بالشكل التالي: class QuestionAdmin(admin.ModelAdmin): fieldsets =[ (None, {'fields': ['question_text']}), ('Date information', {'fields': ['pub_date'], 'classes': ['collapse']}), ] inlines = [ChoiceInline] list_display = ('question_text', 'pub_date', 'was_published_recently') واﻵن يفترض أن تظهر الصفحة الرئيسية بالشكل التالي: ﻻحظ أن Django قام بتسمية العمود اﻷخير بنفس اسم التابع المستخدم في النموذج Question مع استبدال الشرطات السفلية بفواصل، ويمكننا تغيير هذا الاسم وتحسين طريقة عرض المخرجات في هذا العمود بالتوجه إلى ملف polls/models.py وتعديل الصنف Question ليصبح بالشكل التالي: class Question(models.Model): question_text = models.CharField(max_length=200) pub_date = models.DateTimeField('date published') def __str__(self): return self.question_text def was_published_recently(self): now = timezone.now() return now - datetime.timedelta(days=1) <= self.pub_date <= now was_published_recently.admin_order_field = 'pub_date' was_published_recently.boolean = True was_published_recently.short_description = 'Published recently?' أعد تحميل الصفحة الرئيسية ولاحظ الفرق: يمكننا إضافة المزيد من التحسينات إلى هذه الصفحة، فمثلًا يمكننا إضافة عمود جانبي يعمل على تصفية اﻷسئلة حسب تاريخ نشرها، وللقيام بذلك أضف السطر التالي إلى الصنف QuestionAdmin: list_filter = ['pub_date'] سيضيف هذا السطر عمودًا جانبيًا إلى الصفحة الرئيسية يتيح لمدير الصفحة تصفية اﻷسئلة حسب تاريخ النشر. ولكن ماذا لو أردنا البحث عن نص سؤال معين بدلًا من البحث بحسب تاريخ النشر؟ يمكن القيام بذلك بإضافة السطر التالي إلى الصنف QuestionAdmin والذي سيعمل على إظهار صندوق للبحث في الصفحة الرئيسية: search_fields = ['question_text'] بعد إجراء التعديلات السابقة ستظهر الصفحة الرئيسية بالشكل التالي: تعديل مظهر لوحة التحكم الخاصّة بالتطبيق من المؤكّد أننا لا نرغب في ظهور عبارة Django administration في رأس كل صفحة من صفحات لوحة التحكم، ويمكن تغيير هذه العبارة باستخدام نظام قوالب Django، فلوحة التحكم هذه تدار بواسطة Django، وتستخدم الواجهة نظام قوالب Django كذلك. أنشئ مجلّدًا باسم templates في مجلّد المشروع (المجلد الذي يحتوي على الملف manage.py)، ثم توجّه إلى ملف اﻹعدادات الخاص بالمشروع mysite/settings.py ثم أضف الخيار DIRS إلى إعدادات القالب بالشكل التالي: TEMPLATES = [ { 'BACKEND': 'django.template.backends.django.DjangoTemplates', 'DIRS': [os.path.join(BASE_DIR, 'templates')], 'APP_DIRS': True, 'OPTIONS': { 'context_processors': [ 'django.template.context_processors.debug', 'django.template.context_processors.request', 'django.contrib.auth.context_processors.auth', 'django.contrib.messages.context_processors.messages', ], }, }, ] يحدّد السطر الذي أضفناه إلى إعدادات قوالب المسارات التي يجب على Django البحث فيها عن القوالب، وهنا أخبرنا Django بأن عليه البحث عن المجلد templates ضمن المجلد الرئيسي للمشروع BASE_DIR. تعمل الدالة os.path.join على ربط القيمة التي يتم الحصول عليها من BASE_DIR مع اسم المجلد المطلوب وهو templates. واﻵن أنشئ مجلّدًا جديدًا باسم admin داخل مجلد templates الذي أنشأناه قبل قليل، ثم انسخ إليه القالب base_site.html من مجلد admin الموجود ضمن الملفات المصدرية لـ Django في المسار django/contrib/admin/templates. إن واجهت صعوبة في العثور على الشيفرة المصدرية الخاصة بـ Django توجّه إلى سطر اﻷوامر ونفّذ اﻷمر التالي: python -c "import django; print(django.__path__)" واﻵن قم بتحرير ملف base_site.html واستبدل الشيفرة {{ site_header|default:_('Django administration') }} بالعبارة التي ترغب في ظهورها في رأس كل صفحة من صفحات لوحة التحكم، يجب أن تكون الشيفرة مقاربة لما يلي: {% block branding %} <h1 id="site-name"><a href="{% url 'admin:index' %}">Polls Administration</a></h1> {% endblock %} من هنا نلاحظ إمكانية إجراء أي تعديل نرغب به على أي قالب من القوالب الخاصة بلوحة التحكم بنفس الطريقة السابقة، فكل ما علينا فعله هو نسخ القالب المطلوب من الملفات المصدرية لـ Django ولصقه في المجلد المخصّص له، ثم إجراء التعديلات المطلوبة. فعلى سبيل المثال، يمكن تخصيص مظهر الصفحة الرئيسية للوحة التحكم وذلك من خلال نسخ الملف template/index.html من الملفات المصدرية لـ Django بنفس الطريقة السابقة، ثم قم بتحرير الملف، وستجد أنّه يستخدم متغيرًا يحمل الاسم app_list. يتضمن هذا المتغير جميع التطبيقات المثبتة في المشروع الذي تعمل عليه. يمكنك اﻵن استبدال هذا المتغير بروابط تأخذ المستخدم إلى مواضع مختلفة من لوحة التحكم، بدلًا من عرض جميع التطبيقات. تغيير لغة العرض في لوحة التحكم من الخصائص التي يتميّز بها إطار العمل Django دعمه للكثير من اللغات، ومن ضمنها اللغة العربية، ويمكن تغيير لغة واجهة لوحة التحكم إلى اللغة التي نرغب بها من خلال التوجّه إلى ملف اﻹعدادات الخاصّ بالمشروع setteings.py ثم تعديل قيمة المتغير LANGUAGE_CODE الافتراضية 'en' إلى رمز اللغة المطلوبة. فمثلًا لتغيير لغة الواجهة إلى العربية: LANGUAGE_CODE = 'ar' وللغة الفرنسية: LANGUAGE_CODE = 'fr' المصدر: توثيقات Django

بعد أن تعرّفنا على أساسيات لغة بايثون حان الوقت للانتقال إلى مرحلة جديدة. في هذه السّلسلة من الدّروس سنتعرّف على أساسيات تطوير تطبيقات الويب بلغة بايثون، وذلك بالاستعانة بإطار العمل Flask، يعتبر Flask إطارا مُصغّرا Micro-Framework أي أنّه يُقدّم للمُبرمج أدوات مُساعدة بسيطة، وبعكس إطار Django فهو مُناسب للمُبتدئين الذين تعرّفوا على لغة بايثون حديثا. متطلبات هذه السلسلة لمتابعة هذه الدّروس وفهمها، ستحتاج إلى معرفة بسيطة بلغة بايثون. ستحتاج كذلك إلى معرفة بسيطة بلغة HTML الهيكلية، وكذلك القليل من لغة CSS لتنسيق الصّفحات إذ لن أشرح ما يتعلق بلغة HTML وCSS لأنّ ذلك ليس من اختصاص السّلسلة. يمكنك مراجعة الدروس التالية على أكاديمية حسوب لتعلم أساسيات هذه اللغات: سلسلة دروس تعلم لغة بايثون تعلّم لغة HTML ولغة CSS ما هو تطبيق الويب؟ تطبيق الويب، هو كل تطبيق يُمكن الوصول إليه عن طريق مُتصفّح للويب (Firefox ،Chrome ،Safari) ويقوم بتقديم صفحات مرئية حسب طلب الزّائر. يُمكن اعتبار موقع الأكاديمية هذا تطبيق ويب، إذ يتفاعل مع الزائر بتقديم المقالات بشكل متناسق، ويوفّر إمكانية المُشاركة للمُستخدمين عبر صندوق التّعليقات وغير ذلك من الخصائص. الصفحة التي تقرأ منها هذا المقال حاليا أصلها شيفرات لغة HTML وهي لغة أساسية في الويب. وتُستعمل لغات البرمجة مثل لغة Python لتقديم شيفرة HTML من الخادوم إلى المُتصفّح الذي يعرضها بدوره للمُستخدم. ما يعني أنّ الهدف النهائي من برمجة التّطبيق هو تقديم ملفات HTML من الخادوم إلى العميل (المُستخدم). خلاصة القول أنّك عندما تدخل إلى موقع الأكاديمية عن طريق رابط academy.hsoub.com، يرسل المُتصفّح طلبا للخادوم الخاص بالأكاديمية، عندما يستقبل الخادوم الطلب يقوم مُباشرة بتنفيذ الشيفرة المكتوبة بلغة برمجية، الشيفرة البرمجيّة تُجيب بملفات HTML ويعرضها لك المُتصفّح فور استقبالها. ما سنتعلّمه في هذه السّلسلة هو كيفيّة التعامل مع طلبات المُستخدم وكيفيّة تقديم ملفات HTML للمُتصفّح باستخدام لغة بايثون. ما هو إطار العمل؟ إطار العمل هو مجموعة من المكتبات والوحدات التي تحتوي على دوال مُساعدة تُمكّن المُبرمج من كتابة تطبيقات دون الاضطرار إلى التعامل مع التفاصيل الدقيقة التي تتطلب وقتا وجهدا كبيرين. يُمكن أن يكون إطار العمل خاصا بتطوير تطبيقات الويب مثل Flask أو Django، ويُمكن كذلك أن يكون مُخصّصا لمجالات أخرى كبناء تطبيقات سطح المكتب مثلا. تتوفّر لغة بايثون على العديد من أطر العمل الخاصّة بتطوير الويب، والتالي قائمة ببعض الأطر مع وصف مختصر لكلّ إطار. Django: إطار عمل ضخم، يتوفّر على عدد هائل من الدوال المُساعدة، كما يعتبر أنسب خيار لمن يرغب بتطوير تطبيقات كبيرة ومُعقّدة متعدّدة الوظائف، يتميّز بشهرته الواسعة وهو سهل التّعلم، يعتبر مناسبا كذلك لمن يرغب بإنشاء تطبيق بسرعة وهو شائع بين الشّركات النّاشئة. Flask: إطار عمل مُصغّر/صغير، يتوفّر على عدد لا بأس به من الدوال المُساعدة، شهرته تقريبا بنفس شهرة Django، مُناسب لتطوير تطبيقات صغيرة ومُتوسّطة (مُدونة، منتدى، موقع شخصي… ). Tornado: إطار عمل مُخصّص للتطبيقات التي تتطلب سرعة في مُعالجة الطّلبات وسرعة في التجاوب كتطبيقات الدّردشة مثلا. Bottle: إطار عمل صغير جدا، يوفّر أدنى المُتطلبات لتطوير تطبيق بسرعة، ويعتبر أصغر من إطار Flask. سبق وأن نشرنا درسا عنه. TurboGears: خصائصه تقترب من خصائص إطار Django، الاختلاف الرئيسي يكمن في الأدوات والمكتبات التي يعتمد عليها كالاتصال بقواعد البيانات وما إلى ذلك ويُعتبر خيارا آخر لمن يرغب بتطوير تطبيقات كبيرة. صحيح أن هناك أطر عمل أخرى لكنّ ما تقدّم ذكره يعتبر أبرزها. لماذا Flask؟ وقع الاختيار على إطار العمل Flask لسهولة تعلّمه بالنّسبة للمبتدئ، إذ سيبدو مألوفا لمن تعرّف حديثا على لغة بايثون، وبما أنّه إطار عمل مُصغّر فسيسهل عليك فهم خطوات إنشاء تطبيق كامل، خاصّة أنّك تستطيع أن تبني تطبيقا في ملفّ بايثون واحد. يتميّز إطار Flask كذلك بإتاحة إمكانيّة ربط تطبيقك بمُختلف مكتبات لغة بايثون، والتي يُمكنك تنصيبها بسهولة بأداة pip، وهي أداة لإدارة الحزم (مثل Gem بالنّسبة للغة روبي و Composer بالنّسبة للغة PHP). يُمكن كذلك الاعتماد على إضافات لجعل الإطار أقرب إلى الأطر الكبيرة مثل Django إذ يمتلك إطار العمل Flask العديد من الإضافات التي يُمكنك تنصيبها واستعمالها في مشروعك، ما يُمكن أن يُساعدك على إنشاء مشاريع كبيرة. Flask أم Django؟ يعتبر الاختيار بين إطار Flask وإطار Django من القرارات الصّعبة على المُبتدئ، لكنّ عليك فهم الفرق بين الإطارين لتختار ما يُناسبك، فكما قلنا سابقا فإطار Django يُوفّر عددا هائلا من الدوال والأدوات المُساعدة، أما إطار Flask فيُوفّر أدوات بسيطة وعددا أقلّ من الدوال المُساعدة. يُمكنك اختيار تعلّم إطار Django إذا كانت لديك خبرة مُسبقة بأحد أطر العمل في اللغات الأخرى مثل Laravel أو Ruby On Rails، كما يُنصح به إذا كان المشروع الذي ستعمل عليه كبيرا كتطبيق تواصل اجتماعي أو تطبيق خدمي. أما إذا لم تكن تملك أية خبرة مُسبقة فأنصح بتعلّم إطار Flask أولا، وبعد التمكن من التعامل معه وإتقان ذلك يُمكنك الانتقال إلى استعمال Django متى ما دعت الحاجة إلى ذلك، وستجد حينها بأنّ الوقت الذي استثمرته في تعلّم Flask قد أتى أكله، وسيسهل عليك تعلّم إطار Django وفهم كيفيّة عمله. كيف تستفيد من هذه السلسلة من الدروس؟ سلسلة الدروس هذه ستكون موزعة حسب المُخطّط التالي: إعداد بيئة التّطوير وإنشاء تطبيقك الأول تقديم ملفات HTML وملفات CSS والصور استخدام قاعدة بيانات مع تطبيق Flask كل درس سيكون شبه مُستقل عن الدّرس الذي يسبقه، وذلك لتكون الدروس مرجعا لك في حالة نسيان أي جزئية. في نهاية السّلسلة ستكون قادرا على استعمال لغة بايثون لتطوير تطبيق يعمل على المُتصفّح ويتصل بقاعدة بيانات. ختاما في الدّرس المُقبل سنقوم بإعداد بيئة التّطوير بتنصيب الأدوات المطلوبة، كما سننشئ تطبيقا بسيطا لعرض صفحة ويب على المُتصفّح.

يعتبر React.js -على حداثته- من أقوى أطر عمل Javascript (بعضهم قد يسميه مكتبة وليس إطار عمل) لبناء الواجهات الرسومية على الويب، حيث طبّق أفكارًا جديدة في هذا المجال، جعلت شِفرة الواجهات البرمجية أكثر نظافة، سرعة وأكثر قابلية للصيانة. يسمح لك React ببناء الواجهة الرسومية في مجموعة مكونات، كل مكوّن عبارة عن سرد لهيكلة ومنطق المكون، إذا تمزج بين شِفرة HTML مخصصّة وشِفرة جافاسكربت تصف سلوك ذاك المكون، ليكون قائما بذاته وقابلا لإعادة الاستعمال. إطار عمل React مُطور من طرف شركة فيس بوك (Facebook)، وقد يكفيك ثقة ويجذب انتباهك بمجرد أن تعرف أن فيس بوك نفسها تستخدم React في واجهتها البرمجية على موقع Facebook نفسه! يمكنك فتح موقع Facebook وعرض شفرة HTML الخاصة به والبحث عن كلمة react للتأكد بنفسك. سنقوم في هذا الدرس بإنشاء مُربَّع تعليقات بسيط وفعَّال بإمكانك وضعه في مدوَّنتك، سيكون المُربَّع عبارة عن نُسخة مُجرَّدة من التعليقات الآنية التي تُقدمها لك تعليقات Disquse ،LiveFyre أو فيس بوك. ستجد في نهاية الدَّرس أنَّ لديكَ مُربَّع تعليقات يوفِّر ما يلي: عرض لجميع التعليقات.نموذج لإرسال تعليق.خُطَّافات لتوفير مُنتهى خلفي مُخصَّص custom backend.سوف يحتوي مُربَّع التعليقات كذلك على بعض المزايا اللَّطيفة: تعليق مُحسَّن: تظهر التَّعليقات في القائمة قبل أن يتمّ حفظها على الخادم وبناءً عليه تظهر التَّعليقات في التوِّ واللَّحظة.تحديثات حيَّة: تظهر تعليقات المستخدمين الآخرين في عرض التَّعليقات في نفس وقت الإرسال.هيئة Markdown: يُمكن للمستخدمين استخدام Markdown لتهيئة نصوصهم.هل ترغب في تخطِّي كل هذا ومعاينة المصدر؟ كل شيء موجود على GitHub. تشغيل الخادمرغم أنَّه ليس من الضروري أن تبدأ بهذا الجزء من الدرس إلَّا أنَّنا سنقوم في وقت لاحق بإضافة وظائف تتطلَّب المُشاركة POST إلى خادم قيد التشغيل. إذا كُنتَ واثقٌ من أنّك على دراية بهذا الأمر وترغب في إنشاء خادمك الخاص يُمكنكَ القيام بذلك. ولِمَن يُريد التَّركيز على تعلُّم React دون الحاجة إلى القلق بشأن جوانب الخادم، فلقد كتبنا خوادم بسيطة بعددٍ من اللُّغات: Python ،Ruby ،Go، Node.js و PHP. كلُّ هذا مُتاح على GitHub. يُمكن الاطِّلاع على المصدر أو تحميل ملفّ مضغوط للبدء. للبدء بتطبيق هذا الدَّرس، كلّ ما عليكَ فعله هو بداية تحرير public/index.php. البدءسنستخدم لهذا الدرس ملفَّات JavaScript سبق إنشاؤها على شبكة توصيل مُحتوى CDN. قم بفتح المُحرِّر المفضَّل لديك وقم بإنشاء مُستند HTML جديد: <!-- index.html --> <!DOCTYPE html> <html> <head> <title>Hello React</title> <script src="https://fb.me/react-0.13.3.js"></script> <script src="https://fb.me/JSXTransformer-0.13.3.js"></script> <script src="https://code.jquery.com/jquery-2.1.3.min.js"></script> </head> <body> <div id="content"></div> <script type="text/jsx"> // Your code here </script> </body> </html>سيتمّ كتابة شفرات JavaScript في وسم السكربت هذا طوال الفترة المتبقية من الدرس. مُلاحظة: قُمنا بإدراج jQuery هُنا لأننا نٌريد تبسيط الشَّفرات لاستدعاءات Ajax في المُستقبل، ولكنَّها ليست إلزاميَّة لعمل React. مُكوِّنكَ الأوَّلتتمحور الفكرة الأساسيَّة لـ React حول كل شيءٍ له علاقة بالمُكوِّنات التركيبيَّة القابلة للتَّشكيل modular, composable components. سنستخدم بنية المُكوٍّنات التالية لمثال مُربَّع التَّعليقات لهذا الدرس: - CommentBox - CommentList - Comment - CommentFormسنقوم الآن ببناء المُكوِّن CommentBox وما هو إلَّا وسم بسيط: // tutorial1.js var CommentBox = React.createClass({ render: function() { return ( <div className="commentBox"> Hello, world! I am a CommentBox. </div> ); } }); React.render( <CommentBox />, document.getElementById('content') );لاحظ أن أسماء عناصر HTML تبدأ بحرف صغير في حين أن أسماء فئات React تبدأ بحرف كبير. 1. صياغة JSXستُلاحظ أوَّل ما تلاحظ تلكَ الصياغة المُشابهة لـ XML في شفرة JavaScript. لدينا precompiler بسيط يُترجم الجُملة البسيطة Syntactic Sugar إلى شفرات JavaScript المُجرَّدة هذه: // tutorial1-raw.js var CommentBox = React.createClass({displayName: 'CommentBox', render: function() { return ( React.createElement('div', {className: "commentBox"}, "Hello, world! I am a CommentBox." ) ); } }); React.render( React.createElement(CommentBox, null), document.getElementById('content') );إنَّ استخدام صياغة JSX اختياري ولكن وجدنا أنَّها أسهل استخدامًا من شفرات JavaScript مُجرَّدة. يُمكن قراءة المزيد في مقال صياغة JSX 2. ماذا يحدث هنانقوم بتمرير بعض الوظائف في كائن JavaScript إلى دالَّة ()React.createClass لإنشاء مُكوِّن React جديد. أهم هذه الوظائف ما تُسمَّى تصيير render والتي تُعيد شجرة من مُكوِّنات React والتي في نهاية المطاف ستقوم بالتصيير عبر HTML. لا تُعتبر وسوم عُقَد نموذج كائن مُستند DOM فعليَّة، وإنَّما هي تمثيلات من مُكوِّنات div الخاصَّة بـ React. يُمكنكَ اعتبارها كوسوم أو قطع من البيانات والتي يعرف React كيفيَّة التعامل معها. React آمن. لا نقوم بتوليد سلاسل HTML لذلك فإن حماية XSS تُعتبر الافتراضيَّة. لا يجب عليكَ إعادة شفرات HTML قياسيَّة. وإنَّما يُمكنكَ إعادة شجرة من المُكوِّنات التي قُمتَ (أو شخص آخر قام) ببنائها. هذا ما يجعل React قابلة للتَّشكيل composable: وهي عقيدة أساسيَّة في الواجهات الأماميَّة القابلة للصّيانة. يقوم ()React.render بتمثيل المُكوِّن القاعدي، بدء عمل الإطار، ثم إدخال الوسوم إلى عنصر نموذج كائن مُستند خام، يتمّ تقديم تلك الوسوم كمُعطى ثاني . تركيب المُكوِّناتسنُنشيء الآن هياكل بناء لكلٍّ من المُكوِّنين CommentList وCommentForm والتي ستكون -مرَّة أخرى- عبارة عن وسوم بسيطة. أضِف هذين المُكوِّنين إلى ملفِّك مع الحفاظ على تعريف commentBox الحالي واستدعاء React.render: // tutorial2.js var CommentList = React.createClass({ render: function() { return ( <div className="commentList"> Hello, world! I am a CommentList. </div> ); } }); var CommentForm = React.createClass({ render: function() { return ( <div className="commentForm"> Hello, world! I am a CommentForm. </div> ); } });ما سنقوم بعمله الآن هو تحديث مُكوِّن CommentBox لاستخدام المُكوِّنات الجديدة: // tutorial3.js var CommentBox = React.createClass({ render: function() { return ( <div className="commentBox"> <h1>Comments</h1> <CommentList /> <CommentForm /> </div> ); } });لاحظ كيف تمَّ مزج وسوم HTML والمُكوِّنات التي قُمنا ببنائها. إنَّ مُكوِّنات HTML ما هي إلَّا مُكوِّنات React مُنتظمة، تمامًا مثل تلك التي تقوم بتعريفها ولكن مع فارق واحد. سيقوم مترجم JSX تلقائيًا بإعادة كتابة وسوم HTML إلى تعبيرات React.createElement() tagName وترك كل شيء على حدة. وهذا لمنع حدوث التَّلوّث في مساحة الاسم العموميَّة global namespace. استخدام الخصائصسنقوم الآن بانشاء مُكوِّن Comment، والذي سوف يعتمد على البيانات التي تمَّ تمريرها إليه من المُكوِّن الأساسي. يتمّ اتاحة البيانات التي تمّ تمريرها من مُكوِّن أساسي كـ "خاصيَّة" في المُكوِّن الفرعي. ويتمّ الوصول إلى هذه "الخصائص" من خلال this.props. يُمكننا باستخدام الخصائص props قراءة البيانات التي تمّ تمريرها إلى Comment من CommentList، وتصيير بعض الترميزات: // tutorial4.js var Comment = React.createClass({ render: function() { return ( <div className="comment"> <h2 className="commentAuthor"> {this.props.author} </h2> {this.props.children} </div> ); } });يُمكنكَ وضع نصّ أو مُكوِّنات React في الشَّجرة وذلك بإحاطة تعبير JavaScript بأقواس داخل JSX (إما كخاصيَّة أو كمُكوِّن فرعي). نقوم بالوصول إلى خاصيَّات مُسمَّاه تمّ تمريرها إلى عنصر كمفاتيح على this.props وأيّ عناصر مُتداخلة كما this.props.children. خصائص المُكوِّننحتاج الآن وبعد أن قمنا بتحديد مُكوِّن Comment إلى تمرير اسم الكاتب ونصّ التعليق إلى هذا المُكوِّن. يسمح لنا هذا بإعادة استخدام نفس الشَّفرة لكلِّ تعليق مُختلف. لنقوم الآن بإضافة بعض التَّعليقات داخل مُكوِّن CommentList: // tutorial5.js var CommentList = React.createClass({ render: function() { return ( <div className="commentList"> <Comment author="Pete Hunt">This is one comment</Comment> <Comment author="Jordan Walke">This is *another* comment</Comment> </div> ); } });لاحظ أنَّنا قد قُمنا بتمرير بعض البيانات من مُكوِّن CommentList الأساسي إلى مُكوِّنات Comment الفرعيَّة. مرَّرنا على سبيل المثال Pete Hunt (عن طريق خاصيَّة) وThis is one comment (عن طريق عُقدة فرعيَّة تُشبه XML) إلى Comment الأوَّل. وكما ذكرنا بالأعلى فإنَّ مُكوِّن Comment سيعمل على الوصول إلى هذه الخصائص من خلال this.props.author، وthis.props.children. إضافة MarkdownMarkdown هي طريقة بسيطة لتهيئة مُضمّنة inline لنصِّك. على سبيل المثال، احاطة النص بعلامة النجمة (*) سيقوم بتأكيده. أولًا، أضِف مكتبة الطرف الثالث marked إلى تطبيقك. Marked هي مكتبة JavaScript تقوم بأخذ نص Markdown وتُحوِّله إلى صيغة HTML خام. هذا الأمر يتطلَّب وسم سكربت في قسم head (قُمنا بادراجه بالفعل في أرضيَّة React): <!-- index.html --> <head> <title>Hello React</title> <script src="https://fb.me/react-0.13.3.js"></script> <script src="https://fb.me/JSXTransformer-0.13.3.js"></script> <script src="https://code.jquery.com/jquery-2.1.3.min.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/marked/0.3.2/marked.min.js"></script> </head>سنقوم بعد ذلك بتحويل نصّ التَّعليق إلى Markdown ومن ثمَّ إخراجه: // tutorial6.js var Comment = React.createClass({ render: function() { return ( <div className="comment"> <h2 className="commentAuthor"> {this.props.author} </h2> {marked(this.props.children.toString())} </div> ); } });كل ما فعلناه هنا هو استدعاء مكتبة marked. نحتاج إلى تحويل this.props.children من نصّ React مُحاط إلى سلسلة خام يُمكن لمكتبة marked فهمها ولذلك فإننا نقوم بستدعاء دالَّة ()toString. لكن لدينا مشكلة وهي أنَّه يتمّ إظهار وسوم HTML الموجودة في التَّعليقات بالشكل التَّالي في المُتصفح: This is another comment. هذا الأمر هو حماية React لك من هجوم XSS. هُناك طريقة للالتفاف على ذلك، ولكنَّ إطار العمل يُحذِّرُكَ من استخدامها: // tutorial7.js var Comment = React.createClass({ render: function() { var rawMarkup = marked(this.props.children.toString(), {sanitize: true}); return ( <div className="comment"> <h2 className="commentAuthor"> {this.props.author} </h2> <span dangerouslySetInnerHTML={{__html: rawMarkup}} /> </div> ); } });هذه الشَّفرات هي API خاصّ والذي عمدًا يجعل من الصَّعب إدراج شفرات HTML خام، في حالتنا بالنِّسبة لمكتبة marked فإنَّنا سنقوم بالاستفادة من هذا المنفذ الخلفيّ. تذكَّر: باستخدامك لهذه الميزة فإنَّك تعتمد على مكتبة marked أن تكون آمنة. نقوم في هذه الحالة بتمرير sanitize: true التي تطلب من مكتبة marked تنفيذ أي وسم HTML في المصدر بدلًا من تمريره دون تغيير. إضافة نموذج البياناتحتَّى الآن فإنَّنا نقوم بإدراج تعليقات مُباشرة في شفرات المصدر. بدلًا من ذلك، سنقوم بتصيير بضع من بيانات JSON في قائمة التعليق. يأتي هذا من الخادم في نهاية المطاف، ولكن في الوقت الراهن سنكتبها نحن في المصدر: // tutorial8.js var data = [ {author: "Pete Hunt", text: "This is one comment"}, {author: "Jordan Walke", text: "This is *another* comment"} ];الآن نحنُ بحاجة إلى إدخال هذه البيانات في مُكوِّن CommentList بطريقة نموذجيِّة. قُم بتعديل CommentBox واستدعاء ()React.render لتمرير هذه البيانات إلى CommentList عن طريق الخصائص props: // tutorial9.js var CommentBox = React.createClass({ render: function() { return ( <div className="commentBox"> <h1>Comments</h1> <CommentList data={this.props.data} /> <CommentForm /> </div> ); } }); React.render( <CommentBox data={data} />, document.getElementById('content') );الآن حيثُ أنَّ البيانات مُتاحة في CommentList، سوف نقوم بتقديم التَّعليقات بطريقة ديناميكيَّة: // tutorial10.js var CommentList = React.createClass({ render: function() { var commentNodes = this.props.data.map(function (comment) { return ( <Comment author={comment.author}> {comment.text} </Comment> ); }); return ( <div className="commentList"> {commentNodes} </div> ); } });هذا كل شيء. الاستدعاء من الخادمسنعمل الآن على استبدال البيانات الثَّابتة ببعض البيانات الديناميكيَّة من الخادم. يتمّ ذلك بإزالة خاصيَّة البيانات data prop واستبدالها بعنوان URL للجلب: // tutorial11.js React.render( <CommentBox url="comments.json" />, document.getElementById('content') );هذا المُكوِّن مُختلف عن المُكوِّنات السَّابقة حيثُ أنَّه سيضطر إلى إعادة تصيير نفسه. لن يحتوي المُكوِّن على أيّ بيانات إلى أن يعود الطَّلب من الخادم، في هذه الحالة قد يحتاج المُكوِّن إلى تصيير بعض التَّعليقات الجديدة. الحالة التفاعليَّةقام كلّ مُكوِّن حتَّى الآن على أساس خصائصه بتصيير نفسه مرة واحدة. الخصائص props ثابتة: يتمّ تمريرها من المُكوِّن الأساسي و”مملوكة” من قبل المُكوِّن الأساسي كذلك. لتنفيذ التَّفاعلات، فإنَّنا نُقدِّم حالة قابلة للتغيير إلى المُكوِّن. حالة this.state هي خاصَّة بالمُكوِّن ويُمكن تغييرها من خلال استدعاء ()this.setState يقوم المُكوِّن بإعادة تقديم نفسه عند تحديث الحالة. وظائف ()render مكتوبة إلزاميًّا كدوال this.props وthis.state. يضمن إطار العمل أن تكون واجهة المستخدم دائمًا مُتَّسِقَة مع المُدخَلات. عندما يقوم الخادم بجلب بيانات سنقوم نحن بتغيير بيانات التعليق لدينا. لنُضيف الآن مصفوفة من بيانات التَّعليق كحالة للمُكوِّن CommentBox: // tutorial12.js var CommentBox = React.createClass({ getInitialState: function() { return {data: []}; }, render: function() { return ( <div className="commentBox"> <h1>Comments</h1> <CommentList data={this.state.data} /> <CommentForm /> </div> ); } });يتمّ تنفيذ دالَّة ()getInitialState مرَّة واحدة فقط خلال دورة حياة المُكوِّن كما أنَّها تبدأ الحالة الأوليَّة للمُكوِّن. تحديث الحالةنُريد عند إنشاء المُكوِّن لأوَّل مرَّة أن نحصل على (GET) بعض بيانات JSON من الخادم وتحديث الحالة لتعكس أحدث البيانات. هذا من شأنه أن يكون نقطة نهاية ديناميكيَّة لو كان الأمر في تطبيق حقيقي، ولكن سنستخدم لهذا المثال ملف JSON ثابت لابقاء الأمور بسيطة: // tutorial13.json [ {"author": "Pete Hunt", "text": "This is one comment"}, {"author": "Jordan Walke", "text": "This is *another* comment"} ]سنقوم باستخدام مكتبة jQuery للمساعدة في عمل طلب غير متزامن asynchronous request إلى الخادم. مُلاحظة: حيثُ أنَّ هذا الأمر أصبح تطبيق AJAX فإنَّك سوف تحتاج لتطوير تطيبقك باستخدام خادم ويب بدلًا من أن ملف موجود في نظام ملفاتك. قدَّمنا -كما هو مذكورٌ بالأعلى- العديد من الخوادم التي يُمكنكَ استخدامها على GitHub. توفر تلك الخوادم التأدية الوظيفيَّة التي تحتاجها لبقيَّة هذا الدرس. // tutorial13.js var CommentBox = React.createClass({ getInitialState: function() { return {data: []}; }, componentDidMount: function() { $.ajax({ url: this.props.url, dataType: 'json', cache: false, success: function(data) { this.setState({data: data}); }.bind(this), error: function(xhr, status, err) { console.error(this.props.url, status, err.toString()); }.bind(this) }); }, render: function() { return ( <div className="commentBox"> <h1>Comments</h1> <CommentList data={this.state.data} /> <CommentForm /> </div> ); } });وظيفة componentDidMount هنا هي وظيفة تُستدعى تلقائيًا بواسطة React عندما يتمّ تصيير مُكوِّن. مفتاح التَّحديثات الديناميكيَّة هو استدعاء دالَّة ()this.setState. نقوم باستبدال مصفوفة التَّعليقات القديمة بواحدة جديدة من الخادم وتقوم واجهة المستخدم بتحديث نفسها تلقائيًا. بسبب هذا التفاعل، يُعتبر التغيير لإضافة تحديثات حيَّة طفيفًا. سوف نستخدم أسلوب بسيط في هذا الدَّرس ولكن لكَ الحُريَّة في استخدام WebSockets أو غيرها من التكنولوجيَّات. // tutorial14.js var CommentBox = React.createClass({ loadCommentsFromServer: function() { $.ajax({ url: this.props.url, dataType: 'json', cache: false, success: function(data) { this.setState({data: data}); }.bind(this), error: function(xhr, status, err) { console.error(this.props.url, status, err.toString()); }.bind(this) }); }, getInitialState: function() { return {data: []}; }, componentDidMount: function() { this.loadCommentsFromServer(); setInterval(this.loadCommentsFromServer, this.props.pollInterval); }, render: function() { return ( <div className="commentBox"> <h1>Comments</h1> <CommentList data={this.state.data} /> <CommentForm /> </div> ); } }); React.render( <CommentBox url="comments.json" pollInterval={2000} />, document.getElementById('content') );كل ما فعلناه هنا هو نقل استدعاء AJAX إلى وظيفة مُستقلَّة واستدعائها عند تحميل المُكوِّن الأوَّل واستدعائها كلّ ثانيتين بعد ذلك. حاول تشغيل هذا في مُتصفِّحك وتغيير ملف comments.json. في غضون ثانيتين ستظهر لكَ التغييرات. إضافة تعليقات جديدةحان الآن الوقت لبناء النموذج. على مُكوِّن CommentForm أن يسأل المُستخدم عن اسمه ونصّ التَّعليق، ثم يقوم بإرسال طلب إلى الخادم لحفظ التعليق. // tutorial15.js var CommentForm = React.createClass({ render: function() { return ( <form className="commentForm"> <input type="text" placeholder="Your name" /> <input type="text" placeholder="Say something..." /> <input type="submit" value="Post" /> </form> ); } });دعونا نجعل النموذج متجاوب. عندما يقوم المُستخدم بإرسال النَّموذج، يجب علينا مسحه clear، تقديم طلب إلى الخادم، ثُمَّ تحديث قائمة التعليقات. للبدء في تنفيذ هذا، سقوم بالاستماع إلى حدث ارسال النَّموذج ومسحه. // tutorial16.js var CommentForm = React.createClass({ handleSubmit: function(e) { e.preventDefault(); var author = React.findDOMNode(this.refs.author).value.trim(); var text = React.findDOMNode(this.refs.text).value.trim(); if (!text || !author) { return; } // TODO: send request to the server React.findDOMNode(this.refs.author).value = ''; React.findDOMNode(this.refs.text).value = ''; return; }, render: function() { return ( <form className="commentForm" onSubmit={this.handleSubmit}> <input type="text" placeholder="Your name" ref="author" /> <input type="text" placeholder="Say something..." ref="text" /> <input type="submit" value="Post" /> </form> ); } });1- الأحداث Eventsتقوم React بإرفاق مُعالجات الحدث في المُكوِّنات باستخدام اتفاقية التَّسمية camelCase. نقوم بإرفاق مُعالج onSubmit إلى النَّموذج الذي يعمل على مسح حقول النَّموذج عند إرساله مع إدخال صحيح. عليكَ استدعاء ()preventDefault بالحدث لمنع الإجراء الافتراضي للمُتصفِّح من اعتماد النَّموذج. 2- المراجع Refsنستخدم خاصيَّة ref لتعيين اسم للمُكوِّن الفرعي وthis.refs لارجاع المُكوِّن. يمكن أن نستدعي (React.findDOMNode(componentعلى مُكوّن للحصول على عنصر نموذج كائن مُستند المُتصفِّح الأصلي. 3- نداءات الخصائصعندما يُرسِل المُستخدم التَّعليق، فإنَّنا سوف تحتاج إلى تحديث قائمة التَّعليقات لتشمل التَّعليق الجديد. من الطبيعي أن تفعل كل هذا في مُكوِّن CommentBox حيث أنَّ المُكوِّن يمتلك الحالة التي تُمثِّل قائمة التَّعليقات. نحن بحاجة لتمرير البيانات من نُسخة المُكوِّن الفرعي الاحتياطيَّة إلى المُكوِّن. يتمّ فعل هذا في وظيفة render الخاصَّة بالأب عن طريق تمرير رد نداء جديد (handleCommentSubmit) في الابن ثُمَّ الزامها لحدث الابن onCommentSubmit. كُلَّما تم تشغيل الحدث، سيُنفَّذ الاستدعاء: // tutorial17.js var CommentBox = React.createClass({ loadCommentsFromServer: function() { $.ajax({ url: this.props.url, dataType: 'json', cache: false, success: function(data) { this.setState({data: data}); }.bind(this), error: function(xhr, status, err) { console.error(this.props.url, status, err.toString()); }.bind(this) }); }, handleCommentSubmit: function(comment) { // TODO: submit to the server and refresh the list }, getInitialState: function() { return {data: []}; }, componentDidMount: function() { this.loadCommentsFromServer(); setInterval(this.loadCommentsFromServer, this.props.pollInterval); }, render: function() { return ( <div className="commentBox"> <h1>Comments</h1> <CommentList data={this.state.data} /> <CommentForm onCommentSubmit={this.handleCommentSubmit} /> </div> ); } });سوف نستدعي الآن النِّداء من CommentForm عندما يقوم المُستخدم بإرسال النَّموذج: // tutorial18.js var CommentForm = React.createClass({ handleSubmit: function(e) { e.preventDefault(); var author = React.findDOMNode(this.refs.author).value.trim(); var text = React.findDOMNode(this.refs.text).value.trim(); if (!text || !author) { return; } this.props.onCommentSubmit({author: author, text: text}); React.findDOMNode(this.refs.author).value = ''; React.findDOMNode(this.refs.text).value = ''; return; }, render: function() { return ( <form className="commentForm" onSubmit={this.handleSubmit}> <input type="text" placeholder="Your name" ref="author" /> <input type="text" placeholder="Say something..." ref="text" /> <input type="submit" value="Post" /> </form> ); } });الآن وبعد أن أصبح النِّداء في مكانه الصحيح، كل ما علينا القيام به هو الإرسال إلى الخادم وتحديث القائمة: // tutorial19.js var CommentBox = React.createClass({ loadCommentsFromServer: function() { $.ajax({ url: this.props.url, dataType: 'json', cache: false, success: function(data) { this.setState({data: data}); }.bind(this), error: function(xhr, status, err) { console.error(this.props.url, status, err.toString()); }.bind(this) }); }, handleCommentSubmit: function(comment) { $.ajax({ url: this.props.url, dataType: 'json', type: 'POST', data: comment, success: function(data) { this.setState({data: data}); }.bind(this), error: function(xhr, status, err) { console.error(this.props.url, status, err.toString()); }.bind(this) }); }, getInitialState: function() { return {data: []}; }, componentDidMount: function() { this.loadCommentsFromServer(); setInterval(this.loadCommentsFromServer, this.props.pollInterval); }, render: function() { return ( <div className="commentBox"> <h1>Comments</h1> <CommentList data={this.state.data} /> <CommentForm onCommentSubmit={this.handleCommentSubmit} /> </div> ); } });تحديثات مُحسَّنةمشروعنا الآن كامل الوظائف ولكن من المُمل أن نقوم بانتظار الطَّلب حتَّى يكتمل قبل ظهور تعليقك في القائمة. يُمكننا إضافة هذا التَّعليق إلى القائمة لجعل التطبيق يعمل بشكلٍ أسرع. // tutorial20.js var CommentBox = React.createClass({ loadCommentsFromServer: function() { $.ajax({ url: this.props.url, dataType: 'json', cache: false, success: function(data) { this.setState({data: data}); }.bind(this), error: function(xhr, status, err) { console.error(this.props.url, status, err.toString()); }.bind(this) }); }, handleCommentSubmit: function(comment) { var comments = this.state.data; var newComments = comments.concat([comment]); this.setState({data: newComments}); $.ajax({ url: this.props.url, dataType: 'json', type: 'POST', data: comment, success: function(data) { this.setState({data: data}); }.bind(this), error: function(xhr, status, err) { console.error(this.props.url, status, err.toString()); }.bind(this) }); }, getInitialState: function() { return {data: []}; }, componentDidMount: function() { this.loadCommentsFromServer(); setInterval(this.loadCommentsFromServer, this.props.pollInterval); }, render: function() { return ( <div className="commentBox"> <h1>Comments</h1> <CommentList data={this.state.data} /> <CommentForm onCommentSubmit={this.handleCommentSubmit} /> </div> ); } });ختامًاانتهيتَ لتوك من إنشاء مربع تعليقات في بضع خطوات بسيطة. يُمكنك الآن التَّعرُّف على المزيد حول أسباب استخدام React، أو الخوض في مراجع API وبدء العمل. ترجمة -وبتصرّف- للمقال: Tutorial | React.

تُظهر هذ الإرشادات كيفية إنشاء تطبيقات JS/HTML Cordova ونشرها على منصّات موبايل أصليّة متنوعة باستخدام واجهة سطر أوامر كوردوفا (cordova (CLI, راجع CLI reference لتفاصيل مرجعية عن واجهة سطر أوامر Cordova. تثبيت Cordova CLI واجهة سطر أوامر Cordova موزّعة كحزمة npm (نظام إدارة حزم). اتبع الخطوات التالية لتثبيت أداة cordova CLI : 1- حمّل وثبّت Node.js. خلال التثبيت يجب أن تكون قادراً على استدعاء node و npm على سطر الأوامر الخاص بك. 2- (اختياري) حمّل وثبّت git client, إذا لم يكن لديك نسخة مسبقًا. قم بتثبيتها, وبعدها يجب أن تكون قادرًا على استدعاء git على سطر الأوامر الخاص بك. حيث يستخدمها CLI لتحميل الموارد عندما يتم الاشارة إليها باستخدام git repo 3- ثبّت cordova باستخدام أداة npm لـ Node.js. حيث سيُحمّل cordova أوتوماتيكيًا باستخدام أداة npm . في OS ولينكس $ sudo npm install -g cordova في أنظمة OSX و LINUX قد يكون الحاق الأمر npm بـ sudo ضروريًا لتثبيت أداة التطوير هذه في الأدلة المقيّدة مثل /usr/local/share إذا كنت تستخدم الأداة الاختيارية nvm/nave أو تمتلك صلاحية الوصول الى دليل التثبيت. يمكنك الاستغناء عن البادئة sudo . في نظام التشغيل ويندوز Windows C:\>npm install -g cordova تخبر العلامة g- الأمر npm بتثبيت cordova بشكل عام. وإذا لم يتم التحديد سيتم التثبيت في الدليل الفرعي node_modules من مسار التثبيت الحالي. بعد إتمام التثبيت يجب أن تتمكن من تشغيل cordova من موجه الأوامر بدون معامِلات، ويجب أن تقوم Cordova بطباعة نص للمساعدة على شاشة موجه الأوامر.. إنشاء التطبيق اذهب الى الدليل الذي تدير فيه شفرتك المصدرية. وأنشئ مشروع Cordova $ cordova create hello com.example.hello HelloWorld هذا ينشئ بنية الدليل المطلوب لتطبيق cordova الخاص بك. افتراضيًا, سكريب cordova create يولد هيكلية تطبيق معتمد على الوب والذي صفحته الرئيسية هي ملف المشروع www/index.html. إضافة منصّات يجب تشغيل جميع الأوامر اللاحقة ضمن الدليل الرئيسي المشروع، أو أي دليل فرعي: $ cd hello أضف المنصّات التي ترد لتطبيقك أن يستهدفها. سنضيف منصّة أندرويد و IOS والتأكد من حفظها الى config.xml و package.json: $ cordova platform add ios $ cordova platform add android للتأكد من مجموعتك الحاليّة للمنصّات: $ cordova platform ls تشغيل أوامر لإضافة أو إزالة المنصّات يؤثّر على محتويات دليل منصّات المشروع، حيث تظهر كل منصّة محدّدة كدليل فرعي. ثبيت المتطلبات المسبقة للبناء لإنشاء التطبيقات وتشغيلها، يلزمك تثبيت حزم SDK لكل منصّة تريد استهدافها. بدلاً من ذلك، إذا كنت تستخدم متصفح للتطوير فيمكنك استخدام منصّة browser التي لا تتطلب أية SDKs للمنصّة. للتحقق مما إذا كنت مستوفيًا لمتطلبات إنشاء المنصّة: $ cordova requirements Requirements check results for android: Java JDK: installed . Android SDK: installed Android target: installed android-19,android-21,android-22,android-23,Google Inc.:Google APIs:19,Google Inc.:Google APIs (x86 System Image):19,Google Inc.:Google APIs:23 Gradle: installed Requirements check results for ios: Apple OS X: not installed Cordova tooling for iOS requires Apple OS X Error: Some of requirements check failed بناء التطبيق افتراضيًا، Cordova تنشئ سكريبت يولد هيكلية تطبيق معتمد على الوب والذي صفحة البداية له هي ملف المشروع www/index.html. يجب تحديد أيّة تهيئة كجزء من معالج حدث deviceready المعرّف في www/js/index.js. قم بتشغيل الأمر التالي لبناء المشروع لجميع المنصّات: $ cordova build يمكنك اختياريًا تحديد المجال في كل بناء لمنصّات محدّدة- في هذه الحالة"ios" $ cordova build ios اختبار التطبيق غالباً ما تأتي حزم SDK لمنصّات الموبايل مع محاكي تشغّل صورة الجهاز, وبذلك يمكنك تشغيل التطبيق من الشاشة الرئيسية ومشاهدة كيفية تفاعله مع العديد من ميزات المنصّة. شغّل أمر مثل التالي لإعادة بناء التطبيق وعرضه ضمن محاكي منصّة معيّنة: $ cordova emulate android تبعاً لأوامر محاكي Cordova تحدّث (refreshes) صورة المحاكي لعرض أحدث تطبيق, والذي قد أصبح متاحاً للوصول من الشاشة الرئيسية: في نفس الوقت يمكنك توصيل الهاتف إلى حاسوبك واختبار التطبيق مباشرةً: $ cordova run android قبل تشغيل هذا الأمر، تحتاج إلى إعداد الجهاز للاختبار، باتباع الإجراءات التي تختلف حسب كل منصّة. إضافة الإضافات Plugins يمكنك تعديل التطبيق المولَّد افتراضياً للاستفادة من ميزات تقنيات الوب المعيارية, ولكن ستكون بحاجة لإضافة Plugins لكي يتمكّن التطبيق من الوصول لميزات على مستوى الجهاز. تعرض الإضافة واجهة برمجة تطبيقات جافا سكربت Javascript API لوظيفة SDK الأصلية. يتم استضافة الإضافات عادةً على npm ويمكنك البحث عنهم في صفحة plugin search. تُزوَّد بعض مفاتيح API من قبل مشروع المصدر المفتوح Apache Cordova ويشار إليها باسم Core Plugin APIs $ cordova plugin search camera لإضافة وحفظ إضافة الكاميرا إلى config.xml و package.json، سنحدّد اسم حزمة لإضافة الكاميرا: $ cordova plugin add cordova-plugin-camera Fetching plugin "cordova-plugin-camera@~2.1.0" via npm Installing "cordova-plugin-camera" for android Installing "cordova-plugin-camera" for ios يمكن أن تضاف الإضافات أيضاً باستخدام الدليل أو باستخدام git repo استخدم plugin ls أو plugin list أو plugin لوحدها لعرض الإضافات المثبّتة حالياً. كلٌ يُعرض من خلال معرّفه الخاص: $ cordova plugin ls cordova-plugin-camera 2.1.0 "Camera" cordova-plugin-whitelist 1.2.1 "Whitelist" استخدام mergesلتخصيص كل منصّة في حين أن Cordova تسمح لك بنشر التطبيق بسهولة على منصّات مختلفة, إلا أنه في بعض الأحيان ستحتاج لإضافة تخصيصات. في هذه الحالة, لن تقوم بتعديل الملفات المصدرية في أدّلة www المتعددة ضمن دليل المستوى العالي platforms , لأنه يتم استبداله بشكل منتظم مع مصدر المنصّات المتعددة لدليل المستوى العالي www بدلاً من ذلك، دليل المستوى الأعلى merges يوفر مكاناً لتحديد الموارد للنشر على منصّات محدّدة. يعكس كل دليل فرعي خاص بالمنصّة ضمن عمليات merges بنية الدليل لشجرة المصدر www، مما يسمح لك بتجاوز أو إضافة ملفات حسب الحاجة. على سبيل المثال، إليك كيفية استخدام عمليات merges لزيادة حجم الخط الافتراضي لأجهزة أندرويد: حرّر ملف www/index.html , مضيفاُ رابط ملف CSS إضافي, overrides.css في هذه الحالة: <link rel="stylesheet" type="text/css" href="css/overrides.css" /> يمكن اختياريا إنشاء ملف www/css/overrides.css فارغ. والذي سيطبق من أجل كل بناء غير مخصص للأندرويد, لمنع خطأ الملف مفقود (missing-file) أنشئ ملف css على دليل فرعي ضمن merges/android, ثم أضف ملف overrides.css المقابل. حدّد CSS الذي يتجاوز حجم الخط الافتراضي 12-نقطة داخل www/css/index.css, على سبيل المثال: body { font-size:14px; } عندما تعيد بناء المشروع, تضمّن نسخة الأندرويد حجم الخط المخصص, بينما تظل البقية دون تغيير. كما يمكن استخدام merges لإضافة ملفات غير موجودة في الدليل الأصلي www. على سبيل المثال, تطبيق يمكنه تضمين back button رسومي داخل واجهة الـ iOS, مخزّن في merges/ios/img/back_button.png , ، في حين أنه يمكن لنسخة الأندرويد بدلاً من ذلك التقاط الأحداث backbutton من زر الأجهزة المقابلة. تحديث كوردوفا وتطبيقك بعد تثبيت أداة Cordova, يمكنك دوماً تحديثها إلى آخر إصدار من خلال تشغيل الأمر $ sudo npm update -g cordova استخدم هذه الصّياغة لتثبيت إصدار محدّد: $ sudo npm install -g cordova@3.1.0-0.2.0 نفّذ cordova -v لمعرفة النسخة الحالية قيد التشغيل. شغّل الأمر التالي لإيجاد آخر نسخة تم إصدارها Cordova: $ npm info cordova version لتحديث المنصّة التي تستهدفها: $ cordova platform update android --save $ cordova platform update ios --save ...etc. ترجمة -وبتصرّف- للمقال Create your first Cordova app للمساهمين في كتابة المقال على GitHub هذا المقال منشور تحت الرخصة Apache License, Version 2.0

Django هو إطار عمل مجّاني ومفتوح المصدر، مكتوب بلغة Python، وتتبع المشاريع فيه بنية Model-View-Template (عادة ما تختصر إلى MVT). يؤكّد Django على قابلية إعادة الاستخدام Reusability للمكونات وكذلك على التطوير السريع، بالإضافة إلى مبدأ عدم التكرار. تستخدم لغة Python في جميع مفاصل إطار العمل هذا، كالإعدادات ونماذج قواعد البيانات وغيرها. ومن أشهر المواقع التي تستخدم Django هي: Pinterest ،Instagram ،Mozilla ،The Washington Times ،Disqus ،National Geographic وغيرها الكثير. طوّر Django سنة 2003 على يدي المبرمجين Adrian Holovaty و Simon Willson اللذين يعملان في صحيفة Lawrence Journal World، وذلك عندما انتقلا إلى لغة Python لبناء التطبيقات. ثم أطلق Django سنة 2005 تحت رخصة BSD، وقد سمّي بهذا الاسم تيمنًا بعازف الغيتار Django Reinhardt. بنية MVT تنقسم بنية المشاريع في Django إلى ثلاثة أقسام مرتبطة ببعضها البعض، ولكنّها مختلفة عن أطر العمل الأخرى التي تتبع بنية (MVC - Model, View, Controller) مثل Laravel في PHP وغيرها، حيث تتكون المشاريع في Django من النموذج Model والعرض View والقالب Template. يتولى قسم النموذج معالجة البيانات والتعامل معها واسترجاعها، ويدعم Django العديد من قواعد البيانات، مثل: SQlite ،MySQL، و PostgreSQL. أما العرض فعبارة عن مجموعة من دوال Python التي تستجيب لعنوان URL معين، ووظيفة العرض هي تحديد البيانات والمعلومات التي يجب عرضها. أما القالب فهو عبارة عن ملف بصيغة HTML يتم من خلاله تحديد الطريقة التي ستظهر بها المعلومات التي يعرضها قسم العرض. أين المتحكم Controller إذًا؟ المتحكم هنا هو إطار العمل نفسه، أي الآلية التي يتم من خلالها إرسال الطلب إلى العرض المناسب بالاعتماد على عنوان URL محدّد. تثبيت Django إطار العمل Django هو إحدى الحزم الخاصة بلغة البرمجة بايثون، وتوفّر هذه اللغة مدير حزم خاصّ يدعى pip يتم من خلاله تثبيت وتحديث وإزالة الحزم بسهولة ويسر؛ لذا ستكون الخطوة الأولى في تثبيت Django هي التأكد من وجود مدير الحزم pip وتثبيته إن لم يكن متوفّرًا. تنصيب pip لتنصيب إطار العمل Django ستحتاج إلى مدير الحزم الخاصّ بـ Python وهو pip، ولحسن الحظّ فإن pip متوفّر في نسخة Python 2.7.9 وما بعدها، وفي نسخة Python 3.4 وما بعدها. في حال عدم توفّر pip في نسخة Python المنصّبة لديك يمكنك تنصيبه باتباع الخطوات التالية: حمّل الملفّ get-pip.py. توجه في سطر الأوامر إلى المكان الذي حملت فيه الملف السابق، ثم اكتب التعليمة التالية: python get-pip.py استخدام سطر الأوامر لنجرب الآن استخدام مدير الحزم في بايثون لتنصيب Django، توجّه الآن إلى سطر الأوامر ثم اكتب الأمر: pip install django==1.9 هل ظهرت لك رسالة خطأ؟ ما المشكلة، ألم نقم بتنصيب pip قبل قليل؟ هذا صحيح، ولكننا لم نخبر سطر الأوامر بأن يوجّه أي تعليمة تبدأ بكلمة pip إلى مدير حزم بايثون، وللقيام بذلك اتبع الخطوات التالية: في أوبنتو: يجب تنصيب حزمة python3-pip إن كنت تستخدم الإصدار الثالث من بايثون أو python-pip للإصدار الثاني من بايثون، لتتمكن من استخدام pip في سطر الأوامر في أبونتو، وللقيام بذلك اكتب الأمر التالي في سطر الأوامر: sudo apt-get install python3-pip أدخل كلمة المرور الخاصة بك، وستبدأ عملية التثبيت، وبعد الانتهاء يمكنك تنصيب أي حزمة خاصة بلغة بايثون عن طريق سطر الأوامر مباشرة. في نظام Windows: أما في نظام Windows فيجب إضافة السطر التالي: C:\Python34\scripts; إلى مسار النظام System path، وللقيام بذلك اتبع الخطوات التالية: انقر بزر الفأرة الأيمن على أيقونة Computer واختر Properties من القائمة المنسدلة: انقر على أيقونة Advance system settings، وفي مربع الحوار المنبثق اضغط على أيقونة Environment Variables. انقر نقراً مزدوجًا على متغير النظام Path في الجزء السفلي من مربع الحوار المنبثق. أضف السطر السابق إلى نهاية السلسلة النصّية، بعد الفاصلة المنقوطة (;) (إن لم تكن هناك فاصلة منقوطة في نهاية السطر فقم بإضافتها). اضغط Ok ثم أغلق بقية النوافذ بالضغط على Ok. يمكنك الآن استخدام pip من سطر الأوامر مباشرة. البيئة الافتراضية Virtual Environment قبل البدء بتنصيب Django سنعمل على تنصيب أداة مفيدة جدًّا من شأنها المساعدة على ترتيب البيئة البرمجية على حاسوبك. يمكن تجاوز هذه الخطوة، ولكن ينصح بها بشدّة. تعمل البيئة الافتراضية على عزل مشاريع Python أو Django الخاصّة بك عن بعضها البعض، وهذا يعني أن إجراء التعديلات على موقع إلكتروني معيّن لن تؤثّر على المشاريع الأخرى التي تعمل عليها. ستحتوي البيئة الافتراضية على الملفات التنفيذية الخاصة بـ Python بالإضافة إلى نسخة من مكتبة pip يمكنك استخدامها في تنصيب حزم Python المختلفة. سننشئ مجلدًا سيحتوي على البيئة الافتراضية التي سوف ننشئها بعد قليل. mkdir mysite cd mysite يتطلب إنشاء البيئة الافتراضية تنصيب حزمة virtualenv وسنستعين بـ pip للقيام بذلك: pip install virtualenv لاستخدام virtualenv من سطر الأوامر مباشرة في أوبنتو يجب تنصيب الحزمة virtualenv، وللقيام بذلك اكتب الأمر التالي في سطر الأوامر: sudo apt-get install virtualenv بعد اكتمال عملية التنصيب يمكنك إنشاء البيئة الافتراضية بالشكل التالي: virtualenv myvenv ستنشئ هذه الشيفرة بيئة افتراضية وهي عبارة عن مجموعة من المجلدات. لتفعيل البيئة الافتراضية الجديدة في نظام Windows استخدم الشيفرة التالية: myvenv\Scripts\activate أما في نظامي Linux و OS X فاستخدم: source myvenv/bin/activate ملاحظة: قد لا تحصل على النتيجة المرجوّة من الشيفرة السابقة، لذا يمكنك استخدام هذه الشيفرة: . myvenv/bin/activate سيتغيّر سطر الأوامر وذلك بإضافة كلمة (myvenv) إلى بداية السطر، وهذا يعني أن الأمور تسير على ما يرام. ولإغلاق البيئة الافتراضية يمكنك استخدام التعليمة التالية: deactivate تنصيب Django بعد اكتمال الخطوتين السابقتين يمكننا الآن تنصيب Django وذلك بتنفيذ الأمر التالي (انتبه إلى وجود علامتي مساواة لا علامة واحدة): pip install django==1.9 بعد اكتمال عملية التنصيب، وللتأكد من أن الأمور تجري على ما يرام، اكتب الأمر التالي في سطر الأوامر: python3 -c "import django; print(django.get_version())" إن حصلت على رقم النسخة (1.9 في حالتنا هذه) التي قمت بتنصيبها، فقد أصبحت جاهزًا لإنشاء مشروعك الأول على Django. إنشاء المشروع الأول مشروعنا الأول سيكون عبارة عن تطبيق استطلاع بسيط، يتألف من جزئين: موقع عام يتيح مشاهدة الاستطلاعات والتصويت عليها. لوحة تحكم تتيح لنا إضافة وحذف وتعديل الاستطلاعات. هذا المشروع سيكون مبنيًا على الإصدار 1.9 من Django والإصدار 3.4 من Python. في حال كنت تستخدم الإصدار 2.7 من Python فيتوجب عليك حينها إضافة بعض التعديلات على الشيفرة التي تكتبها، وسنشير إلى ذلك في محلّه. انتقل إلى سطر الأوامر وتوجه من خلاله إلى المجلد الذي ترغب استخدامه لإنشاء المشروع، وبإمكانك استخدام أي مجلد تحت أي تسمية وفي أي موقع في القرص الصلب، فلا مشكلة لدى Django في ذلك. لإنشاء المشروع نفّذ الأمر التّالي في سطر الأوامر (انتبه إلى النقطة في نهاية السطر): django-admin startproject mysite . سيعمل هذا الأمر على إنشاء مجلد باسم mysite داخل مجلد المشروع. انتبه كذلك إلى كتابة النقطة في نهاية السطر، فهي توجّه الشيفرة إلى تنصيب Django في المجلد الحالي. البنية الأولية للمشروع يحتوي مجلد mysite الذي أنشأته التعليمة السابقة، على مجموعة الملفات التالية: manage.py /mysite __init__.py settings.py urls.py wsgi.py manage.py، يُوصف هذا الملف بالسكين السويسري، وهو الأداة التي سنستعين بها للقيام بالكثير من الأشياء في إدارة الموقع، وفي تهجير قواعد البيانات وتشغيل الخادوم الخاص بـ Django، وغير ذلك الكثير. المجلد mysite هو حزمة بايثون الخاصة بمشروعنا، وسنستخدم هذا الاسم عندما نرغب في استيراد أي شيء داخله. (مثال mysite.urls). mysite/__init__.py ملف فارغ، ووجوده يعني أن هذا المجلّد هو حزمة من حزم بايثون. mysite/settings.py ملف الإعدادات الخاصة بمشروعنا. mysite/urls.py يحتوي على عناوين URL الخاصة بموقعنا، وهو أشبه ما يكون بجدول المحتويات الخاص بالموقع. mysite/wsgi.py نقطة الولوج إلى الخواديم المتوافقة مع WSGI. تشغيل الخادوم توجه في سطر الأوامر إلى المجلد الذي يحوي الملف manage.py ثم اكتب الأمر التالي: python manage.py runserver وستظهر العبارات التالية في سطر الأوامر: Performing system checks... System check identified no issues (0 silenced). You have unapplied migrations; your app may not work properly until they are applied. Run 'python manage.py migrate' to apply them. February 01, 2016 - 15:50:53 Django version 1.9, using settings 'mysite.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C. ملاحظة: لا تستخدم هذا الخادوم في المشاريع الإنتاجية على الإطلاق، فالهدف من هذا الخادوم هو استخدامه لأغراض التطوير فقط. أدخل العنوان التالي في متصفح الإنترنت: http://127.0.0.1:8000 ستظهر الصفحة التالية لتشير إلى نجاحنا في إنشاء أول مشروع في Django.

سنعرض في هذا الدرس كيفية تثبيت إطار عمل Laravel وطريقة إعداده ثم نكتشف المجلدات المكوِّنة للإطار. هذا الدرس جزء من سلسلة تعلم Laravel والتي تنتهج مبدأ "أفضل وسيلة للتعلم هي الممارسة"، حيث ستكون ممارستنا عبارة عن إنشاء تطبيق ويب للتسوق مع ميزة سلة المشتريات. يتكون فهرس السلسلة من التالي: مدخل إلى Laravel 5. تثبيت Laravel وإعداده على كلّ من Windows وUbuntu. (هذا الدرس) أساسيات بناء تطبيق باستخدام Laravel. إنشاء روابط محسنة لمحركات البحث (SEO) في إطار عمل Laravel. نظام Blade للقوالب. تهجير قواعد البيانات في Laravel. استخدام Eloquent ORM لإدخال البيانات في قاعدة البيانات، تحديثها أو حذفها. إنشاء سلة مشتريات في Laravel. الاستيثاق في Laravel. إنشاء واجهة لبرمجة التطبيقات API في Laravel. إنشاء مدوّنة باستخدام Laravel. استخدام AngularJS واجهةً أمامية Front end لتطبيق Laravel. الدوّال المساعدة المخصّصة في Laravel. استخدام مكتبة Faker في تطبيق Laravel لتوليد بيانات وهمية قصدَ الاختبار. يتكون جانب التثبيت في هذا الدرس من جزأين، الأول لنظام تشغيل وندوز وسيكون الاعتماد فيه على برنامج Laragon؛ أما الجزء الثاني فهو موجَّه لتوزيعة لينكس Ubuntu 14.04. وقع الاختيار على Laragon لسهولة العمل عليه إذ يأتي مضمَّنا بإطار عمل Laravel ولا يتطلب سوى إعدادات يسيرة، كما أنه يوفر واجهة أوامر Shell تتيح تنفيذ بعض أوامر Linux. يغطي الدرس المواضيع التالية: متطلبات تثبيت Laravel تثبيت Laravel باستخدام Composer التحقق من نجاح تثبيت Laravel بنية المجلدات في Laravel إعداد مشروع عمل جديد في Laravel متطلبات تثبيت Laravel يجب قبل البدء في تثبيت Laravel التأكد من توفر العناصر التالية: خادوم ويب (Apache). الإصدار 5.5.9 من PHP لتثبيت الإصدار 5.2 من Laravel. قاعدة بيانات (MySQL). أداة Composer. تفعيل الوحدات المطلوبة على كلّ من PHP (وهيّ OpenSSL، PDO ،Mbstring وTokenizer) وتعليمة mod_rewrite على Apache . بيئة تطوير IDE (اختياري). تتناول الفقرات التالية آلية تثبيت هذه العناصر على كل من نظام تشغيل Windows و توزيعة Ubuntu 14.04. ملحوظة: سنعتمد في هذه السلسلة على الإصدار 5.2 من إطار العمل Laravel. قد توجد اختلافات طفيفة مع الإصدارات اللاحقة؛ إلا أن المبدأ العام هو نفسه. تهيئة بيئة العمل على Windows توجد برامج عدة تمكن من الحصول على بيئة تطوير Apache PHP MySQL على Windows ومن أشهرها XAMPP وWAMP. يوجد أيضا خيار آخر وهو برنامج Laragon الذي يتضمن خدمات أخرى إضافة للثلاثة المذكورة، من بينها أداة Composer لإدارة الاعتماديات Dependencies والتي تسهل من تثبيت Laravel وإنشاء مشاريع تعمل عليه كما سنرى لاحقا. تثبيت Laragon نبدأ بتنزيل برنامج Laragon من الموقع الرسمي ثم تثبيته. اختر أثناء التثبيت مجلد عمل Laragon: سيقترح عليك المثبِّت تفعيل إنشاء المضيفات الافتراضية Virtual hosts تلقائيا. تمكّن هذه الميزة من إنشاء مضيف افتراضي لكل مجلد يُنشأ ضمن أصل المستند Document root (أي \C:\laragon\www في حالتنا). يعني هذا أنه عند إنشاء مجلد باسم wordpress على المسار \C:\laragon فإن مضيفا افتراضيا باسم wordpress.dev يحيل إلى هذا المجلد سيُعد تلقائيا. نكمل عملية التثبيت: بإكمال تثبيت Laragon نكون قد ثبّتنا كلّا من خادوم ويب Apache، قاعدة بيانات MySQL وأداة إدارة الاعتماديات Composer. نشغل الخدمات بالضغط على زر Start All. تظهر الخدمات المشغَّلة (خادوم ويب Apache وقاعدة بيانات MySQL) في الواجهة الرئيسية للبرنامج. يمكننا الآن إنشاء مشروع Laravel للعمل عليه. سنستخدم سطر الأوامر لهذا الغرض. توجد إمكانية إنشاء مشروع من واجهة البرنامج بالذهاب إلى قائمة: Menu -> Laravel -> Create project -> Laravel 5 اضغط على زر Shell لإظهار سطر الأوامر. تبدو واجهة سطر الأوامر على النحو التالي: إنشاء مشروع Laravel باستخدام أداة Composer تُستخدَم أداة Composer لإدارة الاعتماديات في برمجيات PHP. يقوم مبدأ عملها على التصريح بالمكتبات والعناصر اللازمة للمشروع وستتولى الأداة تثبيتها وإدارة تحديثاتها. اكتب الأمر التالي في نافذة سطر الأوامر: composer create-project --prefer-dist laravel/laravel larashop "5.2.*" ستحصُل على مخرجات مشابهة لما يلي: ننتظر اكتمال تثبيت Laravel وإنشاء مشروع larashop: يثبت الأمر السابق Laravel وينشئ مشروع Laravel باسم larashop في المجلد \C:\laragon\www الذي هو أصل المستند. ملحوظة: إذا كان إصدار Composer المضمّن في Laragon قديما فسيظهر لديك تحذير - قد يكون مصحوبا بخطأ في التثبيت - عند تنفيذ أمر Composer. للتخلّص من هذا التحذير، وتجاوز الخطأ، حدّث Composer بتنفيذ الأمر أدناه في نافذة سطر الأوامر: composer self-update نفعّل بعد اكتمال تثبيت Laravel وإنشاء مشروع larashop، خدمة PHP Server على المنفذ 8000 في واجهة Laragon بالذهاب إلى القائمة Menu ثم خيار Preferences ثم تبويب Services & Ports ثم التأشير على الصندوق المناسب كما في الصورة أدناه. ستلاحظ ظهور سطر جديد في واجهة البرنامج باسم الخدمة التي فعّلناها للتو. اختبار التثبيت يمكننا الآن التحقق من أن كل شيء جرى على ما يُرام؛ إما بالذهاب إلى واجهة Laragon ثم اختيار: Menu -> www -> larashop أو إدخال المسار التالي في شريط عنوان المتصفح: http://localhost/larashop/public/ أو اسم المضيف التالي (إن كنت تركت خيار إنشاء المضيفات الافتراضية تلقائيا أثناء تثبيت Laragon): http://larashop.dev يجب أن تظهر صفحة الويب التالية في المتصفّح دلالة على أن كل شيء وُضع في مكانه الصحيح: تهيئة بيئة العمل الخاصة بـLaravel على لينكس يتلخّص إعداد بيئة العمل الخاصة بـLaravel على لينكس بالخطوات التاليّة. تثبيت Apache، PHP وMySQL نبدأ بتثبيت حزم LAMP على أوبنتو. توجد خطوات التثبيت بالتّفصيل في درس كيف تُثبِّت حِزم MySQL، Apache، Linux :LAMP وPHP على Ubuntu 14.04. نشير هنا إلى أن الإصدر الموجود في المستودعات الرسمية لأوبنتو (5.6.11 أثناء كتابة هذه السطور) يفي بالمتطلبات (5.5.9 فما فوق). تثبيت المتطلبات الأخرى تثبَّت بعض الوحدات المطلوبة لتشغيل Laravel تلقائيا عند تثبيت PHP، في ما تحتاج أخرى لتثبيتها وتفعيلها. يثبت الأمر التالي هذه الوحدات وأدوات إضافية أخرى: sudo apt-get install -y php5-json openssl php5-mcrypt curl git-core أضفنا حزمتي curl و git-core التين تحتاجهما أداة Composer لتنزيل أرشيف Laravel إلى أمر التثبيت. نفعّل وحدة mcrypt على PHP: sudo php5enmod mcrypt نفعّل كذلك تعليمة mod_rewrite على خادوم ويب Apache: sudo a2enmod rewrite نعيد تشغيل خادوم الويب لاعتماد التعديلات: sudo service apache2 restart تثبيت Composer وإعداده نفذ الأمر التالي لتنزيل أداة Composer وتثبيتها: curl -sS https://getcomposer.org/installer | php نغيّر مكان الأداة ليصبح تنفيذها ممكنا دون الحاجة لذكر المسار الكامل للملف: sudo mv composer.phar /usr/local/bin/composer ثم نتأكد من سلامة تثبيت الأداة: composer يجب أن تشبه النتيجة ما يلي: تثبيت Laravel يمكننا الآن تنفيذ الأمر التالي لتثبيت Laravel باستخدام Composer: sudo composer create-project --prefer-dist laravel/laravel /var/www/html/larashop "5.2.*" يثبت الأمر Laravel (الإصدار 5.2) وينشئ مشروعا على المسار /var/www/html/larashop/. ننتظر حتى اكتمال التثبيت ثم نجعل الحساب الخاص بخادوم الويب مالكَ مجلد المشروع ونعطي إذن الكتابة لجميع المستخدمين حتى نتمكن من التعديل على ملفات المشروع: sudo chown -R www-data:www-data /var/www/html/larashop sudo chmod -R 777 /var/www/html/larashop الخطوة الأخيرة هي نقل ملكية المجلد composer./~ إلى المستخدم الحالي: sudo chown -R $USER $HOME/.composer عند الذهاب الآن إلى العنوان http://localhost/larashop/public/ ستظهر الشاشة التالية دلالة على نجاح عملية التثبيت: إنشاء مضيف افتراضي نقدم هنا باختصار طريقة إنشاء مضيف افتراضي Virtual host بحيث يمكننا الوصول إلى واجهة Laravel بكتابة اسم المضيف (اخترنا larashop.dev اسما للمضيف) فقط في المتصفح. للمزيد حول المضيفات الافتراضية راجع هذا الدرس. نفذ الأمر التالي: /etc/apache2/sites-available/larashop.dev.conf أضف المحتوى: <VirtualHost *:80> ServerName larashop.dev DocumentRoot /var/www/html/larashop/public/ <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/html/larashop/> AllowOverride All </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log LogLevel warn CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost> أضف اسم المضيف إلى خادوم الويب: sudo a2ensite larashop.dev عطل اسم المضيف الافتراضي: sudo a2dissite 000-default أعد تحميل إعدادات Apache: sudo service apache2 reload افتح ملف المضيفات لتحريره: sudo nano /etc/hosts أضف السطر التالي مباشرة بعد السطر الأخير من الأسطر التي تبدأ بـ127.X.X.X: 127.0.1.1 larashop.dev يمكن الآن الوصول إلى واجهة Laravel الأمامية بالذهاب إلى العنوان larashop.dev في المتصفح. بنية مجلدات Laravel يلخص الجدول التالي أهم مجلدات Laravel التي تجب عليك معرفتها. app: يحتوي على الشفرة المصدرية للتطبيق. app/console: توجد أوامر artisan هنا. app/events: يحتوي على أصناف Classes الأحداث Events. app/exceptions: الأصناف التي تتعامل مع الاستثناءات Exceptions. app/Http: تحتوي على الأصناف الخاصة بالمتحكِّمات Controllers، المُرشِحات Filters والطلبات Requests. app/jobs: يحتوي هذا المجلد على الأشغال Jobs التي تمكن إضافتها إلى قائمة الانتظار Queue. app/listeners: يحتوي على الأصناف التي تعالج الأحداث. bootstrap: توجد هنا الأصناف التي يحتاجها إطار عمل Bootstrap. config: يحتوي هذا المجلد على ملفات الإعداد. database: توجد في المجلد أصناف التهجير Migration والبذر Seed الخاصتين بقاعدة البيانات. كما يحتوي المجلد على قاعدة بيانات SQLite. public: يحتوي على متحكمات الواجهة الأمامية للتطبيق وموارد أخرى مثل الصور، ملفات CSS، Javascript وغيرها. resources: يحوي العروض Views وملفات التوطين Localization. storage: يحتوي على قوالب blade المجمّعة Compiled، حقول الجلسات Sessions وأمور أخرى. tests: توجد به الاختبارات الأحادية Unit tests. vendor: يحتوي على اعتماديات Composer. إعداد مشروع Laravel جديد إعداد التطبيق توجد معلومات إعداد التطبيق في الملف config/app.php/ سنرى في هذه الفقرة: ضبط وضع التنقيح Debugging mode: يُستخدم وضع التنقيح لتحديد مقدار المعلومات الواجب إظهارها عند حدوث أخطاء في التطبيق. ضبط المنطقة الزمنية Time zone: يستخدم PHP هذا الإعداد في دوالّ الوقت والتاريخ. مفتاح التطبيق Application key: تُستخدَم هذه القيمة في التعميّة Encryption. وضع التنقيح افتح الملف config/app.php/ واعثر على السطر التالي: 'debug' => env('APP_DEBUG', false), عدّل السطر بحيث يصبح على النحو التالي: 'debug' => env('APP_DEBUG', true), تفعلّ التعليمة ('debug' => env('APP_DEBUG', true وضع التنقيح بإعطاء القيمة true للمتغيّر APP_DEBUG؛ وهو ما يعني أن Laravel سيظهر معلومات مفصَّلة عند حدوث أخطاء. تفيد المعلومات المفصَّلة كثيرًا في البحث عن مشاكل في التطبيق ومن ثم تصحيحها. المنطقة الزمنية ابحث في نفس الملف عن السطر التالي: 'timezone' => 'UTC', تعطي هذه التعليمة القيمة الافتراضيّة UTC للمتغيّر timezone. تشير UTC إلى التوقيت العالميّ الموّحّد؛ يمكنك إبدالها بالقيمة الموافقة لمنطقتك الزمنيّة المفضّلة. مفتاح التطبيق اعثر على السطر التالي: 'key' => env('APP_KEY', 'SomeRandomString'), وضع سلسلة محارف String من اختيارك مكان SomeRandomString: 'key' => env('APP_KEY', 'ines5@dinemwa8aw3bambuyabakoiwe'), اخترنا سلسلة محارف عشوائية من 32 محرفا Characters لاستخدامها في التعميّة. إعدادات أخرى توجد الكثير من الإعدادات الأخرى التي يمكن اكتشافها بتصفح الملف config/app.php. إعداد الاستيثاق توجد إعدادات الاستيثاق ضمن الملف config/auth.php/. سنترك الإعدادات بقيمها الافتراضية، يمكنك تغييرها بما يوافق احتياجاتك. إعداد قاعدة البيانات يوجد إعداد قاعدة البيانات ضمن الملف config/database.php/؛ تُستخدم قاعدة بيانات MySQL افتراضيّا. يمكن تعديل الملف لاستخدام نظام إدارة قواعد بيانات مختلف. سنستخدم قاعدة بيانات MySQL في هذا الدليل ونغيّر بضعة إعدادات: اسم قاعدة البيانات database، اسم المستخدم username، كلمة سر المستخدم. ابحث عن الأسطر التالية في ملف إعداد قاعدة البيانات: 'mysql' => [ 'driver' => 'mysql', 'host' => env('DB_HOST', 'localhost'), 'database' => env('DB_DATABASE', 'forge'), 'username' => env('DB_USERNAME', 'forge'), 'password' => env('DB_PASSWORD', ''), 'charset' => 'utf8', 'collation' => 'utf8_unicode_ci', 'prefix' => '', 'strict' => false, ], حدّث القيم لتصبح على النحو التالي: 'mysql' => [ 'driver' => 'mysql', 'host' => env('DB_HOST', 'localhost'), 'database' => env('DB_DATABASE', 'larashop'), 'username' => env('DB_USERNAME', 'root'), 'password' => env('DB_PASSWORD', 'melody'), 'charset' => 'utf8', 'collation' => 'utf8_unicode_ci', 'prefix' => '', 'strict' => false, ], تعد التعليمة ('database' => env('DB_DATABASE', 'larashop', التطبيق لاستخدام قاعدة بيانات larashop. يمكنك الذهاب إلى MySQL وإنشاء قاعدة بيانات خاوية باسم larashop في MySQL. تضبط التعليمة ('username' => env('DB_USERNAME', 'root', التطبيق لاستخدام الحساب root للوصول إلى قاعدة البيانات. يجب أن تستخدم حساب مستخدم صالحا في MySQL. التعليمة المواليّة ('password' => env('DB_PASSWORD', 'melody', تحدد كلمة سر الحساب المستخدم في التعليمة السابقة. خاتمة رأينا في هذا الدرس كيفية تثبيت Laravel ثم بنية المجلدات الموجودة في إطار العمل وإعدادات أساسية لمشروع Laravel. الخطوة التاليّة ستكون إنشاء أول تطبيق في Laravel. ترجمة -وبتصرّف- لمقال Laravel 5 Installation and Configuration لصاحبه Rodrick Kazembe.

هذا هو الجزء الأخير من سلسلة “مدخل إلى إطار العمل Ruby on Rails” وفي هذا الجزء سنعيد هيكلة الشيفرة التي كتبناها في الأجزاء السابقة من السلسلة، وسنتعرّف إلى نظام الاستيثاق البسيط الذي يقدّمه إطار العمل Rails. إعادة هيكلة الشيفرة بعد أن أصبحت المقالات والتعليقات تعمل بصورة جيدة، لنلقِ نظرة على القالب app/views/articles/show.html.erb . يبدو الملف طويلًا جدًّا، لذا سنستخدم الملفات الجزئية لتنظيف وترتيب الشيفرة البرمجية. تصيير مجموعة الملفات الجزئية في البداية سننشئ ملفًّا جزئيًا خاصًّا بالتعليقات وظيفته عرض جميع التعليقات الخاصّة بالمقالة. أنشئ الملف app/views/comments/_comment.html.erb وأضف إليه الشيفرة التالية: <p> <strong>Commenter:</strong> <%= comment.commenter %> </p> <p> <strong>Comment:</strong> <%= comment.body %> </p> والآن يمكنك تعديل الملف `app/views/articles/show.html.erb` كما يلي: <p> <strong>Title:</strong> <%= @article.title %> </p> <p> <strong>Text:</strong> <%= @article.text %> </p> <h2>Comments</h2> <%= render @article.comments %> <h2>Add a comment:</h2> <%= form_for([@article, @article.comments.build]) do |f| %> <p> <%= f.label :commenter %><br> <%= f.text_field :commenter %> </p> <p> <%= f.label :body %><br> <%= f.text_area :body %> </p> <p> <%= f.submit %> </p> <% end %> <%= link_to 'Edit', edit_article_path(@article) %> | <%= link_to 'Back', articles_path %> بهذه الطريقة سيتم تصيير الملف الجزئي في app/views/comments/_comment.html.erb لكلّ تعليق موجود في مجموعة @article.comments، وعندما يتنقّل التابع render بين عناصر مجموعة التعليقات فإنه يُسند كل تعليق إلى متغيّر محلي local variable يحمل اسم الملف الجزئي ذاته، وفي حالتنا هذه comment والذي يكون متوفّرًا في الملف الجزئي. تصيير الملف الجزئي الخاصّ بالاستمارة لنقم بإزالة قسم التعليقات الجديد إلى ملف جزئي خاصّ به، ومرة أخرى أنشئ ملفًّا باسم _form.html.erb في المجلد app/views/comments/ وأضف إليه ما يلي: <%= form_for([@article, @article.comments.build]) do |f| %> <p> <%= f.label :commenter %><br> <%= f.text_field :commenter %> </p> <p> <%= f.label :body %><br> <%= f.text_area :body %> </p> <p> <%= f.submit %> </p> <% end %> ثم عدّل الملف app/views/articles/show.html.erb ليصبح بالصورة التالية: <p> <strong>Title:</strong> <%= @article.title %> </p> <p> <strong>Text:</strong> <%= @article.text %> </p> <h2>Comments</h2> <%= render @article.comments %> <h2>Add a comment:</h2> <%= render 'comments/form' %> <%= link_to 'Edit', edit_article_path(@article) %> | <%= link_to 'Back', articles_path %> يعرّف تابع render الثاني القالب الجزئي الذي نرغب في تصييره وهو comments/form، ونظرًا لوجود المحرّف / ضمن هذه السلسلة النصّية سيعرف Rails بأنّك ترغب في تصيير الملف _form.html.erb الموجود في المجلد app/views/comments. أما الكائن @article فسيكون متوفّرًا لأيّ ملفّ جزئي يتم تصييره في العرض لأنّنا عرّفناه كمتغيّر من نوع instance. حذف التعليقات إن القدرة على حذف التعليقات المزعجة هي من الميزات المطلوب توفرها في المدوّنة، ولتنفيذ ذلك سنحتاج إلى إضافة رابط لحذف التعليقات ضمن العرض وإلى حدث destroy في المتحكّم CommentsController. لذا سنضيف أوّلًا رابط الحذف ضمن الملفّ الجزئي app/views/comments/_comment.html.erb وكما يلي: <p> <strong>Commenter:</strong> <%= comment.commenter %> </p> <p> <strong>Comment:</strong> <%= comment.body %> </p> <p> <%= link_to 'Destroy Comment', [comment.article, comment], method: :delete, data: { confirm: 'Are you sure?' } %> </p> سيؤدّي النقر على هذا الرابط إلى إرسال الفعل DELETE متمثّلًا بالرابط /articles/:article_id/comments/:id إلى المتحكّم CommentsController، والذي سيبحث بدوره - مستعينًا بهذا الرابط - عن التعليق المراد حذفه من قاعدة البيانات. لنضِف حدث destroy إلى المتحكّم في الملف app/controllers/comments_controller.rb: class CommentsController < ApplicationController def create @article = Article.find(params[:article_id]) @comment = @article.comments.create(comment_params) redirect_to article_path(@article) end def destroy @article = Article.find(params[:article_id]) @comment = @article.comments.find(params[:id]) @comment.destroy redirect_to article_path(@article) end private def comment_params params.require(:comment).permit(:commenter, :body) end end سيبحث الحدث destroy عن التعليق المراد حذفه، ثم يعيّن موقعه في مجموعة @article.comments ثم يحذفه من قاعدة البيانات ويعيد توجيهنا إلى حدث show الخاصّ بالمقالة. حذف الكائنات المترابطة من البديهي أنّه عند حذف مقالة معيّنة فإن من الواجب أن يتم حذف التعليقات المرتبطة بها، وإلا فستشغل هذه التعليقات مساحة ضمن قاعدة البيانات دون أيّ فائدة. يتيح لنا Rails استخدام الخيار dependent لتحقيق ذلك. توجّه إلى نموذج Article (app/models/article.rb) وعدّله بالصورة التالية: class Article < ApplicationRecord has_many :comments, dependent: :destroy validates :title, presence: true, length: { minimum: 5 } end الاستيثاق Authentication في Rails إن كنت ترغب في نشر المدوّنة على الإنترنت، سيكون بإمكان أي شخص إضافة وتعديل وحذف المقالات والتعليقات فيها. يقدّم Rails نظام استيثاق HTTP بسيط يمكن استخدامه في التطبيقات البسيطة كتطبيقنا هذا. سنحتاج في المتحكّم ArticlesController إلى وسيلة لمنع وصول الشخص غير المستوثق منه إلى الأحداث التي يتضمّنها هذا المتحكّم، ويمكن استخدام تابع http_basic_authenticate_with لتحقيق ذلك. ولاستخدام نظام الاستثياق سنقوم بالإفصاح عنه في بداية ملف المتحكّم ArticlesController in app/controllers/articles_controller.rb وسنستوثق من جميع الأحداث المتوفّرة في هذا المتحكّم عدا حدثي index وshow: class ArticlesController < ApplicationController http_basic_authenticate_with name: "dhh", password: "secret", except: [:index, :show] def index @articles = Article.all end # بقيّة الشيفرة ... كذلك سنسمح للمستخدمين المستوثق منهم فقط بحذف التعليقات، لذا أضف الشيفرة التالية إلى المتحكّم CommentsController في الملف app/controllers/comments_controller.rb: class CommentsController < ApplicationController http_basic_authenticate_with name: "dhh", password: "secret", only: :destroy def create @article = Article.find(params[:article_id]) # ... end # بقيّة الشيفرة ... والآن إن حاولت إنشاء مقالة جديدة، ستتلقّى طلب استيثاق كهذا: جدير بالذكر أنّ هناك العديد من وسائل الاستيثاق في تطبيقات Rails، أشهرها Devise rails engine و Authlogic. إطار العمل Rails ونظام الترميز UTF-8 إن أسهل طريقة للعمل مع Rails هي تخزين جميع البيانات الخارجية بنظام الترميز UTF-8، وإن لم تفعل ذلك فغالبًا ما تقوم مكتبات Ruby وإطار العمل Rails بتحويل البيانات الأصلية إلى هذا الترميز، ولكن لا يمكن الاعتماد على هذه المكتبات بصورة تامّة، ويفضّل التأكد من أنّ جميع البيانات الخارجية مرمّزة بهذا النظام. وفي حال حدوث أي خطأ في نظام الترميز فإن الحروف ستظهر في المتصفّح غالبًا على هيئة أشكال معينية سوداء بداخلها علامة استفهام، أو قد تظهر الحروف على هيئة رموز غريبة كأن يظهر الرمز “ü” بدلاً من الحرف “ü”. يتّخذ Rails بعض الإجراءات في نظامه الداخلي للتقليل من المسبّبات الشائعة لهذه المشاكل والتي يمكن الكشف عنها وتصحيحها بصورة تلقائية. ولكن، إن كنت تتعامل مع بيانات من مصادر خارجية غير مخزّنة بترميز UTF-8، لن يكون Rails قادرًا على الكشف بصورة تلقائية عن أسباب المشكلة أو تقديم حلّ لها. وهناك مصدران شائعان للبيانات غير المخزّنة بترميز UTF-8: محرر النصوص: تحفظ معظم محرّرات النصوص الملفات البرمجية بصيغة UTF-8، وإن لم يقم محرّر النصوص الذي تستخدمه في كتابة الشيفرات البرمجية بذلك، فقد ينتج عن ذلك تحوّل الحروف الخاصّة أو حروف اللغات الأخرى غير الإنكليزية إلى التحول في المتصفّح إلى أشكال معينية بداخلها علامة استفهام. ينطبق هذا الأمر كذلك على ملفات الترجمة i18n. تجدر الإشارة إلى أنّه تتيح معظم محررات النصوص التي لا تحفظ الملفات البرمجية بهذا الترميز افتراضيًّا (مثل Dreamweaver) إمكانية تغيير الترميز الافتراضي للملفات المحفوظة إلى نظام UTF-8، وننصح بالقيام بذلك. قاعدة البيانات: يحوّل Rails البيانات القادمة من قاعدة البيانات إلى ترميز UTF-8، ولكن إن لم يكن هذا نظام الترميز هذا مستخدمًا من طرف قاعدة البيانات فلن يكون بالإمكان تخزين جميع المحارف المدخلة من قبل المستخدم. فعلى سبيل المثال، إن كان نظام الترميز الداخلي لقاعدة البيانات هو Latin-1 وأدخل المستخدم كلمات باللغة الروسية أو العربية أو اليابانية، فستخسر البيانات إلى الأبد بمجرد دخولها إلى قاعدة البيانات. لذا ينصح دائمًا بتحويل نظام الترميز الداخلي في قاعدة البيانات إلى نظام UTF-8. المصدر: توثيقات Ruby on Rails.

تحدّثنا في الجزء السابق من هذه السلسلة عن النماذج في إطار العمل Ruby on Rails وتعرّفنا على طريقة إنشائها والتعامل معها من خلال كتابة الشيفرة المسؤولة عن حفظ المقالة الجديدة في قاعدة البيانات. في الجزء الثاني من هذا الموضوع سنتعلّم كيفية ربط نموذجين مع بعضهما البعض من خلال إنشاء نموذج جديد خاصّ بالتعليقات. ولكن قبل ذلك سنكمل ما بدأناه في الدروس السابقة من السلسلة في بناء عمليات “CRUD” حيث غطّينا سابقًا عمليتي الإنشاء Create و القراءة Read، وسنغطي اليوم العمليتين المتبقّيتين وهما التحديث Update والحذف Destroy. تحديث المقالات الخطوة الأولى في عملية تحديث المقالات هي إضافة حدث edit إلى المتحكم ArticlesController بين حدثي new و create وكما يلي: def new @article = Article.new end def edit @article = Article.find(params[:id]) end def create @article = Article.new(article_params) if @article.save redirect_to @article else render 'new' end end سيتضمن العرض استمارة مشابهة لتلك التي استخدمناها في إنشاء المقالات الجديدة. أنشئ ملفًّا باسم app/views/articles/edit.html.erb وأضف إليه الشيفرة التالية: <h1>Edit article</h1> <%= form_for(@article) do |f| %> <% if @article.errors.any? %> <div id="error_explanation"> <h2> <%= pluralize(@article.errors.count, "error") %> prohibited this article from being saved: </h2> <ul> <% @article.errors.full_messages.each do |msg| %> <li><%= msg %></li> <% end %> </ul> </div> <% end %> <p> <%= f.label :title %><br> <%= f.text_field :title %> </p> <p> <%= f.label :text %><br> <%= f.text_area :text %> </p> <p> <%= f.submit %> </p> <% end %> <%= link_to 'Back', articles_path %> سنوجّه الاستمارة هذه المرة إلى حدث update والذي لم نقم بتعريفه حتى الآن. يؤدي تمرير كائن المقالة للتابع إلى إنشاء عنوان url لإرسال استمارة المقالة التي تم تعديلها، ومن خلال هذا الخيار نخبر Rails بأنّنا نرغب في أن يتم إرسال هذا النموذج من خلال فعل HTTP PATCH وهو أحد أفعال HTTP التي تستخدم في تحديث الموارد حسب بروتوكول REST. يمكن أن يكون المعامل الأول لـ form_for كائنًا، مثلًا @articl، والذي سيؤدي بالدالة المساعدة إلى ملء الاستمارة بالحقول التابعة للكائن، ويؤدي تمرير الرمز (:article) بنفس اسم المتغيّر من نوع instance (@article) إلى نفس النتيجة تلقائيًا. والآن سنقوم بإنشاء الحدث update في المتحكّم app/controllers/articles_controller.rb وسنضيفه بين حدث create والتابع ذي المحدّد الخاصّ private: def create @article = Article.new(article_params) if @article.save redirect_to @article else render 'new' end end def update @article = Article.find(params[:id]) if @article.update(article_params) redirect_to @article else render 'edit' end end private def article_params params.require(:article).permit(:title, :text) end يستخدم الحدث update عندما ترغب في تحديث سجل موجود في قاعدة البيانات، ويستقبل هذا الحدث جدول تقطيع hash يحتوي الخصائص التي ترغب في تحديثها. وكما سبق، في حال وجود خطأ في عملية التحديث سنعرض الاستمارة على المستخدم من جديد. سنستخدم التابع article_params الذي عرّفناه في وقت سابق للحدث create. لا حاجة لتمرير جميع الخصائص لغرض تحديثها، فعلى سبيل المثال، إن تم استدعاء @article.update(title: 'A new title') فسيقوم Rails بتحديث خاصية العنوان فقط، ويترك باقي الخصائص دون تعديل. أخيرًا، نرغب في عرض رابط إلى الحدث edit في الصفحة التي نعرض فيها قائمة المقالات، لذا توجّه إلى الملف app/views/articles/index.html.erb وأضف الرابط ليظهر إلى جانب رابط “Show”: <table> <tr> <th>Title</th> <th>Text</th> <th colspan="2"></th> </tr> <% @articles.each do |article| %> <tr> <td><%= article.title %></td> <td><%= article.text %></td> <td><%= link_to 'Show', article_path(article) %></td> <td><%= link_to 'Edit', edit_article_path(article) %></td> </tr> <% end %> </table> سنضيف كذلك رابطًا إلى قالب app/views/articles/show.html.erb ليظهر رابط “Edit” في صفحة المقالة أيضًا: ... <%= link_to 'Edit', edit_article_path(@article) %> | <%= link_to 'Back', articles_path %> هذا هو شكل تطبيقنا حتى هذه اللحظة: استخدام الملفات الجزئية partials لإزالة التكرار من العروض تبدو صفحة تحرير المقالة مشابهة تمامًا لصفحة إنشاء مقالة جديدة، وفي الواقع تستخدم الصفحتان الشيفرة ذاتها لعرض الاستمارة. سنقوم الآن بالتخلص من هذا التكرار باستخدام ملفات العرض الجزئية. تحمل هذه الملفات أسماء تبدأ بالمحرف (_). أنشئ ملفًّا جديدًا باسم _form.html.erb ضمن المسار app/views/articles/ وأضف إليه الشيفرة التالية: <%= form_for @article do |f| %> <% if @article.errors.any? %> <div id="error_explanation"> <h2> <%= pluralize(@article.errors.count, "error") %> prohibited this article from being saved: </h2> <ul> <% @article.errors.full_messages.each do |msg| %> <li><%= msg %></li> <% end %> </ul> </div> <% end %> <p> <%= f.label :title %><br> <%= f.text_field :title %> </p> <p> <%= f.label :text %><br> <%= f.text_area :text %> </p> <p> <%= f.submit %> </p> <% end %> لاحظ أننا لم نغيّر شيئًا باستثناء الإعلان عن التابع form_for وسبب استخدام هذه الأسلوب المختصر والبسيط في الإعلان عن التابع form_for للتعبير عن الاستمارتين هو أن @article عبارة عن مورد يرتبط بمجموعةٍ من مسارات RESTful، وبإمكان Rails أن يخمّن عنوان URI والتابع الذي يجب استخدامه. والآن لنقم بتحديث العرض app/views/articles/new.html.erb لاستخدام الملف الجزئي الذي أنشأناه وسنقوم بإعادة كتابة العرض من جديد وكما يلي: <h1>New article</h1> <%= render 'form' %> <%= link_to 'Back', articles_path %> ثم قم بالأمر عينه في ملف العرض app/views/articles/edit.html.erb: <h1>Edit article</h1> <%= render 'form' %> <%= link_to 'Back', articles_path %> حذف المقالات هذه هي العملية الأخيرة ضمن عمليات CRUD، وبحسب معايير REST فإن المسار الذي يؤدي إلى حذف المقالات وكما يظهر في مخرجات الأمر bin/rails routes هو: DELETE /articles/:id(.:format) articles#destroy يجب استخدام الفعل DELETE في المسار المسؤول عن حذف الموارد، أما في حال استخدام الفعل GET فسيكون بالإمكان إنشاء رابط خبيث كهذا الرابط مثلًا: <a href='http://example.com/articles/1/destroy'>look at this cat!</a> سنستخدم التابع delete لحذف المصادر، وهذا المسار مرتبط بالحدث destroy ضمن المتحكّم app/controllers/articles_controller.rb والذي لم نقم بإنشائه بعد. عادة ما يكون التابع destroy التابع الأخير ضمن المتحكّم، وكما هو الحال مع بقية التوابع العامّة public يجب الإعلان عنه قبل أي توابع خاصّة أو محميّة protected. def destroy @article = Article.find(params[:id]) @article.destroy redirect_to articles_path end الصورة النهائية للمتحكّم ArticleController في الملف app/controllers/articles_controller.rb هي: class ArticlesController < ApplicationController def index @articles = Article.all end def show @article = Article.find(params[:id]) end def new @article = Article.new end def edit @article = Article.find(params[:id]) end def create @article = Article.new(article_params) if @article.save redirect_to @article else render 'new' end end def update @article = Article.find(params[:id]) if @article.update(article_params) redirect_to @article else render 'edit' end end def destroy @article = Article.find(params[:id]) @article.destroy redirect_to articles_path end private def article_params params.require(:article).permit(:title, :text) end end يمكن استدعاء التابع destroy في كائنات التسجيلة النشطة Active Record عندما ترغب في حذفها من قاعدة البيانات. لاحظ أنّنا لسنا بحاجة لإضافة عرض خاص بهذا الحدث لأنّنا نعيد توجيه المستخدم إلى الحدث index. أخيرًا أضف رابط ‘Destroy’ إلى القالب app/views/articles/index.html.erb لنربط كل الصفحات مع بعضها البعض. <h1>Listing Articles</h1> <%= link_to 'New article', new_article_path %> <table> <tr> <th>Title</th> <th>Text</th> <th colspan="3"></th> </tr> <% @articles.each do |article| %> <tr> <td><%= article.title %></td> <td><%= article.text %></td> <td><%= link_to 'Show', article_path(article) %></td> <td><%= link_to 'Edit', edit_article_path(article) %></td> <td><%= link_to 'Destroy', article_path(article), method: :delete, data: { confirm: 'Are you sure?' } %></td> </tr> <% end %> </table> استخدمنا هنا التابع link_to بطريقة مختلفة، حيث مررّنا اسم المسار كمعامل ثانٍ، ثمّ مرّرنا الخيارات الأخرى بعد ذلك. تستخدم الخيارات method: :delete وdata: { confirm: 'Are you sure?' } كخصائص HTML5 بحيث يؤدي الضغط على الرابط إلى عرض مربع حوار للتأكد من رغبة المستخدم في حذف المقالة، ثم إرسال الرابط باستخدام التابع delete. تتمّ تعملية التحقّق هذه بواسطة ملف JavaScript الذي يحمل الاسم rails-ujs والموجود بصورة افتراضية في مخطط التطبيق (app/views/layouts/application.html.erb)، وفي حال عدم وجود هذا الملف لن يظهر مربع الحوار التأكيدي للمستخدم. تهانينا أصبح بإمكانك الآن إنشاء وعرض وسرد وتحديث وحذف المقالات في مدوّنتك. إضافة النموذج الخاصّ بالتعليقات سنقوم الآن بإنشاء نموذج جديد في تطبيقنا هذا ستكون وظيفته التعامل مع التعليقات. إنشاء النموذج لإنشاء النموذج الخاص بالتعليقات سنتبع الأسلوب السابق نفسه وذلك باستخدام أداة المولّد لإنشاء نموذج يحمل الاسم Comment ويمثّل مرجعًا إلى المقالة. اكتب الأمر التالي في سطر الأوامر: $ bin/rails generate model Comment commenter:string body:text article:references سينشئ هذا الأمر أربعة ملفات: الملف Purpose الملف/المجلد الوظيفة db/migrate/20140120201010_create_comments.rb ملف التهجير المسؤول عن إنشاء جدول التعليقات في قاعدة البيانات (سيحمل اسم الملف لديك ختمًا زمنيًا مختلفًا) app/models/comment.rb النموذج الخاص بالتعليقات test/models/comment_test.rb ملف الاختبارات الخاص بنموذج التعليقات test/fixtures/comments.yml نماذج تعليقات تستخدم في إجراء الاختبارات لنلق نظرة في البداية على ملف app/models/comment.rb: class Comment < ApplicationRecord belongs_to :article end كما تلاحظ فمحتوى هذا الملف مشابه لنموذج Article الذي أنشأناه سابقًا، والفارق الوحيد هو السطر belongs_to :article والذي ينشئ رابطًا بين النموذجين، وسنتحدّث عن الروابط بعد قليل. أما الكلمة المفتاحية (:references) ضمن الأمر الذي قمنا بتنفيذه في سطر الأوامر، فهي نوع خاص من البيانات بالنسبة للنماذج. تنشئ هذه الكلمة المفتاحية عمودًا في الجدول الموجود في قاعدة البيانات يحمل اسم النموذج الذي تمّ تمريره إلى هذه الكلمة مع إضافة _id والذي يمثّل عددًا صحيحًا. ستتضح الأمور أكثر بالنسبة إليك إن تفحّصت ملف db/schema.rb أدناه. قام Rails - بالإضافة إلى إنشاء النموذج - بإنشاء تهجير وظيفته إنشاء الجدول المقابل للنموذج في قاعدة البيانات: class CreateComments < ActiveRecord::Migration[5.0] def change create_table :comments do |t| t.string :commenter t.text :body t.references :article, foreign_key: true t.timestamps end end end يُنشئ السطر t.references عمودًا من نوع integer باسم article_id إضافة إلى فهرس index خاص بهذا العمود وقيد مفتاح خارجي Foreign Key Constraint والذي يشير إلى عمود id في جدول المقالات. والآن نفذ التهجير باستخدام الأمر التالي: $ bin/rails db:migrate ينفّذ Rails التهجيرات غير المنفّذة فقط؛ لذا ستكون نتيجة الأمر التالي كما يلي: == CreateComments: migrating ================================================= -- create_table(:comments) -> 0.0115s == CreateComments: migrated (0.0119s) ======================================== ربط النماذج مع بعضها البعض تسهّل روابط التسجيلة النشطة تكوين العلاقات بين النماذج، وفي حالتنا هذه سنُنشئ علاقة بين جدولي التعليقات والمقالات، ولو فكّرنا في طبيعة العلاقة التي تربط بينهما فسنجد أنه: ينتمي كل تعليق إلى مقالة واحدة. تمتلك المقالة الواحدة العديد من التعليقات. يستخدم Rails صياغة مشابهة للربط بين النماذج، وقد شاهدنا في نموذج Comment في الملف app/models/comment.rb الشيفرة المسؤولة عن ربط كل تعليق بمقالة واحدة: class Comment < ApplicationRecord belongs_to :article end سنحتاج الآن إلى تكوين الجانب الثاني من الرابطة، أي ربط المقالات بالتعليقات، لذا توجّه إلى الملف app/models/article.rb وعدّله بالصورة التالية: class Article < ApplicationRecord has_many :comments validates :title, presence: true, length: { minimum: 5 } end والآن أصبح النموذجان مرتبطين مع بعضهما البعض تلقائيًا، فعلى سبيل المثال، في حال كان لدينا متغيّر @article والذي يمثّل مقالة معيّنة، يمكن استدعاء جميع التعليقات المرتبطة بتلك المقالة على هيئة مصفوفة وذلك من خلال @article.comments. إضافة مسار خاص بالتعليقات كما هو الحال مع متحكم welcome سنحتاج إلى إضافة مسار نحدّد من خلاله العنوان الذي نرغب في استخدامه لمشاهدة التعليقات؛ لذا افتح ملف config/routes.rb مرة أخرى، وعدّله كما يلي: resources :articles do resources :comments end بهذه الطريقة تصبح التعليقات بمثابة موارد مضمّنة في المقالات، وهذه الطريقة هي جزء من العلاقة الهرمية التي تنشأ بين المقالات والتعليقات. إنشاء المتحكّم الخاصّ بالتعليقات بعد أن انتهينا من إعداد النموذج، أصبح بإمكاننا الآن إنشاء المتحكّم الخاص بالتعليقات، وسنستخدم أداة المولّد كما فعلنا سابقًا: $ bin/rails generate controller Comments سينشئ هذا الأمر خمسة ملفات إضافة إلى مجلّد فارغ: الملف/المجلد الوظيفة app/controllers/comments_controller.rb المتحكّم الخاص بالتعليقات /app/views/comments يتم تخزين العروض الخاصّة بالتعليقات في هذا المجلد test/controllers/comments_controller_test.rb ملف الاختبار الخاصّ بالمتحكّم app/helpers/comments الملف الخاصّ بمساعد العرض app/assets/javascripts/comments.coffee ملف CoffeScript الخاصّ بالمتحكّم app/assets/stylesheets/comments.scss أوراق الأنماط المتتالية CSS الخاصّة بالمتحكّم كما هو الحال مع أي مدوّنة، فإن القرّاء سيكتبون تعليقاتهم بعد قراءة المقالة مباشرة، وبعد أن يرسلوا تعليقاتهم يتم توجيههم إلى صفحة عرض المقالة ليتمكّنوا من مشاهدة التعليقات. وستكون وظيفة المتحكّم CommentsController هي توفير التوابع اللازمة لإنشاء التعليقات وحذف التعليقات المزعجة حال وصولها. سنقوم أولًا بتعديل قالب عرض المقالات app/views/articles/show.html.erb لنتمكن من إضافة تعليق جديد: <p> <strong>Title:</strong> <%= @article.title %> </p> <p> <strong>Text:</strong> <%= @article.text %> </p> <h2>Add a comment:</h2> <%= form_for([@article, @article.comments.build]) do |f| %> <p> <%= f.label :commenter %><br> <%= f.text_field :commenter %> </p> <p> <%= f.label :body %><br> <%= f.text_area :body %> </p> <p> <%= f.submit %> </p> <% end %> <%= link_to 'Edit', edit_article_path(@article) %> | <%= link_to 'Back', articles_path %> ستضيف الشيفرة السابقة استمارة إلى صفحة عرض المقالات يمكن من خلالها إضافة تعليق جديد من خلال استدعاء الحدث create ضمن المتحكّم CommentsController. ويستخدم الاستدعاء form_for مصفوفة ستعمل على إنشاء مسار متداخل nested route مثل: /articles/1/comments. لنجرِ الآن التعديلات اللازمة على الحدث create في الملفّ app/controllers/comments_controller.rb: class CommentsController < ApplicationController def create @article = Article.find(params[:article_id]) @comment = @article.comments.create(comment_params) redirect_to article_path(@article) end private def comment_params params.require(:comment).permit(:commenter, :body) end end ستتعقّد الأمور هنا قليلًا وذلك بسبب التداخل nesting الحاصل بين المسارات، إذ في كل مرة يتمّ فيها طلب تعليق معيّن يجب أن يتابع ذلك الطلب المقالة التي يرتبط بها هذا التعليق، وبالتالي استدعاء التابع find في نموذج Article والمسؤول عن اختيار المقالة المطلوبة حسب المعرّف المحدّد في المسار. بالإضافة إلى ذلك، استفدنا من بعض التوابع التي تقدّمها عملية الربط بين النموذجين، فقد استخدمنا التابع create على @article.comments لإنشاء التعليق وحفظه، وسيؤدي هذا إلى ربط التعليق الجديد بالمقالة المحدّدة. وبعد إنشاء التعليق الجديد نعيد توجيه المستخدم إلى المقالة الأصلية باستخدام الدالة المساعد article_path(@article). وكما شاهدنا تستدعي هذه الدالة الحدث show ضمن المتحكّم ArticlesController والذي يعمل بدوره على تصيير القالب show.html.erb، وهو المكان الذي نرغب أن تظهر التعليقات فيه؛ لذا سنقوم بإجراء التعديلات اللازمة على الملف app/views/articles/show.html.erb. <p> <strong>Title:</strong> <%= @article.title %> </p> <p> <strong>Text:</strong> <%= @article.text %> </p> <h2>Comments</h2> <% @article.comments.each do |comment| %> <p> <strong>Commenter:</strong> <%= comment.commenter %> </p> <p> <strong>Comment:</strong> <%= comment.body %> </p> <% end %> <h2>Add a comment:</h2> <%= form_for([@article, @article.comments.build]) do |f| %> <p> <%= f.label :commenter %><br> <%= f.text_field :commenter %> </p> <p> <%= f.label :body %><br> <%= f.text_area :body %> </p> <p> <%= f.submit %> </p> <% end %> <%= link_to 'Edit', edit_article_path(@article) %> | <%= link_to 'Back', articles_path %> أصبح بإمكانك الآن إضافة المقالات والتعليقات إلى مدوّنتك وعرضها في الأماكن الصحيحة. في الدرس القادم سنكمل العمل على التعليقات، حيث سنستخدم الملفات الجزئية لترتيب القوالب أوّلًا، ثم نضيف إمكانية حذف التعليقات من قاعدة البيانات، وفي الختام سنتطرّق إلى عملية الاستيثاق Authentication بصورة سريعة ومبسّطة. المصدر: توثيقات Ruby on Rails.

تعرّفنا في الدرس السابق بإيجاز على طريقة عمل إطار العمل Ruby on Rails حيث تعرّفنا على المتحكّمات والعروض وبدأنا بإنشاء تطبيق المدوّنة البسيطة وأنشأنا في الدرس السابق الاستمارة الخاصة بإضافة مقالة جديدة، ولكن وصلنا إلى النقطة التي نحتاج فيها إلى تخزين المقالة في قاعدة البيانات، وهنا يأتي دور النماذج Models. تحمل النماذج في Rails اسمًا بصيغة المفرد في حين يحمل الجدول المرتبط بها في قاعدة البيانات اسمًا بصيغة الجمع. تتيح أداة المولّد generator في Rails إنشاء النماذج ويلجأ أغلب المطوّرين إلى هذه الأداة لإنشاء النماذج. لإنشاء نموذج جديد استخدم الأمر التالي في سطر الأوامر: $ bin/rails generate model Article title:string text:text من خلال هذه الأمر نخبر Rails بأننا نرغب في إنشاء نموذج باسم Article إلى جانب خاصّية title من نوع string، وخاصّية text من نوع text. تضاف هذه الخواص بصورة تلقائية إلى جدول المقالات في قاعدة البيانات ويتم ربطها بنموذج Article. ويستجيب Rails لهذا الأمر بإنشاء عدد من الملفات، وما يهمّنا منها الآن هما app/models/article.rb و db/migrate/20140120191729_create_articles.rb (لاحظ أن اسم الملف الثاني يختلف قليلًا عن هذا الاسم). الملف الثاني مسؤول عن إنشاء بنية قاعدة البيانات، وهو ما سنتحدث عنه بعد قليل. إجراء عملية التهجير Migration كما لاحظنا فإن الأمر bin/rails generate model قد أنشأ ملف تهجير لقاعدة البيانات داخل المجلد db/migrate. والتهجيرات هي عبارة عن أصناف مصمّمة لتسهيل عملية إنشاء الجداول في قواعد البيانات والتعديل عليها. يستخدم Rails أوامر rake لإجراء التهجيرات، ويمكن التراجع عن عملية التجهير بعد إجرائها على قاعدة البيانات. تتضمّن أسماء ملفات التهجير ختمًا زمنيًا لضمان معالجة هذه الملفات حسب التسلسل الزمني لإنشائها. لو ألقينا نظرة في ملف db/migrate/YYYYMMDDHHMMSS_create_articles.rb (تذكّر أن الملف عندك يحمل ختمًا زمنيًّا مختلفًا) فسنجد التالي: class CreateArticles < ActiveRecord::Migration[5.0] def change create_table :articles do |t| t.string :title t.text :text t.timestamps end end end ستنشئ عملية التهجير أعلاه تابعًا يحمل اسم `change` والذي يتم استدعاؤه عند إجراء عملية التهجير. حتى الحدث المُعرّف ضمن التابع قابل للتراجع، ما يعني أن Rails قادر على التراجع عن التغييرات الحاصلة من إجراء عملية التهجير في حال أردت ذلك في وقت لاحق. عند إجراء عملية التهجير هذه سيتم إنشاء جدول باسم `articles` يتضمن عمودًا من نوع `string` وآخر من نوع `text`، إضافة إلى عمودين للختم الزمني يمكن لـ Rails من خلالهما متابعة تواريخ إنشاء وتعديل المقالات. لتنفيذ عمية التهجير توجّه إلى سطر الأوامر ونفذ الأمر التالي: $ bin/rails db:migrate سينفّذ Rails أمر التهجير التالي وسيخبرك بإنشاء جدول Articles. == CreateArticles: migrating ================================================== -- create_table(:articles) -> 0.0019s == CreateArticles: migrated (0.0020s) ========================================= حفظ البيانات بواسطة المتحكّم سنعود الآن إلى المتحكّم ArticlesController، حيث سنعمل على تعديل الحدث create ليستخدم النموذج الجديد Article لحفظ البيانات في قاعدة البيانات. افتح الملف app/controllers/articles_controller.rb وعدّله بالصورة التالية: def create @article = Article.new(params[:article]) @article.save redirect_to @article end يمكن استحداث initialize كل نموذج في Rails مع الخصائص Attributes المرتبطة به، والتي يتم ربطها تلقائيًا مع الأعمدة المقابلة في قاعدة البيانات. وقد قمنا بذلك في السطر الأول في الحدث create (هل تذكر params[:article] والذي يضمّ الخصائص التي نريدها). بعد ذلك يمكن حفظ النموذج في قاعدة البيانات من خلال الدالة @article.save. وفي النهاية نعيد توجيه المستخدم إلى الحدث show الذي سنعرّفه في وقت لاحق. توجّه الآن إلى العنوان http://localhost:3000/articles/new وستتلقّى الخطأ التالي: يدعم Rails العديد من مزايا الأمان التي تساعد في كتابة تطبيقات أمينة، ونحن الآن نتعامل مع إحدى هذه المزايا. تدعى هذه الميزة بالمعاملات القوية strong parameters والتي تجبرنا على تحديد المعاملات المسموح بها في الأحداث الموجودة ضمن المتحكم. ما الفائدة من ذلك؟ صحيح أن القدرة على إضافة جميع المعاملات إلى النموذج دفعة واحدة وبصورة تلقائية يختصر الكثير من الجهد بالنسبة للمبرمج، إلا أنّ البرنامج يكون في هذه الحالة عرضة للاستخدامات الخبيثة. فماذا لو تمّ إنشاء طلب إلى الخادوم يتضمن استمارة إنشاء مقالة جديدة إضافة إلى حقول أخرى تحتوي على معلومات تضرّ بالتطبيق؟ سيتم إسناد المعلومات الإضافية بصورة شاملة “Mass Assignment” إلى النموذج ثم إلى قاعدة البيانات جنبًا إلى جنب مع البيانات الأصلية، وهذا قد يتسبب في تعطيل عمل برنامجك أو قد يحدث ما هو أسوأ من ذلك بكثير. يجب علينا إذًا تحديد المعاملات المسموح بإدخالها إلى النموذج، وفي حالتنا هذه سنسمح بإدراج معاملي title و text ونطلب توفّر قيم لهما. وللقيام بذلك عدّل السطر الأول من حدث create بالصورة التالية: @article = Article.new(params.require(:article).permit(:title, :text)) غالبًا ما يتمّ تحديد المعاملات المسموح بإدخالها إلى النموذج في تابع خاص ليصبح بالإمكان إعادة استخدامها بواسطة عدة أحداث في المتحكّم نفسه مثل حدثي create و update، إضافة إلى ذلك يكون هذا التابع خاصًّا وذلك باستخدام المحدّد private لضمان عدم إمكانية استدعائه من خارج السياق المقرّر له، وبالشكل التالي: def create @article = Article.new(article_params) @article.save redirect_to @article end private def article_params params.require(:article).permit(:title, :text) end عرض المقالات إن قمت بتعبئة استمارة المقالة الجديدة وإرسالها فستتلقّى خطأ مفاده عدم عثور Rails على الحدث show، لذا سنقوم بإنشاء هذا الحدث الآن. كما رأينا سابقًا في مخرجات الأمر bin/rails routes فإن مسار الحدث show هو: article GET /articles/:id(.:format) articles#show تعني الصيغة الخاصة :id أن هذا المسار يطلب وجود معامل :id والذي يمثّل في حالتنا هذه معرّف المقالة. وكما فعلنا سابقًا، يجب علينا إضافة الحدث show إلى ملف المتحكّم app/controllers/articles_controller.rb وتحديد العرض المرتبط به. عادة ما تأخذ أحداث CRUD في المتحكّمات الترتيب التالي: index, show, new, edit, create, update, destroy. ويمكن اتّباع الترتيب الذي يعجبك، ولكن تذكّر أن هذه التوابع هي توابع عامّة public، ويجب الإعلان عنها قبل الإعلان عن التوابع الخاصّة. سنضيف الآن الحدث show آخذين ما سبق بعين الاعتبار: class ArticlesController < ApplicationController def show @article = Article.find(params[:id]) end def new end # بقيّة الشيفرة ..... استخدمنا الدالة Article.find للبحث عن المقالة المطلوبة، وذلك بتمرير المعامل params[:id] للحصول على قيمة المعرّف من الطلب الذي أرسلته صفحة إنشاء مقالة جديدة. كذلك استخدمنا متغيّرًا من نوع instance (مسبوقًا بعلامة @) ليكون مرجعًا لكائن المقالة، وذلك لأنّ Rails يمرّر هذا النوع من المتغيّرات إلى العرض. أنشئ الآن ملفًّا جديدًا باسم show.html.erb في المسار app/views/articles/ وأضف إليه الشيفرة التالية: <p> <strong>Title:</strong> <%= @article.title %> </p> <p> <strong>Text:</strong> <%= @article.text %> </p> ستكون الآن قادرًا على إنشاء مقالة جديدة؛ لذا توجّه إلى العنوان http://localhost:3000/articles/new وجرّب إضافة مقالة جديدة. عرض قائمة بمقالات المدوّنة نحتاج الآن إلى عرض قائمة بجميع المقالات الموجودة في المدونة، وسيكون المسار المرتبط بهذا الحدث وبحسب مخرجات الأمر bin/rails routes كالتالي: articles GET /articles(.:format) articles#index أضف الحدث index المرتبط بهذا المسار إلى المتحكّم ArticlesController في الملف app/controllers/articles_controller.rb. من الممارسات الشائعة بين المطوّرين هو كتابة الحدث index في بداية المتحكّم: class ArticlesController < ApplicationController def index @articles = Article.all end def show @article = Article.find(params[:id]) end def new end # بقية الشيفرة ... بعدها أضف العرض الخاصّ بهذا الحدث والموجود في المسار app/views/articles/index.html.erb والذي يتضمّن الشيفرة التالية: <h1>Listing articles</h1> <table> <tr> <th>Title</th> <th>Text</th> </tr> <% @articles.each do |article| %> <tr> <td><%= article.title %></td> <td><%= article.text %></td> <td><%= link_to 'Show', article_path(article) %></td> </tr> <% end %> </table> توجّه الآن إلى العنوان http://localhost:3000/articles في المتصفّح وستشاهد قائمة بجميع المقالات التي أنشأتها مسبقًا. إضافة الروابط للتنقل بين صفحات المدوّنة أصبح بمقدورنا الآن إنشاء وعرض وسرد قائمة المقالات المتوفّرة في المدونة، ولكنّنا بحاجة إلى بعض الروابط التي تساعدنا في التنقل بين صفحات الموقع. افتح الملف app/views/welcome/index.html.erb وعدّله كما يلي: <h1>Hello, Rails!</h1> <%= link_to 'My Blog', controller: 'articles' %> التابع link_to هو أحد دوال العروض المساعدة والمضمّنة في Rails، ووظيفة هذا التابع إنشاء رابط تشعّبي بالاستناد إلى النصّ الذي نمرّره إليه، وهو في حالتنا هذه المسار الخاص بسرد قائمة المقالات. لنضف بعض الروابط إلى العروض الأخرى، ولنبدأ بإضافة رابط إنشاء مقالة جديدة إلى الملف app/views/articles/index.html.erb قبل وسم <table>: <%= link_to 'New article', new_article_path %> سيوجّه هذا الرابط المستخدم إلى الصفحة التي تتضمن استمارة إنشاء مقالة جديدة. سنضيف رابطًا آخر إلى الملفّ app/views/articles/new.html.erb بعد الاستمارة مباشرة، ليتمكن المستخدم من العودة إلى الصفحة الرئيسية: <%= form_for :article, url: articles_path do |f| %> ... <% end %> <%= link_to 'Back', articles_path %> وأخيرًا، سنضيف رابطًا إلى القالب app/views/articles/show.html.erb يوجّه المستخدم إلى الصفحة الرئيسية أيضًا، وبهذا يصبح بميسور من يستعرض مقالة معيّنة أن يرجع إلى الصفحة التي تعرض جميع المقالات: <p> <strong>Title:</strong> <%= @article.title %> </p> <p> <strong>Text:</strong> <%= @article.text %> </p> <%= link_to 'Back', articles_path %> التحقّق من المدخلات لو نظرت إلى النموذج الذي أنشأناه سابقًا فسترى أنّ الملف بسيطٌ للغاية: class Article < ApplicationRecord end لاحظ أنّ الصنف Article موروث من الصنف ApplicationRecord وهو بدوره موروث من الصنف ActiveRecord::Base والذي يتضمّن الكثير من الوظائف والإجراءات الخاصة بالنماذج، مثل عمليات CRUD البسيطة (Create, Read, Update, Destroy) والتحقّق من البيانات Validation، إضافة إلى عمليات البحث المعقّدة وربط النماذج المختلفة مع بعضها البعض. ويقدّم إطار العمل Rails توابع متعدّدة تساعد في التحقق من البيانات المرسلة إلى النموذج. افتح الملف app/models/article.rb وأضف إليه الشيفرة التالية: class Article < ApplicationRecord validates :title, presence: true, length: { minimum: 5 } end سيضمن هذا التغيير امتلاك كل مقالة جديدة في المدونة لعنوان يتألف من خمسة أحرف على الأقل. يتيح Rails التحقّق من أمور متنوّعة في النماذج، مثل التحقّق من وجود أو عدم تكرار الأعمدة والتحقّق من تنسيقها ووجود كائنات مرتبطة بها. لنجرّب الآن استدعاء الدالة @article.save في مقالة لا تمتلك عنوانًا وسنلاحظ أن الدالة ترجع القيمة false. لو عدنا إلى المتحكّم في الملف app/controllers/articles_controller.rb مرّة أخرى سنلاحظ بأنّنا لم نتحقّق من النتيجة التي ترجعها الدالة @article.save ضمن الحدث create. إن فشلت الدالة @article.save في أداء عملها، يجب أن نعيد المستخدم إلى استمارة إضافة مقالة جديدة، وللقيام بذلك عدّل حدثي new و create في الملف app/controllers/articles_controller.rb بالصورة التالية: def new @article = Article.new end def create @article = Article.new(article_params) if @article.save redirect_to @article else render 'new' end end private def article_params params.require(:article).permit(:title, :text) end سينشئ الحدث new متغيّرًا جديدًا من نوع instance يحمل الاسم @article وستتعرّف إلى سبب القيام بذلك بعد قليل. لاحظ أنّنا استخدمنا render داخل الحدث create بدلًا من redirect_to في حال إرجاع الدالة save للقيمة false. يستخدم التابع render لكي يتم تمرير الكائن @article إلى القالب الجديد عند تصييره. وعملية التصيير هذه تتم ضمن نفس الطلب الناتج من إرسال الاستمارة، في حين أن الدالة redirect_to تتسبّب في إرسال طلب آخر. الآن أعد تحميل الصفحة ذات العنوان http://localhost:3000/articles/new وحاول إضافة مقالة جديد دون عنوان، سترى بأنّ Rails يعيدك إلى صفحة الاستمارة، ولكن هذا ليس مفيدًا جدًّا. يجب إخبار المستخدم بحدوث خطأ ما، وللقيام بذلك عدّل الملف app/views/articles/new.html.erb للتحقّق من رسائل الخطأ: <%= form_for :article, url: articles_path do |f| %> <% if @article.errors.any? %> <div id="error_explanation"> <h2> <%= pluralize(@article.errors.count, "error") %> prohibited this article from being saved: </h2> <ul> <% @article.errors.full_messages.each do |msg| %> <li><%= msg %></li> <% end %> </ul> </div> <% end %> <p> <%= f.label :title %><br> <%= f.text_field :title %> </p> <p> <%= f.label :text %><br> <%= f.text_area :text %> </p> <p> <%= f.submit %> </p> <% end %> <%= link_to 'Back', articles_path %> تحقّقنا في البداية من وجود أي أخطاء من خلال @article.errors.any?، وفي حال وجودها نعرض قائمة الأخطاء المتوفّرة من خلال @article.errors.full_messages. تأخذ الدالة pluralize معاملين الأول رقمي والثاني نصّي. إن كان العدد أكبر من واحد تتحوّل السلسلة النصّية تلقائيًا إلى صيغة الجمع. إن سبب إضافة @article = Article.new إلى المتحكّم ArticlesController هو أنّنا لو لم نقم بذلك لأصبحت قيمة المتغيّر @articl هي nil، وسيؤدي الاستدعاء @article.errores.any? إلى إطلاق خطأ. يحيط Rails الحقول التي تحتوي على أخطاء بوسم <div> مع صنف CSS يحمل الاسم field_with_errors، ويمكنك تعريف صنف CSS هذا لتنسيق الحقول حسب الرغبة. والآن ستتلقّى رسالة خطا مرتّبة عندما تحاول حفظ مقالة لا تتضمن عنوانًا. في الدرس القادم سنواصل العمل على النموذج حيث سنكتب الشيفرة المسؤولة عن تعديل المقالات وحذفها، ثم سنتعرّف على طريقة إنشاء علاقات بين النماذج المختلفة من خلال إضافة نموذج للتعامل مع التعليقات في المدونة. المصدر: توثيقات Ruby on Rails.

Rails هو إطار عمل لتطوير تطبيقات الويب مكتوب بلغة Ruby البرمجية، وقد صُمّم إطار العمل هذا لتسهيل برمجة تطبيقات الويب من خلال وضع بعض الافتراضات المسبقة حول ما يحتاجه المطوّر للشروع في العمل. يتيح إطار العمل هذا كتابة شيفرات أقل وإنجاز أمور أكثر من أي لغة برمجية أو أطر عمل أخرى. يفترض Rails أن هناك طريقة مثلى لإنجاز الأعمال، وقد صمّم لتشجيع المطوّر على اتباع هذه الطرق وفي بعض الأحيان حثّه على ترك البدائل الأخرى، وقد تلاحظ زيادة هائلة في إنتاجيتك إن تعلّمت الأسلوب الذي يتبعه إطار العمل هذا، وقد يؤدي الالتزام بالعادات القديمة المتّبعة في لغات البرمجة الأخرى إلى تجربة غير جيّدة في تطوير التطبيقات باستخدام Rails. تستند فلسفة Rails إلى ركيزتين أساسيتين: لا تكرّر نفسك (Don’t Repeat Yourself): ينصّ هذا المفهوم على وجوب تمثيل أي جزء من أجزاء المعرفة بصورة مفردة وغير مبهمة وموثوقة في النظام. اتّباع هذا المفهوم في كتابة النصوص البرمجية وعدم تكرار المعلومات ذاتها باستمرار يؤدي إلى زيادة قابلية صيانة الشيفرة المكتوبة وامتلاكها القدرة على التوسّع إضافة إلى انخفاض نسبة الأخطاء فيها. مبدأ “Convention Over Configuration”: يمتلك Rails مبادئ خاصّة ترتبط بتحديد الطريقة المثلى في إنجاز الأعمال في تطبيق الويب، ويعتمد على هذه المبادئ بصورة افتراضية بدلًا من إجبار المطوّر على تحديد تفاصيل صغيرة في عمله من خلال عدد كبير من اﻹعدادات. ما الذي تحتاجه للبدء هذه السلسلة مخصصة للمبتدئين الذين يرغبون في الشروع ببناء التطبيقات على إطار العمل Rails، ولا يفترض وجود أي خبرة سابقة في هذا المجال، ولكن هناك بعض الأمور التي يجب تثبيتها قبل الشروع في التعلم: تثبيت الإصدار 2.2.2 من لغة Ruby البرمجية أو أي إصدار أعلى. تثبيت النسخة الملائمة من حزمة التطوير Development Kit إن كنت من مستخدمي نظام التشغيل ويندوز. نظام إدارة الحزم (الجواهر) RubyGems والذي يأتي مع لغة Ruby بصورة افتراضية. تثبيت قواعد بيانات SQLite3. ذكرنا أنّ إطار العمل Rails مبني باستخدام لغة Ruby البرمجية، وإن كنت لا تمتلك خبرة مسبقة بهذه اللغة يمكنك مراجعة الدروس المتوفّرة حول أساسيات لغة Ruby في الأكاديمية إضافة إلى الموقع الرسمي للغة. إنشاء مشروع جديد في Rails الهدف من هذه السلسلة هو بناء مدوّنة بسيطة باستخدام إطار العمل Rails، وقبل البدء في بناء التطبيق يجب التأكد من تثبيت Rails في جهازك. سنستخدم الرمز $ للتعبير عن سطر الأوامر في الأنظمة الشبيهة بـ UNIX. أما في نظام ويندوز فسترى سطر الأوامر يبدأ بشيء مشابه لهذه الصيغة: <C:\source_code. تثبيت Rails توجّه إلى سطر الأوامر في جهازك (في نظام macOS افتح الطرفية Terminal.app، وفي نظام ويندوز اختر “Run” من قائمة ابدأ ثم اكتب cmd.exe). في البداية سنتأكد من إصدار لغة Ruby المثبت في الجهاز: $ ruby -v ruby 2.3.1p112 بالنسبة لقواعد البيانات SQLite3 فعادة ما تكون مثبّتة بشكل افتراضي في الأنظمة الشبيهة بـ UNIX. أما في نظام ويندوز، فإن قمت بتثبيت Rails من خلال مثبت Rails فإن SQLite ستكون مثبتة على جهازك أيضاً. يمكنك كذلك مراجعة موقع SQLite3 للاطلاع على تعليمات تثبيت قاعدة البيانات. يمكن التحقق من سلامة تثبيت SQLite3 من خلال الأمر التالي: $ sqlite3 --version إن كانت SQLite مثبتة في الجهاز فسيظهر رقم الإصدار المثبت في سطر الأوامر. لتثبيت Rails استخدم أمر التثبيت gem install الذي يتيحه RubyGems وبالصورة التالية: $ gem install rails وللتأكد من أن عملية التثبيت قد تمّت بصورة صحيحة، يجب أن تكون قادرًا على تنفيذ الأمر التالي في سطر الأوامر: $ rails --version يجب أن تحصل على نتيجة مشابهة لهذه: Rails 5.1.0. إنشاء تطبيق المدوّنة يقدّم إطار العمل Rails مجموعة من الشيفرات تحمل اسم المولّدات generators، وتهدف هذه الشيفرات إلى تسهيل عمل المطوّر من خلال إنشاء الملفات المطلوبة للشروع في مهمّة معيّنة. مولّد التطبيق الجديد هو أحد هذه المولّدات ويعمل على إنشاء تطبيق Rails جديد وتوفير عناء كتابته من قبل المطور. ولاستخدام المولّد توجّه في سطر الأوامر إلى المجلد الذي ترغب في إنشاء التطبيق فيه واكتب الأمر التالي: $ rails new blog سينشئ هذا الأمر تطبيقًا جديدًا باسم Blog في مجلد blog وسيثبت اعتماديات gem الموجودة في GEMfile باستخدام الأمر bundle install. يمكنك الاطلاع على جميع الخيارات المتاحة في سطر الأوامر والتي يتقبّلها مولّد تطبيقات Rails وذلك من خلال تنفيذ الأمر: rails new -h بعد إنشاء تطبيق المدوّنة، توجّه في سطر الأوامر إلى المجلّد الخاص به: $ cd blog ستلاحظ أنّ مجلّد المدونة يتضمن بعض الملفات والمجلّدات التي تم إنشاؤها بصورة تلقائية والتي تمثّل العمود الفقري لتطبيق Rails. سينحصر الجزء الأكبر من عملنا ضمن مجلد app، ولكن لا بأس في الاطلاع بصورة سريعة على وظيفة هذه الملفات والمجلّدات: الملف أو المجلد الوظيفة /app يتضمن هذا المجلّد: المتحكّمات controllers، النماذج models، العروض views، الدوال المساعدة helpers، دوال البريد اﻹلكتروني mailers، القنوات channels، الوظائف jobs، والأصول assets الخاصّة بالتطبيق. سيتركّز عملنا ضمن هذا المجلد. /bin يتضمّن هذا المجلد شيفرات Rails المسؤولة عن تشغيل التطبيق ويمكن أن يتضمن شيفرات أخرى تستخدم في تثبيت وتحديث ونشر وتشغيل التطبيق. /config يتضمن الإعدادات الخاصة بمسارات التطبيق routes، وقاعدة البيانات وغير ذلك config.ru ملف إعدادات Rack يستخدم في خواديم Rack لتشغيل التطبيق عليها. /db يتضمّن مخطط قاعدة البيانات الحالية، إضافة إلى تهجيرات قاعدة البيانات. Gemfile, Gemfile.lock يتيح هذان الملفان تحديد اعتماديات gem المطلوبة لتطبيق Rails. يستخدم Bundler هذه الملفات. لمزيد من المعلومات توجّه إلى موقع Bundler الإلكتروني. /lib الوحدات الموسّعة الخاصة بالتطبيق. /log ملفات log الخاصة بالتطبيق. /public المجلد الوحيد الذي سيظهر على حاله بعد نشر التطبيق، ويتضمن الملفات الساكنة و ملفات الأصول المجمّعة. Rakefile يحدّد هذا الملف ويحمّل المهامّ التي يمكن تنفيذها بواسطة سطر الأوامر. يتم تعريف المهامّ ضمن مكوّنات Rails. ولإضافة مهامّ جديدة يجب عدم تعديل هذا الملف، بل إضافة ملفات إلى مجلّد lig/tasks. README.md الملفّ التعريفي الخاصّ بالتطبيق، ويمكن من خلاله تقديم نبذة تعريفية عن التطبيق والمهام التي يؤديها وطريقة التثبيت وغير ذلك من المعلومات. /test يضمّ هذا المجلد جميع الأمور المرتبطة بالاختبارات. /tmp يضمّ هذا المجلّد الملفّات المؤقتة (مثل ملفات الذاكرة المخبئية وملفات pid). /vendor ستجد هنا جميع شيفرات الطرف الثالث، وعادة ما يتضمن جواهر مطوّرة من قبل أشخاص أو شركات. gitignore. يخبر هذا الملف نظام التحكم في النسخ Git عن الملفات أو (الأنماط) التي ينبغي عليه تجاهلها. لتعرف المزيد راجع سلسلة دروس Git في الأكاديمية. مرحبًا Rails لنحاول في البداية إظهار بعض النصوص على الشاشة وبصورة سريعة، وللقيام بذلك، ستحتاج إلى تشغيل الخادوم الخاص بـ Rails. تشغيل خادوم Rails يتضمّن إطار العمل Rails خادوم ويب خاصًّا به وكل ما نحتاج إليه هو تشغيله وذلك من خلال تنفيذ الأمر التالي في سطر الأوامر ضمن مجلد blog: $ bin/rails server إن كنت تستخدم نظام ويندوز يجب تمرير الشيفرات في مجلد bin إلى مفسّر Ruby مباشرة: ruby bin\rails server تنفيذ هذا الأمر سيؤدي إلى تشغيل Puma، وهو خادوم ويب مضمّن بصورة افتراضية في إطار العمل Rails. حان الآن وقت الولوج إلى تطبيقنا من خلال المتصفح وذلك بالتوجه إلى الرابط http://localhost:3000/. ستظهر الصفحة التالية لتشير إلى نجاحنا في إنشاء أول مشروع على Ruby on Rails. المصدر: توثيقات Ruby on Rails.

تعرّفنا في الدرس السابق على طريقة تثبيت إطار العمل Rails وبدأنا العمل على مشروعنا الأول وهو عبارة عن مدوّنة بسيطة، وقمنا بتشغيل الخادوم الخاص بإطار العمل. وفي هذا الدرس سنتعرّف على آلية عمل إطار العمل Rails من خلال مثال بسيط، ثم نشرع بعده ببناء مدونتنا البسيطة لنتعرف بصورة أكبر على العديد من المفاهيم التي يستند إليها هذا الإطار. آلية عمل إطار Rails سنتعرّف على آلية عمل إطار Ruby on Rails من خلال مثال بسيط نعرض فيه مجموعة من الكلمات في الصفحة الرئيسية لتطبيقنا، وللقيام بذلك سنحتاج إلى متحكّم Controller وعرض View. وظيفة المتحكّم هي استقبال الطلبات الواردة إلى التطبيق، وتربط المسارات Routes بين الطلبات والمتحكّمات. وغالبًا ما يكون هناك أكثر من مسار واحد لكل متحكّم، ويمكن للمسارات المختلفة أن تؤدّي إلى أحداث Actions مختلفة، ووظيفة الحدث هي جمع المعلومات اللازمة وتقديمها إلى العرض. أمّا وظيفة العرض فواضحة من اسمه، وهي عرض المعلومات التي حصل عليها من الحدث بصورة مقروءة للإنسان. من الضروري هنا الانتباه إلى أن عملية جمع المعلومات تتمّ ضمن المتحكّم وليس ضمن العرض، ومهمّة العرض الوحيدة هي عرض المعلومات. يستخدم إطار Rails لغة قوالب خاصّة في العروض تدعى eRuby (اختصار لـ Embedded Ruby) والتي تُعالج بواسطة دورة الطلب في Rails قبل أن تُرسل إلى المستخدم. سلنجأ إلى أداة المولّد generator لإنشاء متحكّم يحمل اسم Welcome يتضمّن حدثًا باسم index. اكتب الأمر التالي في سطر الأوامر: $ bin/rails generate controller Welcome index سيقوم Rails بإنشاء مسار وعدد من الملفات. create app/controllers/welcome_controller.rb route get 'welcome/index' invoke erb create app/views/welcome create app/views/welcome/index.html.erb invoke test_unit create test/controllers/welcome_controller_test.rb invoke helper create app/helpers/welcome_helper.rb invoke test_unit invoke assets invoke coffee create app/assets/javascripts/welcome.coffee invoke scss create app/assets/stylesheets/welcome.scss ما يهمّنا من هذه الملفات هما المتحكم والموجود في المسار app/controllers/welcome_controller.rb والعرض الموجود في المسار app/views/welcome/index.html.erb. افتح الملف app/views/welcome/index.html.erb في محرّر النصوص المفضّل لديك، واحذف محتوياته واستبدلها بالشيفرة التالية: <h1>Hello, Rails!</h1> بعد أن أنشئنا المتحكم والعرض يجب علينا إخبار Rails بالمسار الذي سيأخذ المستخدم إلى هذا العرض. نحن نرغب في حالتنا هذه أن يتم توجيه المستخدم إلى العرض عندما يتوجّه إلى العنوان http://localhost:3000، ولكن صفحة الترحيب تشغل هذا المسار في الوقت الحاضر. بعد ذلك يجب إخبار Rails بموقع الصفحة الرئيسية ليتمكّن من عرضها للمستخدم. افتح الملف config/routes.rb في محرّر النصوص: Rails.application.routes.draw do get 'welcome/index' # For details on the DSL available within this file, see http://guides.rubyonrails.org/routing.html end الشيفرة أعلاه موجودة في ملف المسارات والذي يتضمّن مدخلات DSL خاصّة (DSL اختصار لـ domain-specific language) والتي تخبر Rail بطريقة ربط الطلبات الواردة إلى التطبيق بالمتحكمات والأحداث. عدّل هذا الملف بالصورة التالية: Rails.application.routes.draw do get 'welcome/index' root 'welcome#index' end من خلال السطر root 'welcome#index' يربط إطار العمل Rails الطلبات الواردة إلى المسار الرئيسي في التطبيق مع الحدث index في المتحكّم Welcome، أما السطر get 'welcome/index' فيربط من خلاله Rails الطلبات الواردة إلى العنوان http://localhost:3000/welcome/index بنفس الحدث ونفس المتحكّم، وقد تمّ إنشاء هذه الشيفرة من قبل أداة المولّد. والآن شغّل الخادوم الخاص بـ Rails ثمّ توجّه في المتصفّح إلى العنوان http://localhost:3000، وستشاهد عبارة “Hello, Rails!” الموجودة في ملف app/views/welcome/index.html.erb وهذا يعني أن هذا المسار قد توجّه فعلًا إلى الحدث index في المتحكم Welcome والذي قام بدوره بتصيير العرض بصورة صحيحة. البدء بإنشاء المدوّنة بعد أن تعرّفنا على المتحكّمات والأحداث والعروض، لنبدأ العمل على مدوّنتنا. سننشئ الآن ما يسمى في إطار العمل Rail بالمورد resourse، والمورد هو مصطلح يعبّر عن مجموعة من العناصر المتشابهة، مثل المقالات، الأشخاص أو الحيوانات. ويمكن إنشاء create وقراءة read وتحديث update وإلغاء destroy العناصر في المورد، وتسمى هذه العمليات بعمليات CRUD. يقدّم Rails تابعًا باسم resources يمكن استخدامه للإفصاح عن مورد بنمط REST القياسي. يجب إضافة مورد المقالة إلى ملف config/routes.rb وكما يلي: Rails.application.routes.draw do get 'welcome/index' resources :articles root 'welcome#index' end والآن إن قمت بتنفيذ الأمر bin/rails routes فستشاهد جميع المسارات الخاصّة بجميع الأحداث التي تتّصف بنمط REST. سنتعرّف على معنى عمود prefix وبقية الأعمدة في وقت لاحق، ولكن لاحظ أنّ Rails قد خمّن صيغة المفرد (article) واستخدمها في السياق الصحيح. $ bin/rails routes Prefix Verb URI Pattern Controller#Action articles GET /articles(.:format) articles#index POST /articles(.:format) articles#create new_article GET /articles/new(.:format) articles#new edit_article GET /articles/:id/edit(.:format) articles#edit article GET /articles/:id(.:format) articles#show PATCH /articles/:id(.:format) articles#update PUT /articles/:id(.:format) articles#update DELETE /articles/:id(.:format) articles#destroy root GET / welcome#index سنعمل الآن على إضافة خاصيتي إنشاء المقالات وعرضها، وستكون الاستمارة Form المسؤولة عن ذلك بالشكل التالي: قد تبدو الاستمارة بدائيًّة ولكنّها كافية في الوقت الحاضر، وسنعمل على تحسين مظهرها فيما بعد. إنشاء المتحكّمات والمسارات اللازمة في البداية يجب اختيار المسار الذي سيوجّه المستخدم إلى استمارة إنشاء المقالة الجديدة، وسنستخدم المسار /articles/new للقيام بهذه المهمّة، بعدها يصبح بميسور التطبيق أن يتلقّى الطلبات على هذا المسار. توجّه الآن في متصفحك إلى الرابط http://localhost:3000/articles/new وستتلقّى الخطأ التالي: يحدث هذا الخطأ لأنّ المسار بحاجة إلى متحكّم يرسل إليه الطلب؛ لذا سنقوم بإنشاء متحكّم باسم ArticlesController، وذلك من خلال تنفيذ الأمر التالي: $ bin/rails generate controller Articles افتح الملف الذي قمت بإنشائه app/controllers/articles_controller.rb وسترى متحكّمًا فارغًا: class ArticlesController < ApplicationController end المتحكّم عبارة عن صنف Class موروث من ApplicationController وسنقوم بتعريف التوابع ضمن هذا الصنف والتي ستمثل الأحداث الخاصّة بهذا المتحكم، وهذه الأحداث هي المسؤولة عن تنفيذ عمليات CRUD على المقالات الموجودة في تطبيقنا. إن أعدت تحميل الصفحة ستتلقّى خطأً جديدًا: يشير هذا الخطأ إلى عدم قدرة Rails على إيجاد الحدث new ضمن المتحكّم ArticlesController الذي قمنا بإنشائه للتوّ. وهذا عائد إلى أنّ المتحكّمات تكون فارغة عند إنشائها إلا إذا حدّدنا الأحداث المطلوبة خلال عملية إنشاء المتحكّم. ولتعريف حدث جديد بصورة يدوية، سنحتاج فقط إلى تعريف تابع جديد ضمن المتحكم. افتح الملف app/controllers/articles_controller.rb وضمن الصنف ArticlesController عرّف تابعًا جديدًا وكما يلي: class ArticlesController < ApplicationController def new end end والآن أعد تحميل الصفحة في المتصفّح وستتلقّى خطأً آخر: يظهر هذا الخطأ لأنّ Rails يتوقّع أنه يجب أن تمتلك الأحداث الصرفة المشابهة لهذا الحدث عروضًا ترتبط معها لعرض المعلومات التي تتضمنها، ونظرًا لعدم وجود أي عرض مرتبط بهذا الحدث، أطلق Rails هذا الخطأ. لنطّلع على رسالة الخطأ الكاملة: لنستعرض النص السابق سريعًا، ونفهم مضمونه بصورة جيدة. يحدّد الجزء الأول من نصّ الخطأ القالب المفقود، وفي هذه الحالة القالب المفقود هو articles/new. يبدأ Rails بالبحث عن هذا القالب، وإن لم يفلح في العثور عليه فإنه يحاول تحميل قالب يدعى application/new وذلك لأنّ المتحكّم ArticleController هو صنف موروث من المتحكّم ApplicationController. يتضمن الجزء الثاني من رسالة الخطأ request.formats والذي يحدّد صيغة القالب الذي سيتم عرضه كاستجابة للطلب الذي تلقّاه التطبيق، وقد تم اختيار صيغة text/html لأنّنا طلبنا هذه الصفحة بواسطة المتصفح؛ لذا يبحث Rails عن قوالب HTML. أما request.variant فيحدد طبيعة الأدوات المادّية physical devices التي سيتم تقديمها مع الطلب وتساعد Rails في تحديد القالب الذي سيستخدمه في الاستجابة، وهو فارغ نظرًا لعدم توفّر المعلومات. أبسط قالب يمكن أن يعمل في هذه الحالة هو القالب الموجود في المسار app/views/articles/new.html.erb. هذه اللاحقة مهمّة للغاية: فالجزء الأول من اللاحقة (.html) يعبّر عن صيغة القالب، أمّا الجزء الثاني (.erb) فيمثّل المعالج handler الذي سيتم استخدامه في تصيير القالب. يحاول Rails البحث عن قالب يحمل الاسم articles/new ضمن المجلد app/views. يجب أن تكون صيغة هذا القالب هي HTML حصرًا، وسيكون erb المعالج الافتراضي لـ HTML. يستخدم Rails عددًا من المعالجات مثل: builder والمستخدم في إنشاء قوالب XML، وcoffee الذي يستخدم لغة CoffeeScript لبناء قوالب JavaScript. بما أنّنا نرغب في بناء استمارة HTML جديدة فسنستخدم لغة ERB والتي تتيح لنا تضمين لغة Ruby في HTML. إذًا سيكون اسم القالب articles/new.html.erb وسيكون ضمن المجلد app/views الخاص بالتطبيق. أنشئ ملفًّا جديدًا باسم new.html.erb في المسار app/views/articles وأضف إليه ما يلي: <h1>New Article</h1> أعد تحميل الصفحة وستلاحظ ظهور العنوان في رأس الصفحة، وهذا يعني أن هناك تناغمًا تامًّا بين كلّ من المسار والمتحكم والحدث والعرض. الاستمارة الأولى سنستخدم منشئ النماذج form builder لإنشاء الاستمارة الأولى في هذا القالب. يمكن استخدام منشئ النماذج الرئيسي في Rails باستخدام التابع المساعد form_for. أضف الشيفرة التالية في الملف app/views/articles/new.html.erb: <%= form_for :article do |f| %> <p> <%= f.label :title %><br> <%= f.text_field :title %> </p> <p> <%= f.label :text %><br> <%= f.text_area :text %> </p> <p> <%= f.submit %> </p> <% end %> أعد تحميل الصفحة وستلاحظ ظهور نفس الاستمارة التي عرضناها في المثال السابق. كما تلاحظ فإنّ بناء الاستمارات في Rails أمر سهلٌ للغاية. عندما نستدعي التابع form_for فإننا نمرّر إليه عنصرًا يحدّد الهدف من هذه الاستمارة، والهدف في حالتنا هذه هو :article. يُستخدم الكائن FormBuilder والذي مثّلناه بـ f لبناء عنصري label وحقلي نصوص text fields لكلّ من عنوان المقال ومتنها. وفي النهاية استدعينا التابع submit لإنشاء زرّ اﻹرسال الخاصّ بالاستمارة. ولكن تعاني هذه الاستمارة من مشكلة صغيرة. لو تفحّصت شيفرة HTML التي تم توليدها من خلال الشيفرة السابقة فستلاحظ أن خاصية action التابعة للاستمارة تشير إلى المسار articles/new وهذا المسار هو نفسه الذي يقودنا إلى هذه الصفحة، والمفروض أن يستخدم هذا المسار لعرض استمارة إنشاء مقالة جديدة لا غير. إذًا يجب أن تستخدم الاستمارة مسارًا آخر، ويمكن القيام بذلك بسهولة من خلال استخدام الخيار :url في form_for. عادة ما يحمل الحدث المسؤول عن إرسال مقال جديد اسم “create”، لذا يجب توجيه الاستمارة إلى هذا الحدث. عدّل السطر الذي يتضمن form_for في ملف app/views/articles/new.html.erb كما يلي: <%= form_for :article, url: articles_path do |f| %> في هذا المثال تم تمرير الدالة المساعدة articles_path إلى الخيار :url، ولنتعرّف على نتيجة هذا التعديل سنلقي نظرة على مخرجات الأمر bin/rails routes في سطر اﻷوامر: $ bin/rails routes Prefix Verb URI Pattern Controller#Action articles GET /articles(.:format) articles#index POST /articles(.:format) articles#create new_article GET /articles/new(.:format) articles#new edit_article GET /articles/:id/edit(.:format) articles#edit article GET /articles/:id(.:format) articles#show PATCH /articles/:id(.:format) articles#update PUT /articles/:id(.:format) articles#update DELETE /articles/:id(.:format) articles#destroy root GET / welcome#index توجّه الدالة المساعدة articles_pat الاستمارة إلى نمط URI المرتبط لاحقة articles وسيرسل الاستمارة - تلقائيًا - طلبًا من نوع POST إلى المسار، والذي يرتبط بالحدث create التابع للمتحكّم ArticlesController. بعد أن أنشأنا الاستمارة وعرّفنا المسار المرتبط به، أصبح باﻹمكان تعبئة حقول الاستمارة والضغط على زرّ اﻹرسال لبدء عملية إنشاء مقال جديد، ولكن عند إرسال المقال ستتلقّى الخطأ المتوقَّع التالي: علاج هذا الخطأ بسيط وهو إنشاء الحدث create ضمن المتحكّم ArticlesController. إنشاء المقالات سنقوم الآن بتعريف الحدث create ضمن صنف ArticlesController في الملف app/controllers/articles_controller.rb بعد الحدث new وكما يلي: class ArticlesController < ApplicationController def new end def create end end إن أعدت إرسال الاستمارة مرة أخرى فستلاحظ عدم حدوث أي تغيير في الصفحة. لا تقلق، هذا الأمر عائد إلى أنّ Rails يعيد الاستجابة “204 No Content” لأي حدث لا يحدّد الاستجابة المطلوبة. وقد أضفنا الحدث create دون تحديد الاستجابة المطلوبة منه، وهي في حالتنا هذه، إنشاء مقالة جديدة في قاعدة البيانات. عند إرسال الاستمارة يتم إرسال الحقول الخاصة بها إلى Rails على هيئة معاملات parameters، يمكن الإشارة إليها في الأحداث التابعة للمتحكّم وذلك لإنجاز مهّمة ما، ولتعرف كيف تبدو هذه المعاملات عدّل حدث create بالصورة التالية: def create render plain: params[:article].inspect end يأخذ التابع render هنا جدول تقطيع Hash بسيط مع المفتاح :plain والقيمة هي تابع params [:article].inspect. توابع params هي الكائن الذي يمثّل المعامل (أو الحقل) المأخوذ من الاستمارة. ويعيد تابع params كائن من نوع ActionController::Parameters والذي يتيح لنا الوصول إلى مفاتيح جدول التقطيع من خلال السلاسل النصّيّة Strings أو الرموز Symbols. وفي حالتنا هذه، فإن المعاملات المهمّة هي المعاملات المأخوذة من الاستمارة. لتوضيح عمل توابع params، إليك المثال التالي: في عنوان URL هذا: http://www.example.com/?username=dhh&email=dhh@mail.com فإن params[:username] تحمل القيمة “dhh” و params[:email] تحمل القيمة “dhh@mail.com”. والآن أعد إرسال الاستمارة مرة أخرى وستشاهد شيئًا مماثلًا لما يلي: <ActionController::Parameters {"title"=>"First Article!", "text"=>"This is my first article."} permitted: false> يعرض هذا الحدث المعاملات الخاصة بالمقالة والمأخوذة من الاستمارة، ولكن ليس هذا ما نريده بالضبط، فنحن نشاهد المعاملات ولكنّها لا تقدّم أي فائدة تذكر في حالتها هذه. في الدرس القادم سنتعرّف على النماذج Models في إطار العمل Rails وسنستخدمها في إضافة مقالة جديدة إلى قاعدة البيانات التابعة للتطبيق. المصدر: توثيقات Ruby on Rails.

كثُر الحديث في السنوات الأخيرة عن إطار العمل Laravel وانتشر بين مطوّري PHP حتى إنه أصبح إطار العمل الأكثر استخداما بينهم، سواء للمشاريع الشخصية أو المهنية، حسب استبيان أجراه موقع SitePoint الشهير. كما أنه من أكثر المشاريع التي يُساهَم فيها على GitHub. سنتعرّف في سلسلة الدّروس هذه، التي يمثّل هذا المقال مقدّمة لها، على إطار العمل Laravel وأهم المبادئ التي يعمل وفقا لها. لماذا Laravel؟توجد الكثير من الأسباب التي تدعو لاختيار Laravel منها ماهو نفعيّ (انتشار أكبر يعني فرصًا أكثر للحصول على فرص توظيف) ومنها ماهو تقني بحت. قبل الإجابة على السؤال "لماذا Laravel؟" قد يكون من المفيد محاولة الإجابة عن "لماذا إطار عمل؟" بمعنى آخر ألا يمكنك كمطوّر PHP البدء من الصفر وبناء تطبيقك حسب الحاجة؟ يمكننا القول -باختصار- أن أطر العمل تجعلك تتخلص من ضرورة الاعتناء بتفاصيل كثيرة، ترفع كثيرا من إنتاجيتك وتقيك من أخطاء التعامل المباشر مع بيئة لغة البرمجة من قبيل أخطاء التعامل مع استعلامات قواعد البيانات التي قد تنتج عنها هجمات الحقن بتعليمات SQL المعروفة بــSQL injection. تفرِض أطر العمل الجيدة على مستخدميها الفصل بين أجزاء التطبيق وتنفيذ بنية Architecture مجرَّبة تؤدي في النهاية إلى الرفع من تصميم التطبيق وجعل الشفرة المصدرية أيسر في القراءة وأسهل في الصيانة والاختبار. نجمل في ما يلي أهم الأسباب التي تجعل من اختيار Laravel مناسبًا: سهولة الاستخدام.الفصل بين عناصر التطبيق مما يسهل عمل فريق من المطوّرين وتقاسم المهامّ بينهم.دعم التطوير السريع للتطبيقات Rapid Application Developing, RAD: توفر أداة Artisan وسيلة سريعة لإنشاء شفرة مصدرية نمطية للتعديل المباشر عليها. كما أنها تُستخدَم لمهامّ أخرى مثل تشغيل الاختبارات الأحادية Unit tests، تهجير قواعد البيانات، وغيرها.التضمين الافتراضي لوظائف شائعة الاستخدام في تطبيقات الويب، مثل الاستيثاق Authentication، التوجيه Routing، إدارة قواعد البيانات، إرسال البريد الإلكتروني.متحكمات RESTful: يعني هذا أنه يمكن الاستفادة من أفعال HTTP القياسية مثل PUT، POST، GET وDELETE.إدارة الاعتماديات Dependencies باستخدام Composer وهو ما يعني إمكانية استخدام الحزم والمكتبات الموجودة على الموقع www.packagist.com بيُسر ضمن مشاريعك.استخدام إطار العمل Eloquent وهو إطار للربط بين الكائنات في قاعدة البيانات والتصنيفات في شفرة التطبيق Object Relational Mapper.بنية MVCتتبع المشاريع في إطار العمل Laravel بنية Model-View-Controller (تُختصر بـMVC) التي تقسّم التطبيق إلى ثلاثة أجزاء متصلة في ما بينها، وتُفرّق بين التمثيل الداخلي للمعلومة والطرق التي تُقدَّم بها المعلومة إلى المستخدم. يقع جزء النموذج Model في قلب بنية التطبيق؛ تُعالَج في هذا القسم البيانات وتُنفَّذ عليها القواعد (في تطبيق محاسبة تنتمي الفواتير والعمليات عليها إلى هذا الجزء). يتولى الجزء الثاني في البنية وهو العرض View مهمة تقديم البيانات إلى المستخدم. يمكن أن تأخذ نفس البيانات أشكالا عدّة للعرض (مخطّط بياني، جدول، … إلخ). أما الجزء الثالث (المتحكِّم Controller) فيأخذ مُدخلات ويحوّلها إلى أوامر يرسلها للنموذج والعرض. يمكن شرح الأمر على النحو التالي: يرسل المتحكّم أمرا إلى النموذج لتعديل حالته (تحرير فاتورة). كما يمكنه إرسال أمر إلى العرض بتغيير طريقة تقديم البيانات (الانتقال بين أسطر الفاتورة).يخزّن النموذج البيانات المعثور عليها وفقا لأوامر المتحكّم وتلك المعروضة في العرض.يولّد العرض مخرجات للمستخدم حسب البيانات الخزّنة في النموذج.يجمل المخطط البياني التالي آلية العمل. سلسلة دروس Laravel: إنشاء تطبيق ويب للتسوقننطلق في سلسلة الدروس هذه من مبدأ أن أفضل وسيلة للتعلم هي الممارسة، لذا سنبدأ خطوة خطوة بإنشاء تطبيق ويب للتسوق مع ميزة سلة المشتريات. تعطي الصورة التالية فكرة عن شكل الموقع الذي نريد إنشاءه. تشمل السلسلة المواضيع التالية: تثبيت Laravel وإعداده على كلّ من Windows وUbuntu.أساسيات بناء تطبيق باستخدام Laravel.إنشاء روابط محسنة لمحركات البحث (SEO) في إطار عمل Laravel.نظام Blade للقوالب.تهجير قواعد البيانات في Laravel.استخدام Eloquent ORM لإدخال البيانات في قاعدة البيانات، تحديثها أو حذفها.إنشاء سلة مشتريات في Laravel.الاستيثاق في Laravel.إنشاء واجهة لبرمجة التطبيقات API في Laravel.إنشاء مدوّنة باستخدام Laravel.استخدام AngularJS واجهةً أمامية Front end لتطبيق Laravel.الدوّال المساعدة المخصّصة في Laravel.استخدام مكتبة Faker في تطبيق Laravel لتوليد بيانات وهمية قصدَ الاختبار.ترجمة -بتصرّف- لمقال Laravel 5 Tutorial لصاحبه Rodrick Kazembe.

الانتشار الكبير في استخدام لغات تصميم الويب أدى إلى ظهور بعض إطارات العمل (Frameworks) الجاهزة التي تسهل وتسرع عملية تطوير الواجهات كذلك فإن الانتشار الواسع لووردبريس والطلب الكبير لقوالبه دفع بعض المطورين والشركات إلى تطوير العديد من الأدوات الجاهزة التي تسهل بصورة أو أخرى عملية تطوير قوالب ووردبريس، إحدى هذه الأدوات الجيدة جدا هي قالب Underscores _s والذي يتمتع بمجموعة من المميزات (كما سنرى) تجعله من أفضل الأدوات المعينة لمطور قوالب ووردبريس. وفي هذا المقال سنتعرف على بعض مميزات قالب _s وطريقة استخدامه والاستفادة منه، لكن دعنا في الأول نلقي نظرة سريعة على بعض الأدوات المتاحة لمطوري قوالب ووردبريس (من قبل شركات أو مطورين أخرين) وأنواعها وفي أي الأنواع يمكن تصنيف قالب Underscores _s. أطر عمل قوالب ووردبريس WordPress Theme Frameworksأتذكر أنه عند بداية دراستي لتطوير قوالب ووردبريس شكل هذا المصطلح بعض الصعوبة بالنسبة لي ليس لأنه يحتوي على كلمة إطار عمل (Framework) فقط بل لأنه في مجتمع ووردبريس يطلق هذا المصطلح على عدة معاني حيث يختلف المعنى الذي يستخدم لأجله من بعض المطورين، لذا دعنا نحاول تجنيبك الوقوع في مثل هذا الإشكال بتعريف مبسط لكلمة إطار عمل وكذلك الإشارة الى بعض المعاني التي تستخدم لها هذه الكلمة في مجتمع ووردبريس. التعريف المبسط لإطار العمل Framework في مجال تطوير الويبهو عبارة عن مجموعة من الأدوات الجاهزة (عادة شيفرات برمجية) تؤدي بعض المهام الشائعة وتغنيك هذه الإطارات من كتابة هذه الشيفرات بنفسك. بالطبع فإن التعريف يمكن أن يكون أعم من ذلك لكن هذا ما نحتاجه في هذا المقال. إطارات عمل قوالب ووردبريس Themes Frameworkيطلق هذا المصطلح عادة على أربعة معاني في مجتمع ووردبريس (موقع ووردبريس الرسمي ذكر ثلاثة ودعني أضيف لها رقم 2 في قائمتنا هذه). القالب الأب Parents Themes (البعض يطلق عليها Themes Framework) هذا النوع من الأدوات عبارة عن قالب جاهز يمكنك الاستفادة منه من خلال صنع قالبك كقالب ابن Child Theme له وذلك بالاستفادة من هذه الميزة (القالب الابن) التي يوفرها ووردبريس. عادة عند إطلاق كلمة إطار عمل قوالب Themes Framework فإن المقصود هو هذا النوع من القوالب، ومن أشهر هذه القوالب هو إطار العمل Genesis ومن الإطارات ذات التطوير العربي هنالك إطار العمل ممتاز وليس المقام هنا لسرد القوالب المتوفرة تحت هذا النوع من الأدوات.إطارات عمل لوحة تحكم القوالب Theme Options Framework هذا النوع من الأدوات كما يظهر من أسمه يستخدم لتسهيل مهمة إنشاء لوحة تحكم للقالب فهو يسهل عملية إضافة واسترجاع خيارات القالب وعادة ما يوفر مجموعة من الحقول المتقدمة التي تتطلب برمجتها بدونه بعض الوقت والجهد. البعض أيضا يطلق كلمة إطار عمل (هكذا بإطلاقها) على هذا النوع من الأدوات، ومن أشهر هذه الإطارات إطار عمل Redux.المكتبات المساعدة Dropin Libarary هذه مجموعة من الملفات التي تقوم بتضمينها في قالبك للاستفادة من الدوال والأصناف الموجودة فيها وبالرغم من أن كثير من إطارات عمل لوحة التحكم يمكنها العمل بنفس الطريقة (تضمين ملفاتها في قالبك) لكن هذه المكتبات توفر عادة أكثر من مجرد تسهيل لعمل لوحة التحكم بل تتيح لك المزيد من التسهيلات فيما يتعلق بتطوير القالب ككل. من هذه المكتبات إطار العمل Hyprid.القالب الابتدائي Starter Theme عبارة عن قالب جاهز بنسبة كبيرة تقوم بتطوير قالبك بالتعديل عليه مباشرة لا عن طريق استخدام قالب ابن كما في الرقم 1 من هذه القائمة، ويوفر هذا القالب عادة التركيبة الأساسية لملفات قوالب ووردبريس وبعض الدوال والإعدادات الأساسية للقالب بحيث يجعل المصمم يركز على التصميم (CSS) أو تحويل التصميم الجاهز. قالب Underscores والذي نحن بصدد التعرف عليه يقع تحت هذا النوع من إطارات العمل وتستطيع استخدامه في تطوير قالبك من الخلال التعديل المباشر عليه كما سنرى لاحقا إن شاء الله.مميزات قالب Underscoresهنالك عدة مميزات تجعل من الجيد إختيار هذا القالب كنقطة بداية لتطوير قالبك، ومن هذه المميزات: القالب مفتوح المصدر ومطور من قبل مجموعة من المبرمجين المحترفين وعلى رأس التطوير شركة Automatic الراعية لووردبريس، وهذا يضمن لك توافقية عالية بين ووردبريس وقالب Underscores وكذلك احترافية في تطويره.القالب يعتمد على HTML5 كما أنه موثق بصورة جيدة ويحتوي على نسبة مناسبة من الشيفرات (بالتالي لن تفقد الكثير من الأساسيات الموجودة في أي قالب كما أنك لن تضطر لمسح الكثير من الشيفرات).يحتوي على مثال لتطبيق خاصية الترويسة المخصصة Custom header التي يوفرها ووردبريس.مجموعة مخصصة من وسوم القالب Template Tags (يشير هذا المصطلح الى مجموعة من الدوال تستخدم في جلب بيانات المقال) يمكنك استخدامها لتجنب تكرار الشيفرات البرمجية.مجموعة من تنسيقات CSS الأساسية تحتوي على توضيح لبعض فئات العناصر CSS Classes التي يولدها ووردبريس.يتبع الCoding standard الخاصة بووردبريس وموثق بصورة ممتازة، حيث يمكنك أن تتعلم الكثير منه.مجموعة من الدوال والإعدادات الأساسية في ملف functions.php.يشجع على استخدام مخصص القوالب Theme Customizer وهذا أمر مهم جدا خصوصا وأنه قبل أيام قليلة من نشر هذا المقال أصبح إستخدام مخصص القوالب لإعدادات القالب أمر إجباري لكل القوالب في مستودع القوالب الخاص بووردبريس وهذا قد يشير إلى توجه في مجتمع ووردبريس نحو المخصص ومحاولة جعلها Standerd في مسألة خيارات القالب، ولذلك في نهاية هذه السلسلة سنلقي نظرة إلى طريقة إستخدام مخصص القوالب في خيارات القالب.طريقة استخدام Underscoresفي البداية عليك التوجه لموقع القالب وقم بكتابة اسم القالب الذي تود تطويره في الخانة المخصصة ويمكنك الضغط على Advanced Options لإدخال المزيد من الخيارات مثل اسم المطور ورابط موقعه ووصف القالب، وسيقوم الموقع باستخدام هذه المعلومات ويولد لك القالب والذي سيبدأ التحميل مباشرة فور الضغط على Generate. طبعا ستجد أن المعلومات التي قمت بكتابتها تم استخدامها في الترويسة الأساسية للقالب والموجودة في ملف style.css وكذلك في اسم مجلد القالب. بعد ذلك يمكنك تنصيب القالب على الموقع الذي قمت بإعداده لتطوير القالب ومن الجيد أن تقوم بفتح مجلد القالب على محرر الشيفرات المفضل بالنسبة لك حتى تتابع معنا شرح بعض خصائص القالب. التركيبة الأساسية للقالب (المجلدات والملفات)ستلاحظ أن مجلد القالب يحتوي على الملفات الأساسية لقوالب ووردبريس وهي: Style.css, index.php, functions.php, single.php, page.php, archive.php, search.php, 404.php, header.php, footer.php, sidebar.php, comments.php, rtl.css بالإضافة الى مجموعة من الملفات التي يبدأ اسمها بـ content وهي: Content.php, content-single.php, content-page.php, content-search.php, content-none.phpوهذه الملفات تستخدم لوضع محتويات الحلقة The Loop لبعض ملفات القالب الأساسية التي تحتوي على حلقة لجلب المقالات مثل ملف single.php مثلا، حيث يتم تضمين ملف conent المناسب (مثلا content-single.php) في ملف القالب المناسب (single.php) من خلال إستخدام الدالة get_template_part وتستخدم بهذه الطريقة: <?php get_template_part( 'content', 'single' ); ?> حيث أن المعامل الأول للدالة هو بداية اسم الملف والمعامل الثاني هو نهايته (ما بعد الفاصلة) وهذا يوضح لك سبب تسمية الملفات التي تبدئ بـ content بهذه الطريقة. واستخدام هذه الدالة من الأمور الجيدة في هذا القالب لما تتميز به من مميزات وحتى تحافظ على مقروئية جيدة للشيفرة البرمجية فبدلا من وضع كل الشيفرات في ملف single.php او index.php يتم فصل محتويات الحلقة -والتي عادة ما تحتوي على الكثير من شيفرات html- في ملف لوحدها ثم تضمينها. وأيضا يمكنك استخدامها مع الدالة get_post_format لتضمين الملفات اعتمادا على بنية المقال. من الملفات أيضا في المجلد الرئيسي للقالب ملف README.md وصورة screenshot.png ولا أظن أنهما يحتاجان إلى شرح. مجلد incهذا أو المجلدات التي سنتحدث عنها ، حيث يحتوي على خمسة ملفات الجامع بينها أنه يتم تضمينها داخل ملف function.php كما ترى في نهاية هذا الملف من خلال استخدام الدالة بهذه الطريقة: require get_template_directory() . '/inc/template-tags.php'; حيث أن الدالة ()get_template_directory ترجع مسار القالب الحالي ومن الجيد استخدام دوال ووردبريس التي يوفرها فيما يتعلق بمسارات القالب، وهذه أحد الأشياء التي عليك تعلمها من قالب Underscores بالإضافة الى العديد من الممارسات الجديدة Best Practice الأخرى كما سنرى. تضمين هذه الملفات في ملف functions.php بدلا عن كتابة كل الشيفرات الوظائفية الخاصة بالقالب في ملف functions.php يجعل القالب أكثر تنظيما ويسهل التعديل عليه فيما بعد بالإضافة لفصل الدوال والشيفرات على حسب وظائفها. لاحقا سنتطرق الى تفاصيل بعض هذه الملفات بعد أن نلقي نظرة سريعة على ملف functions.php، لكن الأن دعنا نكمل الاطلاع على تركيبة القالب. مجلد jsواضح من اسمه أنه يحتوي على ملفات الجافا سكربت الخاصة بالقالب، وبه ثلاث ملفات سنطلع على وظائفها فيما الدرس القادم إن شاء الله. وبالطبع يمكنك إضافة ملفات جافا سكربت الخاصة بك في هذا المجلد. لاحظ أنك فيما بعد قد تحتاج لإضافة مجلد لملفات CSS واخر للصور وفي هذه الحالة ربما تفضل وضع هذين المجلدين مع مجلد js في مجلد جديد باسم assest أو static مثلا. بقية المجلداتكما تلاحظ هنالك أيضا مجلد language الذي به ملفات اللغة، وملف layout وهو يحتوي على ملفي CSS يستخدمان لتوفير خيارين في تخطيط الموقع، وملف sass وبه بعض الملفات المفيدة في حالة كنت تستخدم SASS. خاتمة كانت هذه مقدمة سريعة على أنواع الإطارات الخاصة بعمل قوالب ووردبريس، ونظرة على طريقة تحميل قالب _s وتركيبة الملفات والمجلدات فيه، وتبقى لنا الكثير لمعرفته حول قالب _s وإستخدامه في تطوير قوالب ووردبريس وهو ما سنتطرق إليه في المقالات القادمة من هذه السلسلة إن شاء الله.

لا يجب أن تبدأ دائمًا بالتطوير باستعمال إطار عمل JavaScript، لكن هنالك حالات يكون فيها استعمال إطار العمل أمرًا منطقيًا. منذ فترةٍ كتبتُ مقالةً بعنوان «لماذا يدفعنا التطوير بلغة JavaScript إلى حافة الجنون!» والتي زارها الكثيرون، وظهر التساؤلان الآتيان ردًا عليها: - متى يجب أن نستخدم إطار عمل؟ - إذا لم نستعمل إطار عمل، فكيف نبدأ؟ سأحاول في هذه المقالة الإجابة على التساؤل الأول، أما سؤال كيفية البدء إذا لم نستعمل إطار عمل فهو سؤالٌ أكبر، ويحتاج تفصيلًا أكثر. بدأتُ العمل منذ عدِّة سنوات في شركة (لن أسميها هنا)، والتي تستطيع أن تطلب منها إنشاء أي شيء غريب يمكن تخيله، وستصنعه لك خلال فترةٍ وجيزة. كان للشركة هامش ربحٍ كبير، وتجني أموالًا طائلة، وتعلمتُ الكثير عن إدارة الأعمال منها، لكنني تعلمتُ أيضًا بعض الأمور عن الأنظمة. كانت واجهة موقع الشركة الإلكتروني معقدةً! ولهذا السبب بدأ موقع الشركة في بدايات 2000 بالتحول إلى تطبيقٍ ذي صفحةٍ واحدة، حتى قبل انتشار فكرة التطبيقات ذات الصفحة الواحدة (single page application). كانت شيفرات JavaScript التي تشغل موقعهم معقدةً جدًا، وكانوا نادرًا ما يوظفون مبرمجين، واختاروا إطار عمل YUI بدلًا من jQuery لأنه كان شائعًا في تلك الفترة، ثم اشتقوا (fork) شيفرة YUI مما جعل التعامل معها وصيانتها أمرًا صعبًا جدًا. ولسببٍ أجهله، كانوا يكتبون شيفرات JavaScript بشكلٍ شبيهٍ بشيفرات Visual Basic. كانوا أيضًا يستعملون نظامًا لإدارة الإصدارات (version control system) من الثمانينات الذي كانت آلية حماية الملفات من التعديل فيه هي قفلها (file locks) والتي تستطيع بسهولة تجاوزها. سكربت البناء الذي كانوا يستعملونه هو شخصٌ اسمه Ed، فلتحويل الشيفرة إلى الخادوم الإنتاجي سيكون عليك أن تطبع قائمةً بالملفات التي عدَّلتَها وتسلمها لذاك الشخص، ثم سيبحث عن تلك الملفات وينسخها يدويًا إلى كل خادوم على حدة. كان السند الخلفي (backend) للموقع هو حاسوبٌ قديمٌ يُشغِّل برمجيات مكتوبة في سبعينيات القرن الماضي، وكانت تُحدَّث بيئة التطوير المشتركة يدويًا من قِبل المطورين، متى أرادوا ذلك. إذا كنتَ تضحك الآن على حالهم وتظن أن هؤلاء الأشخاص أغبياء، فأظن أنَّ الوقتَ مناسبٌ لأشير إلى أنهم لم يعانوا من انقطاعاتٍ في الخدمة، وكانوا يُصدرون ميزاتٍ جديدة دوريًّا، ويجنون أموالًا طائلة تزداد عامًا بعد عامًا. لذا أظن أنهم يضحكون الآن خلال طريقهم إلى البنك ليستلموا أرباحهم. هل تتلقى أجرًا لقاء كتابتك للشيفرات؟ إذًا أنت تعمل لدى شركة. وعندما تقرر الشركة كيف تُنفِق ميزانية المطورين، فلن يكون منطقيًا أن تنفق مالًا لكتابة البرمجيات «بالطريقة الصحيحة». الفكرة التي أحاول إيصالها هنا هي أنَّ حال الشركة السابقة قد يبدو بائسًا بالنسبة إلى مطوري البرمجيات، لكنه منطقيٌ جدًا وجيد بالنسبة إلى أصحاب تلك الشركة الذين يهتمون بالربح. استخدام إطار عمل JavaScript قد لا يكون خيارًا استراتيجيًا للشركات حتى لو كان حالها سيئًا كالشركة التي نتحدث عنها. إذًا، كيف يجب أن تتابع الشركة السابقة بتطوير برمجياتها؟ كيف ستقرر الشركة أنها بحاجة إلى استخدام إطار عمل؟ شرحتُ سابقًا في مقالة «لماذا يدفعنا التطوير بلغة JavaScript إلى حافة الجنون!» أنَّ من غير المنطقي البدء بتطوير البرمجيات انطلاقًا من إطار عمل. لنفترض وجود شيءٍ شبيهٍ بإطار Angular عند نشأة الشركة السابقة؛ فهل كان عليهم استخدام إطار عمل؟ هل يجب عليهم استخدام إطار عمل في هذه الفترة؟ عندما تختار الشركة إطار عمل لتستعمله لتطوير برمجياتها، فهنالك كلف ومخاطر: - ماذا لو اختفى دعم إطار العمل خلال خمس سنوات؟ هل يمكن أن تتحمل الشركة عبء صيانة إطار العمل بنفسها؟ هل يتوافر في فريق العمل أشخاصٌ لهم خبرات في هذا المجال؟ الجواب هو النفي لأغلبية الشركات، ولا نُغفِل أنَّ الكثير من أطر العمل Frameworks تختفي فجأةً. عليك أن تجري مع التيار وتخمِّن إن كانت الزيادة في الإنتاجية الآتية من اختيار إطار عمل تستحق الوقت والكلفة اللازمة للتحويل إلى إطارٍ آخر لاحقًا، أو أنَّها تستحق كلفة التعامل مع برمجيات غير مدعومة لسنوات في نفس الوقت الذي تحاول فيه توفير ميزانية كافية للتحويل إلى إطارٍ جديد. إذا كانت شيفرات برمجيتك قليلة نسبيًا وكنت تعمل في شركة وتحذف كميةً لا بأس بها من الشيفرات وتُعيد كتابتها (كثير منا يفعل ذلك لكنهم لا يعترفون)، فأرى أنَّ من المناسب استعمال إطار عمل. أما لو كانت شيفرات برمجيتك كثيرة جدًا، وكنت تنظر إلى خطتك التي وضعتها للسنوات الخمسة القادمة ورأيتها مليئةً بالميزات الجديدة التي ستكوِّن جزءًا أساسيًا من شركتك، فإن اختيار إطار عمل الذي سينتهي دعمه خلال خمسة سنوات هو رهانٌ خاسر، والطريقة الوحيدة التي ستجعلك تختار واحدًا هي التفكير بأجوبةٍ للأسئلة المتبقية … - كم ستخسر من إنتاجية مطوريك حتى يتعلموا إطار العمل الجديد؟ إذا كنت تنتقل إلى إطارٍ وليكن Angular (وما لم توظِّف مطورين يعرفون Angular من قبل ويلمّون بأحدث المعلومات) فستنفق مالًا لتدريب فريق التطوير وسيضيّع المطورون الأشهر القادمة يسألون «كيف أفعل ذلك في Angular؟» حتى لو كانوا يفعلون نفس الأمر تمامًا باستخدام jQuery وشيفرات JavaScript البسيطة دون أدنى تفكير. - هل يمكننا بناء هذه الميزة التي تجعلنا نجني مالًا أكثر بنفس مقدار الوقت اللازم لتعلم إطار العمل؟ الجواب لأغلبية الشركات الربحية هو «نعم». - هل سيسمح لنا إطار العمل بجني المزيد من المال بجعلنا نُنشِئ الميزات الجديدة بوتيرة أسرع في المستقبل؟ نظريًا: هذه هي الفائدة المرجوة من إطار العمل. إذ ستحصل على فائدة أكبر من إطار العمل عندما يكون فريقك كبيرًا، وشيفرات مشروعك كثيرة، وتريد تسريع وتيرة تطوير الميزات الجديدة. لكن لاحظ أنَّك تستطيع تطوير بعض البرمجيات بسهولة ولن تستفيد فيها من التحول إلى إطار عمل. حسنًا، ربما تظن أنَّ هذا قرارٌ صعبٌ، إلا أنه في الواقع عكس ذلك لأغلبية الشركات. - الشركات الصغيرة وسريعة التغيرات تقع في الزاوية العليا اليسرى من المخطط السابق، فإذا كانت شيفرات برنامجك تتغير بسرعة فلن يكون من الخطر التغيير إلى إطار عمل آخر. فلو كنت تضيف الميزات يمنةً ويسرةً لأنك لم تعلم أيها يجني مالًا بعد، فلن تهتم إن «مات» إطار العمل الذي تستخدمه، لأنك ستحذف تلك الميزات والأجزاء من الشيفرات على أيّة حال. إذا كانت إنتاجيتك أكبر عندما تستعمل إطار عمل، وكنت تعمل لدى شركةٍ ناشئةٍ فسأقول أنَّ من الصواب استعمال إطار عمل، مع الأخذ بالحسبان أنَّ أغلبية الأشخاص تقل إنتاجيتهم عندما يستعملون إطار عمل لكنهم لا يعترفون بذلك. - تتواجد الشركات الصغيرة وذات معدل التغيير البطيء في الطرف السفلي اليساري من المخطط، وتكون إما شركات صغيرة تقليدية التي لا تُمثِّل البرمجيات مكوِّنًا أساسيًا من طريقة عملها، أو شركات البرمجيات الصغيرة. إذا كنت مبرمجًا تعمل لدى شركة صغيرة، فلا تستعمل إطار Angular أو React أو غيرهما. وإنما استخدم المكتبات المستقرة والثابتة والتي تعمل على جميع المتصفحات. فلو كنت تعمل في شركةٍ صغيرةٍ، فأرى أنَّ مخاطر استعمال إطار عمل تفوق ميزاته. - الشركات الكبيرة وذات معدل التغيير السريع تتواجد في القسم العلوي الأيمن من المخطط، وهي الشركات التي تكون البرمجيات مكوِّنًا أساسيًا فيها، أي أنهم يضيفون الميزات كثيرًا ويحذفون أجزاءً كبيرةً من الشيفرات ويعيدون كتابتها (حتى لو لم يعترفوا بذلك)، ولديهم فرق برمجية كبيرة، والميزات الجديدة التي يُضيفونها ستدر عليهم مالًا. لذا من المنطقي أن يدرِّبوا فِرَق البرمجة عندهم لاستعمال إطار عمل، لكي يبدأ الجميع من نفس المكان ولتُكتَب الميزات بوتيرة أسرع. إذا كانت شركتك ذات دخلٍ كبير، فستقل مخاطر فقدان دعم إطار العمل مع مرور الزمن، لأنك عندما كنت تختار ما هو إطار العمل الذي ستعمل عليه فستأخذ بالحسبان الدعم الطويل له. أما لو كنت تعمل في شركةٍ كبيرةٍ وتجني أموالًا طائلة وكانت البرمجيات من أساس عملك، فمن المنطقي أن تكتب إطار عمل خاص بك مثل Facebook و Google … - الشركات الكبيرة وذات معدل التغيير البطيء تقع في الركن السفلي اليميني من المخطط. وتنتمي الشركة التي تحدثنا عنها في بداية المقالة إلى هذا النوع، ولن يكون الخيار الصائب واضحًا هنا. فليس مجال عمل الشركة هو البرمجيات، لكن البرمجيات هي جزءٌ أساسيٌ نظام عمل الشركة. لن تتغير الشركة بسرعة، لكن الميزات الجديدة ستساعد الزبائن بشراء المزيد من المنتجات. مثاليًا، يمكنك أن تبني على إطار عمل الذي سيبقى حوالي 50 سنة، وهذا أمرٌ معقولٌ بالنسبة إلى شركةٍ تستعمل برمجيات وشيفرات عمرها 40 سنة. لكن هذا ليس موجودًا، لذا قد تفكر ببناء إطار عمل خاص بك، لأنك ستتأكد أنك لن تقع في فخ أطر العمل الميتة بعد 10 سنوات. لذا يجب أن تنشئ كل شيء من الصفر، وسترى أنَّ نفقات إنشاء ذلك قليلةٌ مقارنةً بالربح خلال 50 سنة … إذًا، هل يجب أن تنتقل الشركة إلى إطار عمل؟ لا يوجد جواب سهل! فعندما كنتُ مطورًا أعمل عندهم وكنت أفكر عن البرمجيات فقط، فكان الجواب الجلي بالنسبة لي هو: بالطبع يجب أن ينتقلوا لاستخدام Angular! لكن عندما بدأتُ شركتي الخاصة، فأصبحتُ أرى البرمجيات من زاويةٍ أخرى، لذا لن يكون الخيار سهلًا. توقف برهةً وفكِّر بعمق قبل الالتزام بإطار عمل، وإذا كنتَ صاحب قرار التحول إلى إطار عمل في حال استعملتك الشركة كمستشار، فأسدِ خدمةٍ إلى الشركة، وانزع عنك نظارات المبرمج، وضع نظارات مدير الأعمال. ترجمة -وبتصرّف- للمقال Should You Ever Use a JS Framework?‎ لصاحبه Sean Fioritto

تعرّفنا في الدرس السابق على القسمين الثاني والثالث من بنية المشاريع في إطار العمل Django وهما العروض Views والقوالب Templates، وقد تحدّثنا عن العروض وآلية عملها بشكل مفصّل، وسنتطرّق في هذا الدرس بشيء من التفصيل إلى القوالب وآلية عملها وسنتعرّف كذلك على محرّك القوالب الخاص بـ Django. ما هي القوالب؟ نظرًا لكون Django إطار عمل للويب فإنّه بحاجة إلى وسيلة لتوليد شيفرات HTML بصورة ديناميكية، ويستخدم Django القوالب لهذا الغرض، إذ يحتوي القالب على أجزاء ثابتة تضم شيفرة HTML وCSS إضافة إلى صيغة برمجية خاصة تتحكم في طريقة إضافة المحتوى الديناميكي إلى القالب تسمى لغة قوالب Django (DTL). قالب Django عبارة عن ملف نصي يستخدم لغة قوالب Django، ويتضمن هذا الملف بعض الأمور التي يتم تفسيرها من قبل محرك القوالب، وأهمّها المتغيرات واﻷوسمة. ﻻ بدّ أنّك قد لاحظت أنّه في كلّ مرة أجرينا فيها عملية ربط القالب، فقد قمنا بتعريف سياق المتغيرات Variable Context معه. يقوم Django بتصيير Rendering القالب مع السياق المرتبط به، حيث يتم استبدال أسماء المتغيرات بالقيم المرتبطة بها وذلك بعد مطابقتها مع سياق المتغيرات المرفق مع القالب، ويتم كذلك تنفيذ الوسوم الموجودة في ملف القالب، أما ما تبقى في هذا الملف فيظهر كما هو. المتغيرات يعرض المتغير القيمة المرتبطة به عن طريق السياق، وهو قاموس يضم مجموعة من المفاتيح والقيم المرتبطة بها. لاستخدام المتغيرات في قوالب Django يكفي إحاطتها بقوسين معقوفين بالشكل التالي: My first name is {{ first_name }}. My last name is {{ last_name }}. فلو كان سياق المتغيرات بالشكل التالي: {'first_name: 'Mohammed', 'last_name': 'Taher'} تكون النتيجة: My first name is Mohammed. My last name is Taher. الوسوم تؤدي الوسوم مهام متعدّدة ومتنوعة، فيمكن للوسم أن يعرض محتوى معين، أو يؤدي وظيفة بنى التحكم كجمل If الشرطية وحلقات for التكرارية، أو جلب محتوى من قاعدة البيانات، وغير ذلك الكثير. تحاط الوسوم في القوالب بقوس معقوف وعلامة النسبة المئوية، كما في المثال التالي: {% csrf_token %} ومعظمها يتقبل المعاملات: {% cycle 'odd' 'even' %} وتتطلب بعض الوسوم تحديد وسم البداية والنهاية: {% if user.is_authenticated %}Hello, {{ user.username }}.{% endif %} لنلقِ نظرة اﻵن على أشيع الوسوم المستخدمة في لغة قوالب Django: الجمل الشرطية يتحقّق الوسم {% if %} من قيمة المتغير، فإذا كانت القيمة صحيحة (بمعنى أنّ المتغير موجود، وليس فارغًا، ولا يحمل قيمة false) يتم عرض محتوى المتغير: {% if article_list %} Number of articles: {{article_list|length}} {% elif article_in_archive %} The Articels are in Archive. {% else %} No articles. {% endif %} ﻻحظ أنّه يمكن استخدام وسمي {% elif %} و {% else %} لمرة واحدة أو لعدة مرات ضمن الوسم If، وﻻحظ أيضًا أن هذا الوسم يتطلب وجود وسم إغلاق. يمكن استعمال المعاملات المنطقية (and, or, not) في الوسم If، كما يمكن استخدام المعاملات الرياضية (==, !=, <, >, <=, >=, in)، إضافة إلى إمكانية دمج هذه المعاملات مع بعضها البعض، إليك بعض اﻷمثلة: {% if athlete_list and coach_list %} Both athletes and coaches are available. {% endif %} {% if athlete_list and not coach_list %} There are some athletes and absolutely no coaches. {% endif %} {% if athlete_list and coach_list or cheerleader_list %} There are some athelets and maybe some coaches or cheerleaders. {% endif %} {% if somevar == "x" %} This appears if variable somevar equals the string "x" {% endif %} {% if "bc" in "abcdef" %} This appears since "bc" is a substring of "abcdef" {% endif %} {% if user in users %} If users is a QuerySet, this will appear if user is an instance that belongs to the QuerySet. {% endif %} حلقة for التكرارية يؤدي هذا الوسم نفس الوظيفة التي تؤديها أي حلقة for في أي لغة برمجية، إليك هذا المثال: <ul> {% for athlete in athlete_list %} <li>{{ athlete.name }}</li> {% endfor %} </ul> يمكن المرور على عناصر مصفوفة معينة وبصورة عكسية بإضافة كلمة reversed: {% for obj in list reversed %} ويمكن إظهار عناصر قائمة معينة بالشكل التالي: {% for x, y in points %} There is a point at {{ x }},{{ y }} {% endfor %} ويمكن استخدام هذا الوسم للعرض المفاتيح والقيم المرتبطة بها في قاموس معين: {% for key, value in data.items %} {{ key }}: {{ value }} {% endfor %} يمكن الوصول إلى عداد الحلقة التكرارية بأساليب مختلفة، وذلك عن طريق مجموعة من المتغيرات يقدّمها محرّك القوالب في Django. فمثلًا forloop.counter يظهر العدد الحالي للحلقة ويبدأ عدّ الحلقات من الرقم 1، و forloop.counter0 الذي يؤدي نفس الوظيفة ولكن يبدأ العدّ من الرقم 0، و forloop.first والذي يعطي قيمة True إن كانت الدورة الحالية هي الدورة اﻷولى ضمن الحلقة، وforloop.last والذي يؤدي نفس الوظيفة ولكن عند الوصول إلى الدورة اﻷخيرة ضمن الحلقة. إليك هذا المثال لتوضيح الموضوع: {% for photo in gallery %} {% if forloop.counter == 1 %} Do something with {{ photo }}. {% endif %} {% endfor %} تبدأ حلقة for بالمرور على عناصر مجموعة معرض الصور gallery ويتحقق وسم if أثناء ذلك من العدد الحالي للحلقة، فإن كانت الحلقة هي اﻷولى يتم تنفيذ الشرط، وإلا فلا. الشيفرة السابقة مطابقة للشيفرة التالية: {% for photo in gallery %} {% if forloop.first %} Do something with {{ photo }}. {% endif %} {% endfor %} تقدّم لغة قوالب Django عددًا كبيرًا من الأوسمة التي تؤدي وظائف متعددة ومتنوعة، ويمكنك الاطلاع على جميع الوسوم المتوفرة ووظائفها من هنا. المرشحات Filters تعمل المرشّحات على إجراء تحويل معيّن على قيم المتغيرات والأوسمة، وتستخدم بالشكل التالي: {{ hsoub|title }} {% if messages|length >= 100 %} You hove lots of messages. {% endif %} يعمل المرشح title على تحويل الحرف اﻷول من كل كلمة في قيمة المتغير إلى حرف كبير، فلو كان السياق معرفًا بالشكل التالي: {'hsoub': 'on a mission to develop the arab world'} فإن الحرف اﻷول من كل كلمة في العبارة السابقة سيتحول إلى حرف كبير: On A Mission To Develop The Arab World يمكن لبعض المرشحات أن تتقبل المعاملات: {{ my_date|date:"Y-m-d" }} يقدم محرّك قوالب Django عددًا كبيرًا من المرشحات التي تؤدي وظائف مختلفة، كتنسيق الوقت والتاريخ، وعرض الجمل المناسبة لصيغتي المفرد والجمع، وتكبير اﻷحرف اﻹنكليزية وتصغيرها، وحساب عدد الكلمات وغيرها الكثير. يمكنك الاطلاع جميع المرشحات المتوفرة ووظائفها من هنا. استخدام محرّك القوالب في تطبيق الاقتراعات لنعد اﻵن إلى تطبيق الاقتراعات الذي نعمل على إنشائه ضمن هذه السلسلة، ولنتوجه إلى ملف templates/polls/index.html الذي يحتوي الشيفرة التالية: {% if latest_question_list %} <ul> {% for question in latest_question_list %} <li><a href="/polls/{{ question.id }}/">{{ question.question_text }}</a></li> {% endfor %} </ul> {% else %} <p>الاقتراعات غير متوفرة حالياً.</p> {% endif %} ﻻحظ أنّنا نستخدم في هذا الملف عددًا من المتغيرات واﻷوسمة، إذ يبدأ الملف بوسم If يتحقق من قيمة المتغير latest_question_list الموجود في سياق المتغيرات المرفق مع القالب، فإن كانت نتيجة التحقق صحيحة، يضاف وسم <ul> إلى الملف ثم تبدأ حلقة for بالعمل، حيث تمرّ على جميع عناصر القائمة latest_question_list وإسناد كل قيمة إلى المتغير question. ﻻحظ أن هذا المتغير يضمّ متغيرات فرعية (إن صح التعبير) تحمل قيمًا مختلفة، مثل question.id و question.question_text. تقوم بالحلقة بسرد عناصر القائمة مع إضافة وسمي <li> و <a> إلى كل عنصر، وبعد الانتهاء يضاف الوسم </ul>. استخدمنا الوسم else لعرض رسالة تخبر المستخدم بعدم وجود أي اقتراعات في الوقت الحاضر في حال كانت نتيجة التحقق خاطئة. توجّه اﻵن إلى الملف detail.html وعدّله ليصبح بالشكل التالي: <h1>{{ question.question_text }}</h1> <ul> {% for choice in question.choice_set.all %} <li>{{ choice.choice_text }}</li> {% endfor %} </ul> ستعمل الشيفرة السابقة على عرض اﻷجوبة المرتبطة بالسؤال الذي اختاره المستخدم على هيئة قائمة نقطية. توليد الروابط بصورة ديناميكية هناك مشكلة صغيرة في قالب index.html وهي أننا قمنا بكتابة مسار الرابط بأنفسنا، ولم يتم توليد هذا المسار ديناميكيًا، اﻷمر الذي يجعل من تبديل المسار في وقت لاحق أمرًا صعبًا خصوصًا إن تضمن القالب مسارات عديدة. يمكن لـ Django أن يتكفل بعملية توليد مسارات الروابط بشكل كامل، وذلك باستخدام الوسم {% url %} ليصبح الملف index.html بالشكل التالي: {% if latest_question_list %} <ul> {% for question in latest_question_list %} <li><a href="{% url 'detail' question.id %}">{{ question.question_text }}</a></li> {% endfor %} </ul> {% else %} <p>الاقتراعات غير متوفرة حالياً.</p> {% endif %} ولكن كيف يتعرّف Django على المسار المطلوب؟ يستخدم Django قيمة المعامل name الذي قمنا بتعريفه في الدرس الرابع من هذه السلسلة (المسارات في Django). توجّه إلى ملف polls/urls.py والق نظرة على المسار الخاص بعرض detail: url(r'^(?P<question_id>[0-9]+)/$', views.detail, name='detail') ﻻحظ أن هذا المسار يحمل اسمًا خاصًّا به، وقد عرّفناه من خلاله المعامل name. بهذه الطريقة يتعرّف Django على المسار المطلوب استخدامه في القوالب. واﻵن إن كنت ترغب في تغيير المسار المرتبط بهذا العرض إلى مسار آخر، وليكن polls/specifics/12/ على سبيل المثال، فيمكن تعديله ضمن ملف polls/urls.py بدلًا من تعديل المسار في القالب أو القوالب التي تم استخدامه فيها: url(r'^specifics/(?P<question_id>[0-9]+)/$', views.detail, name='detail'), استخدام نطاقات اﻷسماء للتمييز بين المسارات يتضمن مشروعنا هذا تطبيقًا واحدًا فقط وهو تطبيق الاقتراعات، ولكن المشاريع الحقيقية تتضمن عددًا كبيرًا من التطبيقات، فكيف يمكن لـ Django إذًا أن يميز بين أسماء المسارات في هذه الحالة؟ على سبيل المثال، يحتوي تطبيق الاقتراعات على عرض باسم detail، وقد يحتوي المشروع على تطبيق مدونة يتضمن عرضًا باسم detail أيضًا، فكيف يمكن لـ Django أن يتعرف على المسار المطلوب عند استخدام الوسم url في ملف القالب؟ اﻹجابة هي نطاقات اﻷسماء Namespaces. توجه إلى الملف polls/urls.py وأضف اسم التطبيق في بداية قائمة أنماط المسارات، ليصبح الملف بالصورة التالية: from django.conf.urls import url from . import views app_name = 'polls' urlpatterns = [ url(r'^$', views.index, name='index'), url(r'^(?P<question_id>[0-9]+)/$', views.detail, name='detail'), url(r'^(?P<question_id>[0-9]+)/results/$', views.results, name='results'), url(r'^(?P<question_id>[0-9]+)/vote/$', views.vote, name='vote'), ] واﻵن عدّل العبارة التالية في القالب polls/index.html: <li><a href="{% url 'detail' question.id %}">{{ question.question_text }}</a></li> لتصبح بالشكل التالي: <li><a href="{% url 'polls:detail' question.id %}">{{ question.question_text }}</a></li> ختامًا لا زالت هناك بعض اﻷمور اﻷساسية التي تنقص تطبيق الاقتراعات، فصفحات التطبيق غير منسّقة، كما أنّه لا يوفّر للمستخدم طريقة واضحة للتصويت على الاقتراعات. في الدرس القادم سنتعرّف على كيفية التعامل مع النماذج Forms بصورة مبسطة لتهيئة آلية التصويت على الاقتراعات، وسنتعرف كذلك على العروض العامة Generic views وسنرى كيف يمكن لهذه العروض أن تختصر الوقت والجهد. بعد ذلك سنقوم بإضافة التنسيقات الخاصة بتطبيق الاقتراعات بواسطة CSS وسنتعرف على مفهوم الملفات الساكنة Static Files في Django. المصدر: توثيقات Django

بعد أن تعرفنا في الدرس الأول على طريقة تثبيت Django وإنشاء مشروعنا الأول فيه، سنشرع في هذا الدرس في إنشاء تطبيقنا الأول والذي سيكون عبارة عن موقع بسيط للاقتراعات يتكون من قسمين: القسم الأول: واجهة يمكن للمستخدم أن يطلع من خلالها على الأسئلة المطروحة واختيار الإجابة التي يرغب فيها. أما القسم الثاني: لوحة تحكم يمكن من خلالها إضافة الأسئلة وتعديلها وحذفها وإضافة الأجوبة وغير ذلك من الأمور. المشاريع Projects والتطبيقات Applications قبل أن ندخل في تفاصيل إنشاء تطبيق الاقتراعات، لا بأس في الحديث بشكل موجز عن مفهومي "المشروع" Project و"التّطبيق" Application في Django. يمثّل المشروع تطبيق الويب الذي يتم إنشاؤه بواسطة Django، ويتم تعريفه من خلال ملف الإعدادات Settings، فكما رأينا في الدرس السابق فبعد تنفيذ الأمر: django-admin startproject mysite تم إنشاء حزمة بايثون تحتوي على ملفات settings.py و urls.py و wsgi.py، وعادة ما تتوسع هذه الحزمة بإضافة المزيد من الملفات مثل ملفات CSS والقوالب وما إلى ذلك من الأمور التي لا تكون مرتبطة بتطبيق معيّن. وعادة ما يكون مجلّد المشروع هذا (المجلد الذي يحتوي على الملف manage.py) حاويًا للتطبيقات التي يتم إنشاؤها بشكل مستقل، وهذه التطبيقات ما هي إلا حزم بايثون تعمل على تقديم بعض الخصائص وتؤدي بعض المهام، ويمكن استخدام هذه التطبيقات في مشاريع متعددة، وهذا ما يسمى بمبدأ قابلية إعادة الاستخدام re-usability. إنشاء تطبيق الاقتراعات ملاحظة: ابتدءًا من هذا الدرس فإن عبارة "مجلد المشروع" تعني المجلد الذي يحتوي على ملف manage.py. توجّه في سطر الأوامر إلى مجلد المشروع ثم اكتب الأمر التالي: python manage.py startapp polls يمكن الحصول على نفس النتيجة من خلال الأمر التالي: django-admin startapp polls بعد تنفيذ الأمر ستجد أنّ إطار العمل قد أنشأ مجلدًا جديدًا يحمل الاسم polls، ويتضمن عددًا من الملفات نستعرضها بشكل مختصر: init__.py__: هذا الملف مشابه للملف الموجود في مجلد المشروع، وهو ملف فارغ يعني وجوده أن هذا المجلد هو حزمة من حزم بايثون. admin.py: يمكن من خلال هذا الملف إدارة وتخصيص لوحة التحكم والتي تأتي جاهزة مع التطبيق. apps.py: يمكن من خلال هذا الملف إعداد التطبيق configuration لاستخدامه في مشاريع أخرى. models.py: سيتضمن هذا الملف النماذج التي يتعامل التطبيق معها، والتي تكون مسؤولة عن إنشاء جداول قواعد البيانات. tests.py: يمكن من خلال هذا الملف إجراء الاختبارات Tests على التطبيق. views.py: تضاف في هذا الملف العروض المسؤولة عن تحديد البيانات والمعلومات التي سيتم عرضها على المتصفح، وهي كذلك صلة الوصل بين المسارات والقوالب. مجلد migrations: سيستقبل هذا المجلد الملفات الناشئة عن عملية تهجير قاعدة البيانات. إعدادات المشروع يحتوي مجلد المشروع على ملف الإعدادات settings.py، وهو عبارة عن ملف بايثون يحتوي جميع الإعدادات الخاصة بالمشروع، وسنستعرض بعض محتويات هذا الملف بشكل موجز. BASE_DIR: متغير نصّي يقدّم مسار المجلد الأساسي للمشروع، ويمكن الاستفادة من هذا المتغير في تحديد مسارات المجلدات التي تحتوي على القوالب أو الملفات الساكنة وغيرها، وسنتعرف على طريقة استخدامه عند الحديث عن القوالب. SECRET_KEY: عبارة عن سلسلة نصية من حروف ورموز عشوائية يمكن الاستفادة منها في حماية التطبيق. DEBUG: متغير من نوع bool، ويمكن من خلاله التحكم في وضع التنقيح Debugging، حيث تظهر معلومات مفيدة عند حدوث الأخطاء، ولكن ينصح بتغيير قيمته إلى False عند نقل المشروع إلى بيئة الإنتاج. INSTALLED_APPS: عبارة عن قائمة تتضمن التطبيقات التي سيضمها المشروع الحالي، ويمكنك أن تلاحظ وجود عدد من التطبيقات المثبتة بشكل مسبق، مثل إدارة لوحة التحكم admin، والاستيثاق auth، والجلسات sessions وغيرها. TEMPLATES: عبارة عن قائمة تتضمن إعدادات القوالب المستخدمة في المشروع، وما يهمنا فيها هو العنصر DIRS والذي يتم من خلاله تعيين المسارات التي تحتوي على ملفات القالب. DATABASES: قائمة أخرى مسؤولة عن تحديد المعلومات اللازمة للتعامل مع قواعد البيانات، وسنتطرق إليها عند الحديث عن النماذج Models والاتصال بقواعد البيانات. LANGUAGE_CODE: يمكن من خلال هذا المتغير تحديد لغة واجهة لوحة التحكم، والإعداد الافتراضي هنا هو اللغة الإنكليزية، ولكن Django يدعم العديد من اللغات ومن ضمنها العربية، وإن كنت ترغب في استخدام اللغة العربية في عرض عناصر لوحة التحكم، فيمكنك تغيير قيمة هذا المتغير بالشكل التالي: LANGUAGE_CODE = 'ar' TIME_ZONE: يمكن من خلال هذا المتغيير تعيين المنطقة الزمنية التي سيستخدمها Django في دوال الوقت والتاريخ. ويمكن استبدال هذه القيمة حسب الرغبة. STATIC_URL: في هذا المتغير يتم تحديد مسار المجلد الذي يحتوي على الملفات الساكنة وهي ملفات CSS و Javascript والخطوط والصور وغيرها. كتابة العرض الأول العرض View عبارة عن دالة مكتوبة بلغة Python (أو صنف كما سنرى في الدروس اللاحقة) يمكن تلخيص عملها ببساطة في أنها تأخذ الطلبات Requests التي يرسلها العميل وتقوم بإرجاع الإجابة response والتي يمكن أن تكون على هيئة شيفرة بصيغة HTML، أو إعادة توجيه لصفحة أخرى، أو صفحة خطأ 404، أو ملف XML، أو صورة أو أي شي آخر. لنبدأ الآن بكتابة العرض الأول في مشروعنا، وللقيام بذلك افتح ملف polls/view.s.py في محرر النصوص المفضّل لديك، ثم امسح محتوياته واكتب الشيفرة التالية: from django.http import HttpResponse def index(request): html = "مرحبًا بك في تطبيق الاقتراعات، هذه هي الصفحة الرئيسية." return HttpResponse(html) في السطر الأول من هذه الشيفرة قمنا باستيراد الصنف HttpResponse من وحدة django.http، وهو المسؤول عن التعامل مع الاستجابة التي ترد على الطلب الذي أرسلناه إلى الخادوم من خلال الدالة index، وذلك عن طريق تمرير المعامل request عند تعريف الدالة. ستقوم هذه الدالة بإعادة العنصر HttpResponse والذي يحتوي على الإجابة، وهي في مثالنا هذا عبارة عن سلسلة نصية بسيطة. ملاحظة: في حال عدم ظهور الأحرف العربية بشكل صحيح، أضف السطر التالي إلى بداية ملف views.py: # -*- coding:utf8 -*- لنتمكن من مشاهدة النتيجة على المتصفح، يجب أن نربط هذا العرض بمسار معين؛ وللقيام بذلك توجه إلى الملف mysite/urls.py وعدّل محتوياته لتصبح بالشكل التالي: from django.conf.urls import url from django.contrib import admin from polls import views urlpatterns = [ url(r'^admin/', admin.site.urls), url(r'^polls/', views.index), ] يتضمن هذا الملف جميع المسارات التي سنستخدمها في المشروع، وهو بمثابة جدول لمحتويات الموقع. في البداية قمنا باستيراد محتويات ملف views.py الموجود في مجلد polls من خلال الشيفرة التالية: from polls import views من خلال هذه الشيفرة يمكنك أن تلاحظ أن Django يتعامل مع المجلد polls باعتباره حزمة من حزم بايثون، وذلك لاحتواءه على ملف init__.py__ كما ذكرنا سابقًا. بهذا الطريقة يمكننا الوصول إلى دالة index التي أنشأناها قبل قليل في ملف views.py الموجود في مجلد polls (أو حزمة polls لنكون أكثر دقة) وذلك تمهيدًا لربطها بالمسار الذي نرغب فيه. أضفنا كذلك الشيفرة التالية إلى قائمة urlpatterns: url(r'/polls', views.index), وهي عبارة عن دالة وظيفتها ربط المسار الذي نحدده في المعامل الأول بالعرض الذي نحدده في المعامل الثاني. لاحظ أن المسار عبارة عن سلسلة نصية مسبوقة بحرف r صغير وذلك لإخبار بايثون بأن يتعامل مع هذه السلسلة النصية على أنّها سلسلة خام raw، بمعنى أنه سيتم تجاوز جميع العلامات الخاصة المستخدمة في هذه السلسلة، وهذا ضروري جدًّا، لأن Django يستخدم التعبيرات النظامية Regular Expressions في تحديد المسارات وتمرير المتغيرات، وهذه التعبيرات تستخدم الكثير من الرموز التي يجب تجاوزها لتعمل الشيفرة بالشكل الصحيح. سنتعرف على المسارات وآلية عملها وكيفية استخدام التعبيرات النظامية، في الدروس اللاحقة. يمكنك الآن التوجه إلى مجلد المشروع وتشغيل الخادوم الخاص بـ Django عن طريق سطر الأوامر من خلال الأمر التالي: python manage.py runserver انتقل في المتصفح إلى العنوان التالي: http://127.0.0.1:8000/polls لتشاهد عبارة الترحيب في واجهة الموقع. يمكننا استخدام شيفرة HTML ضمن السلسلة النصية التي ترجعها دالة العرض، وللقيام بذلك افتح ملف polls/view.py وعدّله ليصبح بالشكل التالي: from django.http import HttpResponse def index(request): html = """ <html dir="rtl"> <head> <title>تطبيق الاقتراعات</title> </head> <body> <h1>تطبيق الاقتراعات</h1> <p>مرحبًا بك في تطبيق الاقتراعات، هذه هي الصفحة الرئيسية.</p> </body> </html> """ return HttpResponse(html) من المؤكد أن التطبيقات التي نراها على صفحات الإنترنت لا تتمتع بهذه البساطة الشديدة، وهذا يعني أن استخدام شيفرة HTML ضمن دالة العرض أمر غير عملي على الإطلاق، وهنا تظهر الحاجة إلى فصل هذه الشيفرات عن العروض وهذه هي وظيفة القوالب Templates والتي سنتعرف إليها في الدروس اللاحقة. خاتمة تعرفنا في هذا الدرس على مفهومي المشروع والتطبيق في Django، وقمنا بكتابة العرض الأول وتعرفنا بشكل مختصر على المسارات Urls. سنتعرف في الدرس القادم على كيفية التعامل مع قواعد البيانات من خلال النماذج Models، وكذلك سنتعرف على كيفية تهجير قواعد البيانات، وكذلك الاستعلام عن البيانات برمجيًا، وذلك لتهيئة قاعدة البيانات التي سنستخدمها في تطبيق الاقتراعات.

أقدّم بين أيديكم هذه السلسلة التي استلهمت فكرتها من كتب برمجة صغيرة مجّانيّة ومحبّبة، مثل كتاب The Little Book on CoffeeScript لمؤلّفه Alex MacCaw. لقد ألّفت هذه السلسلة لتعليم Angular بالطّريقة التي تمنّيت أن أتعلمها بها، ولذلك فهذه السلسلة معينك للانطلاق السريع مع Angular واستخدام هذه المكتبة الرائعة في عملك كمطوّر ويب. أسلوب هذه السلسلة مستلهم من مبدأ باريتو Pareto فهي تعلّمك جزءًا كبيرًا من نقاط قوّة Angular دون أن تثقل كاهلك بالكثير من تعقيداتها، وستتمكّن بعد إنهائك لهذه السلسلة من كتابة تطبيقات واجهة front-end قويّة، وستدهشك سهولة ذلك، بالرّغم من أنّ السلسلة لا تقدّم إلا جزءًا محدودًا ممّا عليك تعلّمه لاحتراف Angular بشكل كامل، لكنها ستمنحك الثّقة الكافية للقيام بذلك لأنّ خبرتك ستكون مبنيّة على التّجربة العمليّة أثناء قراءتك لدروسها، فهي بحدّ ذاتها صفحات ويب ديناميكيّة تحوي آخر نسخة من Angular وتستخدمها لتنفيذ جميع الأمثلة بشكل مباشر، وجميع الشّيفرات البرمجيّة تتيح التّعديل المباشر عليها ممّا يغيّر المخرجات مباشرة، وأتمنّى لو تقوم بكلّ التّجارب والتّعديلات التي تخطر على بالك عند كل مثال. إذا كنت ترغب في معرفة سبب كتابتي لهذه السلسلة يمكنك قراءة هذه المقدّمة إلى نهايتها فهي تتضمّن بعضًا من ذكرياتي مع Angular، ثم سنناقش أفضليّة استخدام Angular في مشاريعك. هل هي صعبة أم سهلة؟لقد عملت من قبل على تطبيقات معتمدة على Web MVC لما يزيد عن عشر سنوات، واستعملت الكثير من الأدوات بدءًا من Struts وانتهاءً بـSpring MVC مرورًا بـRuby on Rails وBackbone، حتّى أنّني قمت بكتابة كتاب Backbone and CoffeeScript لذا كان من الطّبيعي بالنّسبة لي أن أفترض أنّ تعلّم ِAngular سيكون بسيطًا بالنسبة لي، إلّا أنّ تقدّمي في تعلّمها واجه سدًّا كبيرًا من المصطلحات غير المألوفة بعد غوصي في توثيق هذه المكتبة، مصطلحاتٌ مثل transclusion، توجيه directive والمجال المعزول isolate scope، وكلّما قرأت أكثر في التّوثيق الرّسمي للّغة ودروسها تأكّدت أكثر بأنّني كنت أتوهّم عندما ظننت بأنّ Angular أداةٌ سهلة، وأتذكّر بشكل خاصّ مروري على العبارة التّالية: لن تجد العبارة السابقة هذه الأيام داخل توثيق اللّغة، والشّكر يعود للجهود الجادّة التي بذلها فريق ِAngluar لتحسين التّوثيق، وعلى أيّ حال فالاقتباس السّابق جعلني أشعر بالجهل وبدأت الشّكوك تراودني والقلق يساورني: هل هذه المكتبة مجال جديد كلّيّا عليّ؟ كانت الإجابة تأتيني من كلّ الجهات تقريبًا: إنّ ِAngular تقنيّة معقدّة، ولا مجال للعبث معها، ففي ملتقيات المبرمجين على Stack Overflow ومجموعة AngularJS على Google وفي كلّ مكان آخر، كانت تفاصيل هذه المكتبة محلّ النّقاشات المطوّلة، مع توثيقات مرعبة للمشاكل والأفخاخ والحيل فيها، فشمّرت عن ساعد الجد كأي محترف يحترم نفسه وقبلت هذا التّحدّي، ومع مرور الوقت أصبحت أكثر ألفة مع هذه المفاهيم والمصطلحات، وتقبّلت أنّ تعلّمي هذه الأداة سيكون بطيئًا، إلى أن جاء ذلك اليوم الذي شاهدت فيه مقابلة مع Miško Hevery مخترع Angular، وبعد ذلك اكتشفت حقيقة بسيطةً إلّا أنّها كانت شديدة الأهمّيّة: الهدف الأصليّ من Angular هو سهولة الاستخدام. لقد بيّن Hevery بأنّه أراد أن تكون Angular أداة ليستخدمها غير المبرمجين، ليتمكّنوا من بناء صفحات ويب ديناميكيّة باستخدامهم لنصوص تصريحية بسيطة، لقد اكتشفت بأنّني قد تعمّقت في الكثير من تفاصيل Angular دون أن أجني منها فائدة مكافئة للوقت والجهد المبذول، ورغم أنّ مشروع Angular ومجتمع Angular أصبحا معتمدين على بعضهما بشكل وثيق حيث تقدّم المكتبة التّحديات والتّعقيدات التي تشبع شغف هؤلاء، إلّا أنّه كان هناك طريق أفضل لاستخدام المكتبة كما أراد مخترعها، بعيدا عن مبدأ عملها المصنوع بعناية، وقد كان الصّواب بالنسبة إليّ الابتعاد عن هذه الأمور الدّاخليّة الدّقيقة وتركها آمنة لتقود كلّ شيء دون المساس بها، وبعد أن اعتمدت هذا المبدأ في التعامل معها وبالرّغم من وجود العديد من الأدوات الأخرى إلّا أنّ شمس Angular صارت تشرق لي عند مواجهة العديد من الحالات. هل تناسبك؟تعتمد إجابة هذا السّؤال على معرفتك لمشروعك بدقّة، فعليك معرفة فيما إن كان يحتاج بالفعل لمعالجة البيانات وإخراج HTML في طرف الزّبون، أم أنّك تخدع نفسك ببعض المتطلّبات الإضافيّة لتعطيها دافعًا لتعلّم أداة جميلة وجذّابة، فقد لا تلزمك Angular إن كان بإمكانك الاعتماد على بعض المعالجة من طرف الخادوم مع "رشّةٍ" من التّفاعل المعتمد على jQuery. ضع في حسابك أنّ Angular واسعة وتدعو للتشبّث بها، فبالرّغم من أنّنا ندعوها "مكتبة" إلا أنّ دعمها الذّاتي للـوحدات modules ولـحقن التّبعيّة dependency injection سيفرض على المطوّر طريقة إدارة مشروعه، وقد يُفضّل حلًّا آخر على Angular، ربّما سيختار أداة أقدم منها ومتميزةً بكونها الأفضل في وقتها، لكنّه قد يجد أنّه من الصّعب أو المستحيل أن تحلّ محلّ Angular، أضف إلى ذلك أنّك لن تحتاج إلى الدّعم الفنّي من فريق تطوير Angular إن لم تكن تنوي أن يصبح مشروعك كبيرًا بالقدر الّذي يعتبره مهندسو Google مثاليًّا. هناك مشكلة أخرى تظهر عندما تحاول دمج شيفرات Angular مع شيفرات غير Angular وتريدها أن تعمل إلى جانب تغليف Angular للبيانات أو آلية إخراج الصفحة فيها، سيكون عليك عندها الغوص في تفاصيل غامضة في Angular غوصًا عميقا، قارن ذلك مع Backbone التي تعد طبقة رقيقة فوق jQuery فهي أصغر وأقرب للفهم، وإن كان تطبيقك معتمدًا بشكل كبير على ملحقات jQuery فسيكون عليك استخدام Backbone لتزيد من التّحسين في تصميم تطبيقك. أخيرًا، إنّ لطريقة Angular الأساسيّة للرّبط ثنائي الاتجاه بين عناصر واجهة المستخدم وكائنات النمذجة حدودًا تعتمد على مدى تعقيد التّطبيق، وقد تشارك المطوّرون في Facebook خيبة أملهم بربط البيانات ثنائيّ الاتجاه فقالوا: وبالرّغم من كون مكتبة React الخاصة بـFacebook بالكاد تهتمّ بالإخراج ومن ثمّ فهي تعدّ حلّا جزئيًّا بالمقارنة مع Angular، إلّا أنّ تطبيقات طرف الزّبون التي تعتمد عليها تستحقّ التقدير حقًّا. أسباب هامة تدفعك لاستخدام Angularلا شك أنّ Angular هي أشهر مكتبات JavaScript المختصّة بحلول النّمذجة والعرض عالميًّا في هذه الأيام، فقد حصلت على أكثر من 33000 نجمة على GitHub، وربّما ازدادت أكثر من ذلك بكثير منذ وقت كتابة هذه السلسلة إلى اليوم، فقد تربّعت على قمّة قائمة الحلول المطروحة التي تمّت دراستها ومقارنتها بواسطة مشروع TodoMVC وسنناقش الآن بعض أسباب نجاح Angular. الإنتاجية الآنيةإذا كان مشروعك بحاجة إلى واجهة مستخدم معقّدة إلى حدّ ما لتقوم بعمليات إدارة البيانات CRUD على البيانات من طرف الزّبون، فإنّ Angular ستفي بوعدها لك بتحقيق إنتاجيّة شبه آنيّة، فبإضافتك لرشّةٍ من بعض الخصائص المميّزة غلى نصّ HTML الأصلي، والقليل من شيفرات Javascript، ستتمكّن من جعل صفحتك تتفاعل مع المستخدم، في حين كنت ستحتاج إلى الكثير من المهارات وبذل الجهود لتقوم بذلك باستخدام مكتبة أدنى مستوى. الألفةتعتمد Angular على كتابة شيفرات JavaScript السّهلة ونصوص مطابقة تقريبًا لتعليمات HTML، لقد قلت "تقريبًا" لأنّ Angular تقدّم عناصر وخصائص جديدة وبعض الشيفرات المستغربة، إلّا أنها بالمقارنة مع أنظمة القوالب الأخرى تبقى قريبةً جدًّا إلى HTML النّقيّة، وهذا يجعلها سهلة الفهم لأغلبية مطوري الويب. المرونةتتبنّى Angular التّوجّه الحالي نحو التكيف مع واجهات المستخدم في أطر عمل JavaScript، دون الكثير من التّضحية بإنتاجيّتها، فإن كنت تحبّ العمل مع أحد أطر العمل الشهيرة المختصة بواجهة المستخدم مثل Bootstrap فستتمكّن من الاستفادة من الإضافة المقدّمة من مشاريع طرف ثالث مثل AngularUI لتقوم بتكامل سهل. لذا سواء كنت تريد زخرفة صفحة ويب تقليديّة ببعض التّطبيقات التفاعلية هنا وهناك، أو كنت تريد تطوير تطبيقٍ كاملٍ وحيد الصّفحة فإن Angular ستكون الأفضل للعمل ضمن شروطك ومحدداتك. المعايير المستقبليةلا أدري أيّهما أكثر صحّة، إن كانت Angular متبصّرة بالمستقبل أو أنّ Google والدةَ Angular ستصنع المستقبل، إلا أنّه من الواضح أنّ استخدامك لـAngular سيكون طريقة ناجحة لتألف المعايير المقترحة مثل Web Components وأضف إلى ذلك أنّني أتوقّع بقاء Angular واستمرارها لأنّها تواكب ميزات JavaScript المرتقبة مثل Object.observe. مجتمع Angularلابدّ أنّ أحد أقوى الأسباب لاختيار Angular بدلًا من منافساتها هو أنّها الأكثر شيوعًا، فهي تُستخدم الآن في عدد غير محدود من مواقع الويب كثيرة الزيارة، ولكن تذكّر بأنّ الجري وراء الأغلبية ليس الصّواب دومًا وليس لكلّ النّاس ولا في كلّ الأحيان، وعليك أن تدرس متطلّبات مشروعك الحقيقيّة بعناية. عن هذه السلسلةلقد جاءتني فكرة الكتب التفاعلية منذ عدّة سنوات أثناء قراءتي لكتاب إلكترونيّ عن البرمجة باستخدام JavaScript على حاسوبي المحمول، فقد توجّب عليّ لتجربة أحد أمثلة الكتاب أن أقوم بتحميله من موقع النّاشر، ثم البحث عن موضع الملفّ الذي تم تحميله وإيجاد مكان لفكّ ضغطه، ثم الإبحار عبر الكثير من الملفّات إلى أن أعثر على الشّيفرة المطلوبة، وأفتحها أخيرًا في أحد المحرّرات، ثمّ أكتشف بأنّ عليّ إنشاء ملف HTML ليُشغّل السكربت، وبعد كلّ هذا لا تعمل الشيفرة وأكون قد ضيّعت وقتي في مطاردة أماكن الملفّات والارتباطات. لم كلّ هذا؟ إن كنت أقرأ كتابًا عن تقنية front-end على الحاسوب فهل عليّ أن أعاني كلّ تلك المعاناة لأشغّل المثال؟ لقد اكتشفت بعد مدّة قصيرة من ذلك النّسخةَ الأولى لكتاب Marijn Haverbeke المسمّى Eloquent JavaScript واكتشفت بأنّه بإمكاني استخدام مشروعه CodeMirror لأنشر رؤيتي الخاصّة: كتاب إلكترونيّ رائع المظهر، أنيق الحروف وجميل التّصميم، ولكن مع أمثلة حية قابلة للتّعديل والتّشغيل مباشرة من الدّرس ذاته، ولهذا ستجد جميع أمثلة السلسلة داخل محرّرات حيّة تفاعليّة، وستجد مخرجات هذه الشيفرات مباشرة تحت المثال داخل صندوق iframe. <div ng-app=""> <strong>The lucky number {{11+12}}</strong> </div> See the Pen angular-intro by Hsoub Academy (@HsoubAcademy) on CodePen. هيّا حاول تغيير المثال أعلاه الآن، رغم أنك لم تتعلم شيئًا بعد عن Angular، قم ببعض التغييرات على المثال وراقب التّغييرات. ماذا بعد؟سيأخذك الفصل الأوّل من هذه السلسلة في رحلة لطيفة للتّعرف على مبادئ Angular في القولبة templating من طرف الزّبون وفي الرّبط ثنائيّ الاتّجاه، وقد أقرّ العديد من المطوّرين المحترفين في ِAngular بأنهم استفادوا من هذا الفصل رغم أنّ جميع أمثلته بسيطة ويمكن فهمها بلمحة سريعة. ترجمة وبتصرّف للجزء الأول من كتاب: Angular Basics لصاحبه: Chris Smith.

بايثون (Python) لغة ممتازة لبرمجة الويب نظرا لمرونتها وأدائها العالي. أطُرُ الويب يمكن أن تجعل برمجة تطبيقات الويب أبسط بكثير لأنها توصل العديد من المكونات الضرورية مع بعضها للحصول على تطبيق قوي. في حين تهدف بعض أطر الويب إلى توفير كل شيء يمكن أن يرغب به المستخدم لتطوير تطبيق ما، هناك أطر أخرى تحاول البقاء بعيدا والاهتمام بالأهم، Bottle إطار للغة بايثون يندرج ضمن النوع الثاني. إنه بالفعل خفيف ومصغر، لكنه يجعل تطوير التطبيقات سهلا وسريعا. في هذا المقال، سنعرض طريقة ضبط واستعمال إطار العمل المصغّر Bottle لإنشاء تطبيقات ويب بسيطة وباستعمال لغة Python. كيفية تثبيت Bottleتثبيت Pythonإطار Bottle مبني على لغة Python وهي مثبتة مسبقا على أنظمة لينكس وOS X، أما بالنسبة لنظام Windows فيمكن تنصيب Python 2 عبر تحميلها من موقعها الرسمي. الجدير بالذّكر أن هذا الدّرس خاصّ بالإصدار الثاني من بايثون (Python 2.x). تثبيت وتفعيل بيئة وهميةسنثبت حزمة virtualenv لعزل مشروع بايثون الخاص بنا من بيئة بايثون الخاصة بالنظام. يمكننا فعل هذا بسهولة عبر تنصيب أداة إدارة الحزم الخاصة ببايثون واسمها pip. لتنصيب pip على Ubuntu يكفي تنصيب virtualenv مباشرة، فهي إحدى اعتمادياته: sudo apt-get update sudo apt-get install python-virtualenv بالنسبة لأنظمة OS X و Windows يمكن تنصيبه بتنصيب pip ثم تنصيب virtualenv عبرها: أو احفظ هذا الملف على جهازك، ثم نفذ الأمر التالي على نافذة الأوامر بالنسبة لـ Windows أو Terminal بالنسبة لـِ Mac OS X، في كلا النظامين، ستحتاج أن تنفذ الأمر التالي بصلاحيات المدير: python get-pip.pyبرنامج virtualenv عبارة عن بيئة وهمية لبايثون لتنصيب مكتبات بايثون في معزل عن بيئة بايثون الحقيقية على النظام، هذا مهم جدا لعزم اعتماديات مشروع الويب الخاص بك وما يحتاجه من حزم عن الحزم العامة المنصبة على كافة النظام، تحتوي بيئة مشاريع بايثون الخاصة بنا على حزمنا فقط، لكي لا تؤثر على نظام التشغيل ككل. سننشئ مجلد المشاريع projects في مجلد Home أو ماشابه، ثم نقوم بإنشاء بيئة وهمية في هذا المجلد، بالنسبة لـ Windows يمكن تنفيذ هذه الأوامر باستخدام طرفية PowerShell: mkdir ~/projects cd ~/projects virtualenv --no-site-packages venv هذا سينشئ مجلدا باسم venv داخل مجلد المشاريع. لقد تُبِّتت بعض أدوات بايثون داخل هذا المجلد وأنشِئَت بنية مجلد لتثبيت أدوات إضافية. يجب علينا تفعيل البيئة الوهمية قبل بداية العمل على مشروعنا : source venv/bin/activateالأمر المُخرَج سيتغير لعكس حقيقة أننا نقوم بعمليات داخل بيئة وهمية الآن. وسيكون كالتالي: (venv)user@Hostname:~/projects$إذا أردت الخروج من البيئة الوهمية، يمكنك في أي وقت كتابة الأمر التالي : deactivateملاحظة: لا تخرج من البيئة الوهمية حاليا. تثبيت Bottleأداة pip تُمكنك من تثبيت حزم بايثون بسهولة من دليل حزم بايثون Python package index، وهو مستودع مُفهرس لمكتبات بايثون. إذا أردنا البحث عن حزم بايثون المتعلقة بـِ Bottle، يمكن تنفيذ: pip search bottleسنبدأ بتثبيت حزمة Bottle فقط: pip install bottleبعد إنتهاء العملية، سنتمكن من استخدام إطار Bottle داخل تطبيقاتنا. إنشاء أول تطبيق باستخدام Bottleكمعظم الأطر، Bottle يطبق نسخة من النمط البرمجي MVC .MVC اختصار لـِ Model, view, controller نموذج،عرض،هيكل؛ وهو أمر للفصل بين عوامل مختلفة بين واجهة المستخدم والمنطق البرمجي. النموذج model تمثيل لمجموعة من البيانات وهو مسؤول عن تخزين، استعلام، وتحديث البيانات.العرض view مسؤول عن كيفية تقديم المعلومة للمستخدم. ويُستخدم لتشكيل وضبط عرض البيانات.الهيكل controller هو مركز العمليات الرئيسي للتطبيق، والذي يقرر كيفية الإجابة لطلبات المستخدم.تطبيقات bottle يمكنها أن تكون بسيطة للغاية. في شكلها البسيط يمكنها تنفيذ جميع المكونات في ملف واحد. سنقوم بإنشاء تطبيق "مرحبا بالعالم" لعرض كيفية العمل. باستعمال محررك المفضل (في هذه الحالة سنستعمل محرر سطر الأوامر nano، بالنسبة لنظام Windows يمكنك استعمال محرر مرئي)، أنشئ تطبيق بايثون باسم hello.py: nano hello.pyفي هذا الملف، سنقوم أولا باستدعاء بعض الوظائف من حزمة Bottle. الأمر الذي سيمكننا من استخدام أدوات الإطار داخل تطبيقنا: from bottle import route, runهذا السطر يخبر برنامجنا بأننا نحتاج إلى استيراد المسار route وتشغيل النماذج modules من حزمة Bottle. نموذج run الذي قمنا باستيراده يمكن أن يُستعمل لتشغيل التطبيق في خادوم التطوير، الشيء الذي يعتبر جيداً لرؤية نتائج برنامجك بسرعة. نموذج route مسؤول عن إخبار التطبيق بالتعامل مع أي من طلباتURL باستخدام أي من دوال بايثون.تطبيقات Bottle تنفّذ التوجيه routing باستدعاء دالّة بايثون واحدة لكلّ طلب من طلبات URL. وتقوم بعد ذلك بإرجاع نتائج الدالة للمُستخدم. نستطيع إضافة توجيه سيُوافق رابط URL /hello from bottle import route, run @route('/hello')هذا التوجيه سيوافق رابط URL /hello عندما يتمّ طلب هذا المسار على الخادوم. ستُنفّذ الدّالة التّابعة مباشرة: # -*- coding: utf-8 -*- from bottle import route, run @route('/hello') def hello(): return u"<h1>مرحباً بالعالم</h1>"ملاحظات: السطر # -*- coding: utf-8 -*- مسؤولٌ عن دعم اليونيكود وبالتالي اللغة العربية، فهو يخبر مفسر بايثون أن هذا الملف به أحرف unicode غير الأحرف الانجليزية.حرف u (اختصارًا لـ unicode) قبل النص العربي مهم أيضا لإخبار بايثون أن هذه السلسلة النصية بالضبط تحتوي على أحرف يونيكود وبالتالي يعامل السلسلة النصية بطريقة خاصة.هذه الدّالة بسيطة جدّاً، لكنّها كافية لإكمال المتطلّب الوحيد لدالّة توجيه: تقوم بإرجاع قيمة يُمكن عرضها على المتصفّح. في هذه الحالة، القيمة عبارة عن نص HTML. يمكننا حذف وسم h1 وستُعرض نفس القيمة بشكل غير منسّق. أخيراً، نحتاج إلى تشغيل تطبيقنا باستعمال خادوم التّطوير development server: # -*- coding: utf-8 -*- from bottle import route, run @route('/hello') def hello(): return u"<h1>مرحباً بالعالم</h1>" run(host='0.0.0.0', port=8080)هذا السطر سيُشغل الخادوم. بتمرير المعامل 'host='0.0.0.0 الأمر سيقوم بإرجاع المحتوى لأي حاسوب، وليس فقط الحاسوب المحليّ. هذا مهم بما أن تطبيقنا مستضاف عن بعد. معامل port يقوم بتحديد المنفذ الذي سنستخدمه. يُمكننا تشغيل التطبيق بتنفيذ الأمر: python hello.pyيمكنك زيارة التطبيق بمتصفح الويب عن طريق الذهاب إلى عنوان IP الخاصّ بك (إن كنت تعمل على خادوم) أو localhost إن كنت تعمل محليا، متبوعاً برقم المنفذ الذي قمنا باختياره (8080)، متبوعا بالتوجيه الذي أنشأناه (hello/): http://localhost:8080/helloسيظهر لك التالي: يُمكن إيقاف الخادوم في أي وقت بالضغط على CTRL-C في نافذة الطرفيّة أو سطر الأوامر. تطبيق مبدأ MVCلقد نفّذنا الآن تطبيقنا الأول. لقد كان بسيطاً بالتأكيد، ولكنّه لا ينفّذ مبادئ MVC، أو لا يقوم بشيء مثير للاهتمام. لنحاول جعله تطبيقاً أكثر تعقيداً هذه المرّة. إنشاء النموذجلنبدأ بنموذجنا، هذا هو الجزء الخاص بالتّعامل مع تخزين البيانات في برنامجنا. يمكن لـ Bottle بسهولة استخدام مجموعة من الواجهات الخلفية backends للبيانات باستعمال الإضافات. سنستخدم ملف SQLite لقاعدة بيانات التطبيق. هذه قاعدة بيانات بسيطة للغاية مُصمّمة للعمليّات الخفيفة التي يُمكن أن يقوم بها برنامجنا. ثبّت أولا SQLite، على Ubuntu يمكن ذلك عبر الأمر التالي: sudo apt-get install sqliteبالنسبة لـ Windows و OS X يمكن تثبيتها من على موقعها الرسمي. نحتاج كذلك إلى تحميل وتثبيت إضافة Bottle التي تُخوّلنا لاستعمال قواعد البيانات هذه: pip install bottle-sqliteالآن نحن نمتلك المكوّنات الأساسية، نستطيع أن ننشئ قاعدة بيانات بسيطة لتخزين بياناتنا فيها. سنقوم بإنشاء ملفّ بايثون لتوليد قاعدة بيانات SQLite مع بعض البيانات بداخلها عندما ننفّذ الملفّ. يُمكننا فعل الأمر على مترجم بايثون، لكنّ هذه الطريقة تجعل الأمر أسهل للتكرار. سننشئ ملفا باسم picnic_data.py. nano picnic_data.pyهنا نقوم باستيراد حزمة SQLite. بعد ذلك، يمكننا تنفيذ أمر يُنشئ جدولا ويدخل بيانات فيه. وفي الأخير، ننّفذ التغييرات: # -*- coding: utf-8 -*- import sqlite3 db = sqlite3.connect('picnic.db') db.execute("CREATE TABLE picnic (id INTEGER PRIMARY KEY, item CHAR(100) NOT NULL, quant INTEGER NOT NULL)") db.execute("INSERT INTO picnic (item,quant) VALUES ('خبز' , 4')") db.execute("INSERT INTO picnic (item,quant) VALUES ('جبن', 2)") db.execute("INSERT INTO picnic (item,quant) VALUES ('عنب', 30)") db.execute("INSERT INTO picnic (item,quant) VALUES ('كعك', 1)") db.execute("INSERT INTO picnic (item,quant) VALUES ('مشروبات', 4)") db.commit()احفظ الملفّ وأغلقه يُمكننا تنفيذ الملفّ، الشيء الذي سينشئ ملفّ قاعدة بيانات باسم نزهة.db داخل المُجلّد: python picnic_data.py نموذج تطبيقنا الآن مكتمل. يمكننا الآن استنتاج أن النموذج يملي على التطبيق كيفية تعامل جزء التحكم مع البيانات. إنشاء هيكل التّطبيقبعد أن أنشأنا قاعدة بيانات التّطبيق، يمكننا البدء في تطوير تطبيقنا الرئيسي. هذه العمليّة ستكون وظيفة الهيكل بشكل أساسي. وسيكون الملفّ الأكثر شبها بتطبيقنا الأول. أنشئ ملفّا باسم picnic.py لحفظ تطبيقنا الرئيسي: nano picnic.pyداخل هذا الملفّ، نحتاج إلى استيراد بعض الأشياء من حزمة Bottle، تماما كما سبق. نحتاج إلى بعض النّماذج الإضافية التي لم يسبق لنا أن استخدمناها. إضافة إلى ذلك، نحتاج إلى استيراد وظيفة SQLite: # -*- coding: utf-8 -*- import sqlite3 from bottle import route, run, templateتالياً، سنقوم بتعريف توجيه يوافق مسار URL على الشكل التالي picnic/: # -*- coding: utf-8 -*- import sqlite3 from bottle import route, run, template @route('/picnic')سنضيف دالّة للاتصال بقاعدة البيانات، لتحضر البيانات من الجدول، والاتصال مع العرض View لتقديم الصفحة. وفي الأخير، ستُرجع المخرج إلى المُستخدم. # -*- coding: utf-8 -*- import sqlite3 from bottle import route, run, template @route('/picnic') def show_picnic(): db = sqlite3.connect('picnic.db') c = db.cursor() c.execute("SELECT item,quant FROM picnic") data = c.fetchall() c.close() output = template('bring_to_picnic', rows=data) return outputبعد ذلك سنضيف أمر run لكي نقوم بتشغيل التطبيق: # -*- coding: utf-8 -*- import sqlite3 from bottle import route, run, template @route('/picnic') def show_picnic(): db = sqlite3.connect('picnic.db') c = db.cursor() c.execute("SELECT item,quant FROM picnic") data = c.fetchall() c.close() output = template('bring_to_picnic', rows=data) return output run(host='0.0.0.0', port=8080)احفظ وأغلق الملفّ. نقوم بالاتصال مع قاعدة البيانات باستعمال: db = sqlite3.connect('picnic.db')نقوم باستعلام قاعدة البيانات وجلب جميع القيم بالأسطر الأربعة الموالية. السطر الذي نقوم فيه بالإتصال إلى "العرض" لتشكيل البيانات هو: output = template('bring_to_picnic', rows=data)السطر يقوم بالاتصال بقالب (عرض) باسم bringtopicnic.tpl لتشكيل البيانات وتقديمها. حيث يقوم بتمرير المتغير data لمتغير القالب rows. سنقوم بإنشاء ملفّ القالب هذا في المرحلة التالية. إنشاء العرضالآن نحن نمتلك كلّا من النموذج والهيكل، الشيء الوحيد المتبقّي هو إنشاء العرض. يُمكن القيام بهذا بسهولة بالاستعانة بمحرك القوالب المُدمج مع Bottle. سيبحث التطبيق عن قالب موافق للاسم الذي عرّفناه في الدّالة السابقة، الملفّ يجب أن ينتهي ب .tpl يُمكن للملفّ أن يكون إمّا في مجلّد المشروع، أو داخل مجلّد باسم "view”. أنشئ ملفّا باسم يوافق الاسم الذي عرّفناه في دالّة القالب: nano bring_to_picnic.tplفي هذا الملفّ، يُمكننا دمج HTML والبرمجة معاً. سيكون ملفّنا بسيطا جدّاً. سنقوم باستعمال حلقة تكرار لإنشاء جدول يقوم بعرض بيانات النّموذج: <html dir="rtl" style="font:droid arabic naskh"> <body> <h1>أشياء لإحضارها إلى النّزهة</h1> <table> <tr><th>المكوّن</th><th>الكميّة</th></tr> %for row in rows: <tr> %for col in row: <td>{{col}}</td> %end </tr> %end </table> </body> </html>هذه الأسطر ستقوم بتقديم صفحتنا بصيغة HTML. لغة القالب التي رأينها هي ببساطة لغة بايثون. متغيّر row الذي قمنا بتمريره إلى القالب مُتاح للاستخدام عند تصميم المُخرجات. يُمكننا كتابة أسطر بايثون بتقديم علامة "%". يُمكننا الوصول إلى المُتغيّرات بداخل HTML باستخدام "{{var}}". احفظ الملفّ وأغلقه. مشاهدة النتائجتطبيقنا مكتملٌ الآن ويمكننا تشغيل الملفّ الرئيسي: python picnic.pyيمكننا رؤية النتائج بزيارة عنوان IP متبوعا برقم المنفذ، متبوعاً بالتوجيه picnic/ http://localhost:8080/picnic ختاماًإلى هذه النقطة، يجب أن تكون قادراً على رؤية كيف يُمكنك بناء تطبيقات معقّدة باستخدام الإطار المُصغر والبسيط Bottle. رغم أنّ أمثلتنا بسيطة، إلا أنّك الآن تستطيع بسهولة أن تطوّر تطبيقات إلى القيام بوظائف متقدّمة. نظام إضافات Bottle يعدّ أيضاً أصلاً مهمّاً. الإضافات مُشارَكةُ بنشاط في المجتمع وإضافة وظائف أكثر تعقيداً لتطبيقك يُمكن أن يُنفّذ بسهولة باستخدام الإضافات. هناك طريقة سهلة للبحث عن الإضافات وهي عن طريق استعمال الأمر: pip search bottleهذا سيُعطيك فكرة عن بعض الإضافات الأكثر شعبية. ترجمة -وبتصرّف- للمقال: How To Use the Bottle Micro Framework to Develop Python Web Apps.

تمّ التطرّف في الجزء الأوّل من هذا الشرح إلى الخطوات الأوّليّة في بناء صفحة باستخدام إطار عمل 3 Bootstrap، في الجزء الثّاني، سيتم استكمال تصميم الصّفحة بدءًا من الشعار وانتهاءً بذيل الصّفحة. الشعار (Logo) سيتمّ إضافة الشعار إلى رأس الصّفحة كما في التّالي: <header> <a href="/"><img src="images/logo.png" alt="Logo"></a> </header>سيتمّ الاكتفاء بإدراج صورة الشعار وبدون إضافة أية تنسيقات. نموذج البحث سيتمّ الاستفادة من بعض مُكوّنات Bootstrap بغرض إنشاء نموذج البحث، سيتمّ إنشاء نموذج ضمن السطر في رأسيّة الصّفحة، كما سيتمّ إزاحة هذا النموذج إلى جهة اليمين، على أنّ يَملك هذا الحقل الصنف form-control وعنونة (label) وسيحتوي النموذج على المُكوّن (input groups)، ومهمته إزالة الفراغ بين حقل الإدخال النصّي (input text) والزر (button)، كما لو أنّه يقوم بدمجهم كعنصر واحد، ولذلك سيتمّ استخدام الصنف input-group، ولعنصر الإدخال (input) سيتمّ استخدام الصنف form-control ولقسم الزر سيتمّ استخدام الصنف input-group-btn. ومن ثُمّ سيتمّ إضافة الصنف btn-primary للزر، والذي سيمنح الزر لونًا بارزًا وحدودًا بارزةً. <header> ... <form name="search" action="#" method="get" class="form-inline form-search pull-right"> <div class="input-group"> <input class="form-control" id="searchInput" type="text" name="search" placeholder="Search"> <div class="input-group-btn"> <button type="submit" class="btn btn-primary">GO</button> </div> </div> </form> </header>سيتمّ في الخطوة التّالية ضبط عرض صندوق البحث إلى القيمة 200px: body { ... .wrapper { ... header { ... .form-search { width: 200px; } } } }شريط التنقل سيتمّ استخدام مُكوّنات التنقل، والّتي تحتوي على قائمة بالروابط، وسيتم استخدام الصنف navbar-nav لشريط التنقل، والذي يُطبّق تنسيقًا خاصًّا لشريط التنقل. <nav class="navbar navbar-default"> <ul class="nav navbar-nav"> <li><a href="/home/">Home</a></li> <li class="active"><a href="/about/">About us</a></li> <li><a href="/services/">Services</a></li> <li><a href="/partners/">Partners</a></li> <li><a href="/customers/">Customers</a></li> <li><a href="/projects/">Projects</a></li> <li><a href="/careers/">Careers</a></li> <li><a href="/contact/">Contact</a></li> </ul> </nav>كما سيتمّ إضافة هذه المُتغيّرات وذلك بهدف جعل تنسيق شريط التنقل أكثر توافقيّةً مع الصّفحة. /* navigation menu height */ @navbar-height: 37px; /* additional paddings */ @nav-link-padding: 10px 30px; /* background for menu items */ @navbar-default-bg: @panel-bg; /* text color in the menu items */ @navbar-default-link-color: #b2b2b2; /* for the mouse hover - the same color */ @navbar-default-link-hover-color: @navbar-default-link-color; /* background of the active menu item */ @navbar-default-link-active-bg: @brand-primary; /* text color of the active menu item */ @navbar-default-link-active-color: #fff;كما سيتمّ إضافة التعديلات التّالية على ملفّ التنسيق الخاصّ بالمشروع، بغرض تخصيص الخط المُستخدم لشريط التنقل، وذلك بجعل الحروف كبيرة (uppercase)، وضبط نوع وحجم الخط. body { ... .wrapper { ... .navbar a { text-transform: uppercase; font: 14px @brand-font; } } }عنوان الصّفحة (Page Header) سيتمّ استخدام الصنف heading مع عنوان الصّفحة: <div class="heading"> <h1>About us</h1> </div>وبالتنسيق التّالي: body { ... .wrapper { ... .heading { height: 40px; background: transparent url(../images/h1-bg.png); margin: 30px 0; padding-left: 20px; h1 { display: inline-block; color: #7e7e7e; font: normal 40px/40px 'Oswald', sans-serif; background: url(../images/bg.png); margin: 0; padding: 0 10px; text-transform: uppercase; } } } }تمّ في الشيفرة السابقة تعيين صورة خلفية للعنوان (h1)، وتنسيق الخط، ليظهر العنوان بالشكل السابق. القائمة الفرعيّة (Submenu) لن يتمّ استخدام المُكوّن navigation مع القائمة الفرعيّة، حيثُ أنّه لا يناسب التنسيق، بدلًا من ذلك سيتمّ استخدام المُكوّن group list، وكل عنصر من هذا المكوّن سيملك الصنف list-group-item. مع الانتباه أنّ القائمة الفرعيّة يجب توضع داخل الوسم aside: <aside class="col-md-7"> <ul class="list-group submenu"> <li class="list-group-item active">Lorem ipsum</li> <li class="list-group-item"><a href="/donec/">Donec tincidunt laoreet</a></li> <li class="list-group-item"><a href="/vestibulum/">Vestibulum elit</a></li> <li class="list-group-item"><a href="/etiam/">Etiam pharetra</a></li> <li class="list-group-item"><a href="/phasellus/">Phasellus placerat</a></li> <li class="list-group-item"><a href="/cras/">Cras et nisi vitae odio</a></li> </ul> </aside>إن الإعدادات الخاصّة بالمكوّنات تظهر أنّ جميع القوائم المُجمّعة (grouped lists) تستخدم خلفيّة وحدود المكوّن panel: @list-group-bg: @panel-bg; @list-group-border: @panel-inner-border;ومن ثُمّ سيتمّ تطبيق التنسيقات التّالية على القائمة الفرعيّة: body { ... .wrapper { ... .submenu { margin-bottom: 30px; li { display: list-item; font: 300 14px @brand-font; list-style-position: inside; list-style-type: square; padding: 10px; text-transform: uppercase; &.active { color: @brand-primary; } a { color: @text-color; text-decoration: none; &:hover { color: @text-color; } } } } } }تمت إضافة هامش سفلي باستخدام margin-bottom، والتخفيف من حدّة الخط، وتغيير التنسيق الخاصّ بعناصر القائمة باستخدام الخاصّيّة list-style-type لتكون مُربّعة (square)، ومن أجل الروابط تمّ ضبط اللّون، والحروف لتكون حروفًا كبيرةً، الجدير بالذكر هنا أنّ الإشارة & (ampersand) هي جزء من صياغة LESS، والّتي سيتمّ استبدالها بالمُحدّد الأب (parent selector). الشريط الجانبي (Sidebar)سيتمّ إضافة صورة تُشير إلى عنوان مكتب العمل، وذلك أسفل القائمة الفرعيّة. سيتمّ استخدام المُكوّن panel من مكوّنات Bootstrap، وذلك باستخدام الأصناف الفرعيّة منه وهي panel-primary من أجل تلوين العنوان، و يحتوي هذا المكوّن على كتلة علويّة وتستخدم الصنف panel-heading، وكتلة المُحتوى وتستخدم الصنف panel-body، كما سيتمّ استخدام الصنف img-responsive لصورة خريطة الموقع، وذلك من أجل الحصول تجاوبيّة لها على مُختلف قياسات الشاشة (responsiveness). <aside class="col-md-7"> ... <div class="panel panel-primary"> <div class="panel-heading">Our offices</div> <div class="panel-body"> <img src="images/map.png" class="img-responsive" alt="Our offices"> </div> </div> </aside>تمّ بالفعل سابقًا ضبط لون لخلفيّة المكوّن panel وذلك في خصائص Bootstrap وذلك عبر المُتغيّر panel-bg، والآن ما سيتمّ عمله هو تغيير لون الحدود الخاصّة به، وسيتم استخدام اللون الرمادي المُعيّن سابقًا بالمُتغيّر @panel-inner-border: @panel-primary-border: @panel-inner-border;سيتم الحاجة أيضًا إلى تغيير بعض التنسيق الافتراضي للمكوّن panel، وهذه التغييرات لا يُمكن تغييرها بواسطة المُتغيّرات: .panel { box-shadow: none; .panel-heading { font: 14px @brand-font; text-transform: uppercase; padding: 10px; } .panel-body { padding: 10px; } }تمّ في الشيفرة السابقة إزالة الظل الخاصّ بالمكوّن panel وضبط الحشوة padding وضبط الخط. الاقتباس (Quotation)سيتمّ الشروع بالعمل على تصميم المحتوى، وفي البداية سيتمّ إضافة الاقتباس: يشبه هذا الجزء إلى حدٍ كبير المُكوّن Jumbotron، والذي سيتمّ الاستفادة منه هنا، وذلك عبر إضافته داخل عمود المُحتوى (col-md-17): <section class="col-md-17"> <div class="jumbotron"> <blockquote> <p> "Quisque in enim velit, at dignissim est. nulla ul corper, dolor ac pellentesque placerat, justo tellus gravida erat, vel porttitor libero erat." </p> <small>John Doe, Lorem Ipsum</small> </blockquote> </div> </section>باستخدام مُتغيّرات المكوّن jumbotron سيتمّ تعيين اللّون الأبيض للخط، وضبط لون الخلفية إلى قيمة المُتغيّر @brand-primary وهو ذو القيمة #29c5e6: @jumbotron-bg: @brand-primary; @jumbotron-color: #fff;كما سيتمّ إضافة بعض التنسيق: body { ... .wrapper { ... .jumbotron { border-radius: 0; padding: 0; margin: 0; blockquote { border-left: none; p { font: 300 italic 33px @brand-font; text-transform: uppercase; margin-bottom: 0; } small { text-align: right; color: #1D8EA6; font: 300 20px @brand-font; &:before { content: ''; } } } } } }تمّ إزالة الزوايا الدائريّة باستخدام الخاصّيّة border-radius، وتنسيق الخط ليتناسق مع بقيّة التصميم. المُحتوى الرئيسي (Main content) تمّ بالفعل إتمام جميع التنسيقات اللازمة للنص الخاصّ بالمُحتوى، وعليه فإن كل ما يجب عمله هو إضافة ثلاثة فقرات (paragraphs) مع النصّ الخاصّ بها: <p>Lorem ipsum dolor sit amet...</p> <p>Donec vel nisl nibh...</p> <p>Donec vel nisl nibh...</p>سيتمّ في الخطوة التّالية إضافة صورتين، أسفل المُحتوى الكتابي السابق، ولذلك سيتمّ استخدام عمودين: <div class="row"> <div class="col-md-12"> <img src="images/about-1.png" alt="" class="thumbnail"> </div> <div class="col-md-12"> <img src="images/about-2.png" alt="" class="thumbnail"> </div> </div>يُعطي الصنف thumbnail تنسيقًا جميلًا للصور، ومن دون إضافة المزيد من التنسيق، ما سيتمّ عمله فقط هو تعديل الحشوة (padding) ولون الحدود (border): @thumbnail-padding: 1px; @thumbnail-border: #c9c9c9;القسم الخاصّ بفريق العمل أوّلًا، سيتمّ إضافة رأسيّة هذا القسم (header): <h2>Our team</h2>وبالتنسيق التّالي: body { ... .wrapper { ... h2 { background: none repeat scroll 0 0 #29C5E6; color: #fff; font: 300 30px @brand-font; padding: 0 10px; text-transform: uppercase; } } }سيتمّ إضافة div وبالصنف team، والذي يحتوي بطاقات فريق العمل، حيثُ أنّ كل كرت هو عمود وبعرض مساوي إلى أربعة أعمدة من النّظام الشبكي، وجميعها تحتوي على إزاحة بعمود واحد ما عدا الكرت الأول من كل صفّ، وتُطبّق هذه الإزاحة باستخدام الصنف col-sm-offset-1، ويتألّف كل كرت من صورة والوصف الوظيفي لكل عضو من أعضاء الفريق. <div class="team"> <div class="row"> <div class="col col-sm-4"> <img src="images/team/Doe.jpg" alt="John Doe" class="thumbnail"> <div class="caption"> <h3>John Doe</h3> <p>ceo</p> </div> </div> <div class="col col-sm-4 col-sm-offset-1"> <img src="images/team/Pittsley.jpg" alt="Saundra Pittsley" class="thumbnail"> <div class="caption"> <h3>Saundra Pittsley</h3> <p>team leader</p> </div> </div> ... </div> <div class="row"> <div class="col col-sm-4"> <img src="images/team/Nobriga.jpg" alt="Ericka Nobriga" class="thumbnail"> <div class="caption"> <h3>Ericka Nobriga</h3> <p>art director</p> </div> </div> <div class="col col-sm-4 col-sm-offset-1"> <img src="images/team/Rousselle.jpg" alt="Cody Rousselle" class="thumbnail"> <div class="caption"> <h3>Cody Rousselle</h3> <p>senior ui designer</p> </div> </div> ... </div> </div>سيتمّ إضافة التنسيق التّالي إلى ملفّ التنسيق بهدف مُلائمة المُحتوى السابق مع التصميم: body { ... .wrapper { ... .team { .row { margin-top: 20px; .col { white-space: nowrap; .thumbnail { margin-bottom: 5px; } } .col-sm-offset-1 { margin-left: 3.7%; } .caption { h3 { font: 300 16px @brand-font; margin: 0; } p { font: 300 14px @brand-font; color: @brand-primary; margin: 0; } } } } } }تمّ التعديل في الشيفرة السابقة على الصنف col-sm-offset-1، حيثُ أنّ الهامش الخاصّ به واسعٌ نوعًا ما، ولذلك تمّ تحديده بالقيمة 3.7%. تصميم ذيل الصّفحةيتألّف ذيل الصّفحة من أربعة أجزاء رئيسية: تغذية توتير (Twitter feed)خريطة الموقع (site map)روابط الشبكات الاجتماعيّة (social links)الشعار مع نص حقّ النشر (logo with copyright text) سيتمّ في البداية إنشاء الحاوية الرئيسيّة لذيل الصّفحة، والأعمدة الخاصّة بكل جزء: <footer> <div class="container"> <div class="row"> <div class="col-md-8 col-xs-12 twitter"></div> <div class="col-md-4 col-xs-12 sitemap"></div> <div class="clearfix visible-sm visible-xs"></div> <div class="col-md-6 col-xs-12 social"></div> <div class="col-md-6 col-xs-12 footer-logo"></div> </div> </div> </footer>سيتمّ تنسيق ذيل الصّفحة على الشكل التّالي: footer { background: #7e7e7e; color: #dbdbdb; font-size: 11px; overflow: hidden; .container { height: 110px; padding: 10px 0; } }يَظهر وسم ذيل الصّفحة (footer) على كامل عرض الشاشة، بينما تظهر الحاوية الداخليّة بالمُنتصف، ولاصطفاف العناصر داخل ذيل الصّفحة تم استخدام نظام الأعمدة. تغدية توتير (Twitter feed) صياغة تغذية توتير هي على الشكل التّالي: <div class="col-md-8 col-xs-12 twitter"> <h3>Twitter feed</h3> <time datetime="2015-03-03"><a href="#">03 mar</a></time> <p>In ultricies pellentesque massa a porta. Aliquam ipsum enim, hendrerit ut porta nec, ullamcorper et nulla. In eget mi dui, sit amet scelerisque nunc. Aenean aug</p> </div>والتنسيق هو على الشكل التّالي: body { ... footer { ... .container { ... h3 { border-bottom: 1px solid #919191; color: #ffffff; font-size: 14px; line-height: 21px; font-family: @brand-font; margin: 0 0 10px; text-transform: uppercase; } p { margin: 5px 0; } .twitter { p { padding-right: 15px; } time a { color: #b4aeae; text-decoration: underline; } } } } }تمّ تخصيص تنسيق جميع العناوين بذيل الصّفحة وذلك للخط والهوامش، واستخدام الحروف الكبيرة، وذلك باستخدام الخاصّيّة text-transform، ومن أجل الرابط الّذي يعرض التاريخ، تمّ ضبط اللّون والخطّ السفلي (underlining). خريطة الموقع (Sitemap)تتألّف خريطة الموقع من عمودين متساويين محتويان على روابط: <div class="col-md-4 col-xs-12 sitemap"> <h3>Sitemap</h3> <div class="row"> <div class="col-md-12"> <a href="/home/">Home</a> <a href="/about/">About</a> <a href="/services/">Services</a> </div> <div class="col-md-12"> <a href="/partners/">Partners</a> <a href="/customers/">Support</a> <a href="/contact/">Contact</a> </div> </div> </div>سيتمّ تطبيق التنسيق التّالي، والذي يَخصّ اللّون والخطّ والهامش الخاصّ بالروابط: body { ... footer { ... .container { ... a { color: #dbdbdb; } .sitemap a { display: block; font-size: 12px; margin-bottom: 5px; } } } }الأيقونات الاجتماعيّة سيتمّ وضع جميع الروابط (الأزرار) داخل قسم وبالصنف social: <div class="col-md-4 col-xs-12 social"> <h3>Social networks</h3> <a href="http://twitter.com/" class="social-icon twitter"></a> <a href="http://facebook.com/" class="social-icon facebook"></a> <a href="http://plus.google.com/" class="social-icon google-plus"></a> <a href="http://vimeo.com/" class="social-icon-small vimeo"></a> <a href="http://youtube.com/" class="social-icon-small youtube"></a> <a href="http://flickr.com/" class="social-icon-small flickr"></a> <a href="http://instagram.com/" class="social-icon-small instagram"></a> <a href="/rss/" class="social-icon-small rss"></a> </div>وللتنسيق الروابط ضمن ذيل الصّفحة سيتمّ تطبيق التّالي: body { ... footer { ... .container { ... .social { .social-icon { width: 30px; height: 30px; background: url(../images/social.png) no-repeat; display: inline-block; margin-right: 10px; } .social-icon-small { width: 16px; height: 16px; background: url(../images/social-small.png) no-repeat; display: inline-block; margin: 5px 6px 0 0; } .twitter { background-position: 0 0; } .facebook { background-position: -30px 0; } .google-plus { background-position: -60px 0; } .vimeo { background-position: 0 0; } .youtube { background-position: -16px 0; } .flickr { background-position: -32px 0; } .instagram { background-position: -48px 0; } .rss { background-position: -64px 0; } } } } }تمّ في الشيفرة السابقة استخدام أسلوب ما يُعرف بالاسم sprites، وهو أسلوب شائع يُستخدم في تسريع تحميل الصّفحة وذلك عن طريق جمع مجموعة من الصور في صورة واحدة، وعليه فالمتصفّح سيطلب صورة واحدة بدلًا من عدّة صور، أي طلبًا واحدًا بدلًا من طلبات عدّة، في المشروع الحالي تمّ تقسيم الأيقونات الاجتماعيّة إلى صورتين الأولى بالاسم social.png والثانية بالاسم social-small.png، واستخدام كلْ منها كخلفيّة باستخدام الخاصّيّة background وتحديد موضع كل خلفيّة باستخدام الخاصّيّة background-position، على أنّ يتمّ التبديل بين كل رابط وما يخصّه من شعار. نص حقّ النشرسيتمّ استخدام صورة ذات رابط للشعار، وفقرة (paragraph) أسفله مع نصّ حق النشر. ستكون الصياغة على الشكل التّالي: <div class="col-md-8 col-xs-12 footer-logo"> <a href="/"><img src="images/footer-logo.png" alt="Whitesquare logo"></a> <p>Copyright © 2015 Whitesquare.</p> </div>سيتمّ تنسيق هذا القسم بشكل مُشابه للقسم السابق، مع اختلاف وحيد، وهو الإزاحة إلى جهة اليمين: body { ... .footer { ... .container { ... .footer-logo { float: right; margin-top: 20px; font-size: 10px; text-align: right; a { text-decoration: underline; } } } } }الختاميكون إلى هنا قد تمّ الانتهاء من تصميم كامل الصّفحة، يُمكن الوصول إلى الملفّات المصدريّة الخاصّة بالمشروع بتحميلها أو استعراض تصميم المشروع من هنا. ترجمة – وبتصرّف – للمقال Page layout with Bootstrap 3 part 2.