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

يفتقر تطبيق الاقتراعات الذي نعمل على إنشائه إلى آلية جيّدة للتصويت على الأسئلة التي يتم عرضها للمستخدم، لذا يجب علينا توفير استمارة تتيح للمستخدم التصويت على الإجابة التي يرغب بها. إضافة إلى ذلك، سنتعرف في هذا الدرس على العروض العامة التي تهدف إلى اختصار الوقت والجهد عبر التخلّص من العمليات المتكررة بصورة دائمة، مثل جلب البيانات من قاعدة البيانات وعرض النتائج في صفحة مستقلة. وفي نهاية الدرس سنتعرف على الملفات الساكنة وسنضيف بعض التنسيقات إلى تطبيق الاقتراعات. إنشاء استمارة بسيطة يفترض أن يكون المستخدم قادرًا على اختيار إحدى الإجابات الخاصة بسؤال معين، ولكن قالب detail بشكله الحالي لا يوفّر هذا اﻷمر، لذا سنحتاج إلى إضافة استمارة إلى هذا القالب. توجّه إلى الملف polls/detail.html في مجلد القوالب templates ثم أضف إليه الشيفرة التالية: <h1>{{ question.question_text }}</h1> {% if error_message %}<p><strong>{{ error_message }}</strong></p>{% endif %} <form action="{% url 'polls:vote' question.id %}" method="post"> {% csrf_token %} {% for choice in question.choice_set.all %} <input type="radio" name="choice" id="choice{{ forloop.counter }}" value="{{ choice.id }}" /> <label for="choice{{ forloop.counter }}">{{ choice.choice_text }}</label><br /> {% endfor %} <input type="submit" value="صوّت" /> </form> يعمل السطر الأول على جلب نص السؤال ووضعه داخل وسم <h1> لعرضه بشكل واضح وكبير. في السطر الثاني يتم التحقق مما إذا كان المتغير error_message يحمل قيمة أم ﻻ، فإن كان كذلك يتم عرض هذه القيمة وإلا فلا، سنستخدم هذا المتغير بعد قليل في العرض المسؤول عن التصويت، حيث سيحمل هذا المتغير قيمة نصية وهي عبارة عن رسالة نخبر المستخدم فيها أنّه لم يقم باختيار أي إجابة من الإجابات المعروضة. في السطر الثالث أنشأنا استمارة يتم توليد قيمة الحدث action فيه بصورة ديناميكية، وذلك باستخدام الوسم url والمسار vote والمتغير question.id والذي يمثّل الرقم المعرف للسؤال، وستكون طريقة إرسال الحدث هي POST، وبما أننا نعتمد هذه الطريقة، فعلينا الانتباه إلى حماية المعلومات من تزوير الطلب عبر المواقع Cross-site request forgery والمعروف اختصارًا بـ CSRF. ولكن لا تقلق، يوفّر Django نظامًا سهل الاستخدام لتجنّب هذه المشكلة. باختصار، يجب عليك وضع الوسم {% csrf_tocken %} في أي استمارة تعتمد طريقة POST ﻹرسال اﻷحداث. تعمل الحلقة for على إضافة زر اختيار Radio button إلى الإجابات الخاصة بالسؤال الذي اختاره المستخدم، ويتم جلب هذه الإجابات من باستخدام العبارة question.choice_set.all. والآن لنقم بإنشاء العرض الذي سيتحكم في البيانات المرسلة إلى الخادوم. أعتقد أن سير العمل في Django قد أصبح واضحًا في هذه المرحلة، ففي البداية نقوم بتعريف المسار، ثم نربط هذا المسار بالعرض الذي سيكون مسؤولًا عن القيام بأي شيء نرغب به، وبعد ذلك نربط هذا العرض بالقالب الذي سيظهر النتائج. وقد قمنا فعلًا بالخطوة الأولى من سلسلة الخطوات هذه في الدرس الرابع من هذه السلسلة عندما بدأنا الحديث عن المسارات، حيث يتضمن ملف polls/urls.py المسار التالي: url(r'^(?P<question_id>[0-9]+)/vote/$', views.vote, name='vote') هذا المسار مرتبط بالعرض view والذي قمنا بإنشائه في الدرس نفسه: def vote(request, question_id): return HttpResponse("أنت تصوت على السؤال %s." % question_id) لنقم الآن بكتابة الشيفرة المسؤولة عن عملية التصويت ضمن هذا العرض، لذا توجّه إلى ملف views.py وأضف الشيفرة التالية في بداية الملف: from django.http import HttpResponseRedirect from django.core.urlresolvers import reverse from .models import Choice, Question ثم عدّل دالة vote لتصبح بالشكل التالي: def vote(request, question_id): question = get_object_or_404(Question, pk=question_id) try: selected_choice = question.choice_set.get(pk=request.POST['choice']) except (KeyError, Choice.DoesNotExist): return render(request, 'polls/detail.html', {'question':question, "error_message": "لم تقم بالتصويت على السؤال"}) else: selected_choice.votes += 1 selected_choice.save() return HttpResponseRedirect(reverse('polls:results', args=(question.id,))) لنتكلم عن الشيفرة السابقة بشيء من التفصيل، فهناك عدد من الأمور الجديدة فيها: request.POST هو عنصر شبيه بالقاموس يتيح الوصول إلى البيانات المرسلة من الاستمارة بواسطة اسم المفتاح، وفي حالتنا هذا فإن request.POST['choice'] سوف يرجع قيمة المعرّف الخاص بالجواب الذي اختاره المستخدم، وتكون هذه القيمة على هيئة سلسلة نصية. وجدير بالذكر أن Django يقدّم عنصرًا آخر باسم request.GET ويستخدم عندما تكون طريقة إرسال البيانات في الاستمارة هي GET. يطلق العنصر request.POST['choice] خطأً مفتاحيًا KeyError وهذا النوع من الأخطاء يُطلق عندما لا يكون المفتاح المطلوب (ضمن القاموس) موجودًا ضمن مجموعة المفاتيح المتوفرة، وفي تطبيقنا ينطلق هذا الخطأ عندما ﻻ يختار المستخدم أي إجابة من الإجابات المعروضة أمامه، ويعمل على إعادة المستخدم إلى صفحة التصويت مرة أخرى، ولكن هذه المرة مع إضافة العبارة: “لم تقم بالتصويت على السؤال” إلى المتغير error_message، وبعد أن أصبح هذا المتغير يحمل قيمة معينة، سيقوم قالب detail بعرض الرسالة في المكان المناسب. إن تمت عملية التصويت بنجاح يتم إضافة صوت واحد إلى الأصوات الخاصة بالإجابة المختارة من قبل المستخدم، وقد استخدمنا الصنف HttpResponseRedirect بدلًا من الصنف HttpResponse لإعادة توجيه المستخدم إلى صفحة النتائج. هذا الصنف في الواقع هو أحد الأصناف الفرعية للصنف HttpResponse ويأخذ معاملًا واحدًا وهو عنوان URL الذي ستتم إعادة التوجيه إليه. والهدف من استخدام هذا الصنف هو تجنّب إرسال البيانات مرتين في حال ضغط المستخدم على زر الرجوع في المتصفح، وينصح باستخدام هذا الصنف في كل مرة يتم فيها التعامل بنجاح مع بيانات POST، وهذا الأمر ليس خاصًا بـ Django فقط، بل هو من الممارسات الجيدة في مجال تطوير الويب باستخدام أي لغة برمجية. استخدمنا الدالة reverse() في مشيّد الصنف HttpResponseRedirect لنتجنّب الإدخال اليدوي للمسار الذي نرغب بإعادة توجيه المستخدم إليه. يأخذ المعامل الأول في هذه الدالة اسم العرض أو اسم نمط URL المطلوب إعادة التوجيه إليه. في هذا المثال سيتم توجيه المستخدم إلى المسار الذي يحمل اسم polls:results، ولكن هذا المسار يتضمن متغيّرًا، لذا سنخبر Django بأن يأخذ قيمته من المتغيّر question.id وذلك من خلال المعامل args. بمعنى أنّه لو اختار المستخدم السؤال الذي يحمل الرقم 3، فإن الصنف HttpResponseRedirect سيعيد السلسلة النصية التالية: polls/3/results/ حيث أن قيمة question.id في هذه الحالة هو 3. بعد أن يقوم المستخدم بالتصويت على سؤال معين، تعمل دالة العرض vote() على إعادة توجيهه إلى صفحة النتائج الخاصة بذلك السؤال، فلنقم إذًا بكتابة دالة العرض الخاصّة بالنتائج. توجّه إلى ملف polls/views.py وعدّل الدالة results لتصبح بالشكل التالي: def results(request, question_id): question = get_object_or_404(Question, pk=question_id) return render(request, 'polls/results.html', {'question': question}) والآن، قم بإنشاء القالب المسؤول عن عرض النتائج. في مجلد templates/polls/ أنشئ الملف results.html، وأضف إليه الشيفرة التالية: <h1>{{ question.question_text }}</h1> <ul> {% for choice in question.choice_set.all %} <li>{{ choice.choice_text }} -- {{ choice.votes }} vote{{ choice.votes|pluralize }}</li> {% endfor %} </ul> <a href="{% url 'polls:detail' question.id %}">صوّت مرة أخرى</a> والآن توجّه إلى العنوان التالي في متصفحك بعد تشغيل الخادوم الخاص بـ Django: 127.0.0.1:8000/polls/1/ وستحصل على نتيجة مشابهة لهذه: وبعد التصويت سيتم توجيهك إلى صفحة النتائج: وفي حال عدم التصويت على أي إجابة والضغط على زرّ التصويت، تظهر رسالة الخطأ بالشكل التالي: العروض العامة Generic Views لنلق نظرة على ملف views.py بعد إضافة جميع الدوال إليه: from django.shortcuts import render, get_object_or_404 from django.http import HttpResponseRedirect from django.core.urlresolvers import reverse from .models import Choice, Question def index(request): latest_question_list = Question.objects.order_by('-pub_date')[:5] return render(request, 'polls/index.html', {'latest_question_list': latest_question_list}) def detail(request, question_id): question = get_object_or_404(Question, pk=question_id) return render(request, 'polls/detail.html', {'question': question}) def results(request, question_id): question = get_object_or_404(Question, pk=question_id) return render(request, 'polls/results.html', {'question': question}) def vote(request, question_id): question = get_object_or_404(Question, pk=question_id) try: selected_choice = question.choice_set.get(pk=request.POST['choice']) except (KeyError, Choice.DoesNotExist): return render(request, 'polls/detail.html', {'question':question, "error_message": "لم تقم بالتصويت على السؤال"}) else: selected_choice.votes += 1 selected_choice.save() return HttpResponseRedirect(reverse('polls:results', args=(question.id,))) هل لاحظت أمرًا ما؟ الدالتان detail() وresults() متشابهتان كثيرًا، وفي الواقع الفارق الوحيد بينهما هو القالب الذي يرتبط بكل دالة. إضافة إلى ذلك فإن هاتين الدالتين إضافة إلى دالة index() تقوم بعمل واحد وبسيط، وهو عرض مجموعة من المعلومات على المتصفح. تمثل هذه العروض حالة شائعة جدًّا في عملية تطوير الويب، وهي الحصول على البيانات من قاعدة البيانات بالاستناد إلى معامل يتم تمريره في عنوان URL في المتصفح، ثم تحميل قالب معين، ثم تصيير ذلك القالب على متصفح الإنترنت. لقد ذكرنا في بداية هذه السلسلة أنّ إطار العمل Django يركّز على مبدأ عدم التكرار، وقد رأينا هذا بشكل واضح عند استخدامنا للدوال المختصرة render() و get_object_or_404(). كذلك يوفّر Django في حالتنا هذه طريقة مختصرة للتعامل مع هذه العمليات الشائعة، وهي العروض العامّة. تعمل هذه العروض على اختصار الأنماط المتكررة من الشيفرات إلى درجة لا تعود فيها بحاجة إلى كتابة شيفرة بايثون لكتابة التطبيق. ولاستخدام العروض العامّة يتوجّب علينا إجراء بعض التعديلات البسيطة على شيفرتنا السابقة، ويمكن تلخيص هذه التعديلات بالنقاط التالية: تعديل أنماط URL. الاستغناء عن بعض العروض التي لسنا بحاجة إليها بعد الآن. كتابة عروض جديدة بالاعتماد على عروض Django العامة. تعديل أنماط URL توجّه إلى ملف polls/urls.py وعدّله بالشكل التالي: from django.conf.urls import url from . import views app_name = 'polls' urlpatterns = [ url(r'^$', views.IndexView.as_view(), name='index'), url(r'^(?P<pk>[0-9]+)/$', views.DetailView.as_view(), name='detail'), url(r'^(?P<pk>[0-9]+)/results/$', views.ResultsView.as_view(), name='results'), url(r'^(?P<question_id>[0-9]+)/vote/$', views.vote, name='vote'), ] لاحظ أنّنا استبدلنا <question_id> بـ <pk> في مساري detail و results، وسنتعرف على سبب ذلك بعد قليل. تعديل العروض التعديلات التي سنجريها على العروض ستشمل دوال index(), detail(), results() أما دالة vote() فستبقى دون تغيير: from django.shortcuts import get_object_or_404, render from django.http import HttpResponseRedirect from django.core.urlresolvers import reverse from django.views import generic from .models import Choice, Question class IndexView(generic.ListView): template_name = 'polls/index.html' context_object_name = 'latest_question_list' def get_queryset(self): return Question.objects.order_by('-pub_date')[:5] class DetailView(generic.DetailView): model = Question template_name = 'polls/detail.html' class ResultsView(generic.DetailView): model = Question template_name = 'polls/results.html' لاحظ كيف استغنينا بشكل كامل عن الدوال الثلاثة سابقة الذكر لتحلّ محلّها أصناف تحمل أسماءً مشابهة، ونظرًا لاستخدام الأصناف في هذا النوع من العروض، فإنّها تحمل اسم العروض المستندة إلى الأصناف Class based views. لقد استخدمنا نوعين من أنواع العروض العامة، وهما ListView و DetailView. يلخّص العرض اﻷول عملية عرض جميع العناصر، في حين يلخّص العرض الثاني عملية عرض التفاصيل المرتبطة بعنصر معيّن. يحتاج كل عرض عامٍّ إلى التعرّف على النموذج الذي سيتعامل معه، ويتم التصريح عن ذلك في المعامل model. إلى جانب ذلك، يطلب العرض DetailView أن يتم إسناد قيمة المفتاح الرئيسي المأخوذة من عنوان URL إلى متغير يحمل الاسم pk، لهذا السبب قمنا بتبديل question_id بالاسم الجديد في ملف المسارات urls.py. يبحث العرض DetailView بصورة افتراضية عن القالب المرتبط به في المسار <app name>/<model_name>_detail.html، وهذا يعني أنّ هذا العرض سيستخدم القالب polls/question_detail.html بشكل تلقائي. ويمكن تجاوز هذه القيمة التلقائية من خلال تعيين اسم القالب باستخدام المعامل template_name. ينطبق الأمر ذاته على العرض ListView والذي سيستخدم بشكل تلقائي القالب polls/question_list.html. بقي أن نشير إلى أنّنا كنا نزوّد كل قالب بمتغيرات السياق التي سيستخدمها، وفي مثالنا هذا كانت المتغيرات هي question و latest_question_list. عند استخدام العروض العامّة يتم تزويد العرض DetailView بالمتغير question تلقائيًا، وذلك ﻷننا نستخدم النموذج Question، حيث يستطيع Django تحديد اسم مناسب لمتغيرات السياق بناء على النموذج الذي يرتبط بالعرض العام. ويمكن تجاوز القيمة التلقائية هذه بسهولة وذلك بإسناد اسم المتغير الذي نرغب به إلى المعامل context_object_name، وبهذا نخبر Django بأنّنا نرغب باستخدام هذا الاسم بدلًا من الاسم الذي سينشئه بصورة تلقائية وهو في هذه الحالة question_list. كما يمكنك الإبقاء على الاسم الافتراضي question_list إن كنت ترغب في ذلك، ولكن هنا عليك تغيير اسم المتغير في أي مكان يرد فيه ضمن القوالب. الملفات الساكنة Static Files يبدو تطبيقنا بشعًا أليس كذلك؟ لنقم إذًا بإضافة بعض التنسيقات البسيطة إليه، ولنتعرف على مفهوم الملفات الساكنة. إلى جانب ملفات HTML التي ينشئها الخادوم، تحتاج تطبيقات الويب بشكل عام إلى بعض الملفات اﻹضافية - مثل الصور وملفات جافا سكربت وملفات CSS - لعرض صفحات الويب بشكل منسّق ومرتّب، ويطلق Django على هذه الملفات اسم الملفات الساكنة. سنبدأ أولًا بإنشاء مجلد باسم static في مجلد polls الرئيسي، ثم أنشئ داخل المجلد static مجلّدًا جديدًا باسم polls. بمعنى آخر يجب أن يكون مسار ملف CSS بالشكل التالي: polls/static/polls/style.css. كما هو الحال مع القوالب، فإن Django يبحث بنفس الطريقة عن الملفات الساكنة، واستخدام هذه المجلدات هو أمر تنظيمي يتيح لـ Django التمييز بين الملفات الساكنة الخاصة بكل تطبيق. والآن توجّه من خلال محرّر النصوص إلى ملف style.css وأضف إليه الشيفرة التالية: li a { color: green; text-decoration: none; font-size: 1.3em; } والآن توجّه قالب index.html وأضف الشيفرة التالية في بداية الملف: {% load staticfiles %} <link rel="stylesheet" type="text/css" href="{% static 'polls/style.css' %}" /> يعمل الوسم load staticfiles في بداية الملف على تحميل الوسم static المسؤول بدوره عن توليد عنوان URL المطلق للملف الساكن المطلوب. والآن أعد تحميل الصفحة الرئيسية وستلاحظ أن الأسئلة قد تلونت باللون اﻷخضر. ولإضافة صورة للخلفية قم بإنشاء مجلد images في نفس المجلد الذي يحتوي الملف style.css ثم ضع فيه الصورة التي ترغب في جعلها خلفية للصفحة، وعلى فرض استخدام صورة باسم background.gif أضف الشيفرة التالية إلى ملف style.css: body { background: white url("images/background.gif") no-repeat right bottom; } أعد تحميل الصفحة الرئيسية، وستلاحظ أن الصورة قد أصبحت خلفية للصفحة. من الجدير بالذكر أنّه لا يمكن استخدام الوسم {% static %} استخدام داخل الملفات الساكنة والتي لا يتم توليدها بواسطة Django، لذا يجب استخدام المسارات النسبية وليست المطلقة لربط الملفات الساكنة بعضها ببعض. ختامًا تعرّفنا في هذا الدرس على كيفية استخدام نماذج الاستبيان في Django بصورة مبسطة، واستخدمنا بعد ذلك العروض العامّة التي تختصر الكثير من الوقت والجهد، وفي النهاية تعرّفنا على مفهوم الملفات الساكنة وكيفية استخدامها في تطبيقات Django. في الدرس القادم وهو الدرس اﻷخير ضمن هذه السلسلة، سنتحدّث بشيء من التفصيل عن لوحة التحكم التي يتم إنشاؤها بصورة تلقائية مع كل مشروع في Django. المصدر: توثيقات Django

تحدثنا في الدرسين السابقين عن كيفية تنصيب وإعداد إطار العمل Django على أنظمة التشغيل المختلفة، وتعرفنا كذلك على مفهومي المشروع والتطبيق، وقمنا بكتابة العرض الأول وتعرفنا بشكل مختصر على المساراتUrls. وفي الجزء الثالث من هذه السلسلة، سنتطرق إلى النماذج Models وكيفية التعامل مع قواعد البيانات من خلال Django، وسنتعرف خلال الدرس على طريقة ربط قواعد البيانات المختلفة مع Django، وكيفية إنشاء النماذج والتعامل معها وسنتطرق كذلك إلى مفهوم تهجير قواعد البيانات Migration، وسننشئ النموذج الخاص بتطبيق الاقتراعات والذي سيحتضن الأسئلة الخاصة بالاقتراع إضافة إلى الإجابات المرتبطة بالسؤال. النماذج Models أشرنا في الدروس السابقة إلى أن إطار العمل Django يتبع مبدأ العمل MVT، ويشير الحرف M هنا إلى النماذج Models، ويمكن تعريف النماذج بشكل مبسط على أنها وصف للبيانات الموجودة في قاعدة البيانات باستخدام لغة Python، وبمعنى آخر تمثّل النماذج في Django بنية قاعدة البيانات، أي ما ستحصل عليه من إجراء الأمر CREATE TABLE ولكن بلغة Python بدلًا من SQL. يستخدم Django النماذج في التواصل مع قواعد البيانات من خلال تنفيذ أوامر SQL خلف الكواليس وتقديم النتائج التي ترد من هذه الأوامر على هيئة بنية من البيانات تمثل الصفوف في جداول قاعدة البيانات. ولهذا الأسلوب في التعامل مع قواعد البيانات بعض الفوائد، فكتابة النماذج بلغة Python يزيد في الانتاجية، إذ لن يكون المبرمج مضطرًا إلى اتباع قواعد لغة أخرى أثناء العمل على التطبيق ويكون العمل مقتصرًا على لغة python، كما يسهل هذا الأسلوب متابعة النماذج وتتبع التغييرات الحاصلة عليها من خلال أنظمة تتبع الإصدارات كـ Git وغيرها، إضافة إلى ذلك تقدم نماذج Python بعض أنواع البيانات غير المتوفرة في SQL كالبريد الإلكتروني وعناوين URL وغيرها. ربط Django مع قواعد البيانات يستطيع Django التعامل مع أنواع مختلفة من أنظمة قواعد البيانات، ومن أشهرها SQLite، MySQL، PostgreSQL و Oracle. وفي مشروعنا هذا سنستخدم قواعد بيانات SQLite والتي تعتبر الخيار الأبسط والأسهل في حالة المشاريع البسيطة والصغيرة ويتم تثبيتها عند تثبيت Python وهذا يعني عدم الحاجة إلى تثبيت أي حزم إضافية، كما أنها ليست بحاجة إلى خادوم خاص تعمل من خلاله. يمكن اختيار نوع قاعدة البيانات التي سيعمل عليها المشروع من خلال ملف الإعدادات settings.py، وذلك ضمن القاموس DATABASES. يستخدم Django قواعد بيانات SQLite بشكل افتراضي، وستجد قاموس DATABASES بالشكل التالي: DATABASES = { 'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': os.path.join(BASE_DIR, 'db.sqlite3'), } } يتطلب ربط Django بقواعد البيانات الأخرى كـ MySQL و PostgreSQL تثبيت حزم الربط الخاصة بكل نوع منها، وإضافة العناصر ‘USER’، ‘PASSWORD’، و’HOST’ إلى القاموس، ويمكن التعرف إلى الحزم المطلوبة لكل نوع من أنواع قواعد البيانات في توثيقات Django. إنشاء النموذج الأول سيعتمد تطبيق الاقتراعات على نموذجين فقط هما نموذج الأسئلة ونموذج الإجابات، وسيتضمن النموذج الأول السؤال وتاريخ نشره، أما النموذج الثاني فسيتضمن الإجابات ومجموع الأصوات على كل إجابة، وسترتبط كل إجابة بسؤال معين. افتح ملف models.py في محرر النصوص المفضل لديك، ثم أضف الأسطر التالية: class Question(models.Model): question_text = models.CharField(max_length=200) pub_date = models.DateTimeField('date published') class Choice(models.Model): question = models.ForeignKey(Question) choice_text = models.CharField(max_length=200) votes = models.IntegerField(default=0) يمكن أن نلاحظ أن كل نموذج في هذا الملف قد تم تمثيله بصنف والذي يمثل بدوره جدولًا في قاعدة البيانات، ويتضمن كل صنف عددًا من المتغيرات التي يمكن استخدامها في شيفرة Python حسب الحاجة إليها، كما تمثل اسم العمود في قاعدة البيانات. تمثل أسماء المتغيرات التي استخدمناها في الشيفرة السابقة أسماء الأعمدة في قواعد البيانات، وسنستخدم هذه الأسماء في شيفرة Python وستظهر كذلك في لوحة التحكم التي سنتحدث عنها مفصّلًا في الدروس القادمة، ويمكن التحكم في طريقة عرض هذه الأسماء في لوحة التحكم وذلك باستخدام معامل يجب تعيين قيمته قبل أي معامل آخر، كما فعلنا مع المتغير pub_date أعلاه، وبهذه الطريقة سيظهر هذا الحقل في لوحة التحكم بالاسم date published وليس pub_date. نلاحظ في الشيفرة السابقة أيضًا أننا عرّفنا علاقة تربط بين الإجابات وبين السؤال الخاص بها، وذلك باستخدام ForeignKey والتي تخبر Django بأن كل إجابة ترتبط بسؤال واحد فقط. تمتلك بعض أنواع الصنف Field عددًا من المعاملات الإلزامية، كما هو الحال مع CharField والذي يتطلب تحديد العدد الأقصى للحروف من خلال max_length. وبطبيعة الحالة تمتلك هذه الأصناف بعض المعاملات الاختيارية، كما هو الحال مع IntegerField الذي أضفنا إليه قيمة افتراضية مساوية للصفر من خلال default=0. يتم تمثيل كل حقل من حقول قاعدة البيانات بـ instance للصنف Field، مثل CharField لحقول الحروف، و DateTimeField لحقول التاريخ والوقت. يقدّم Django عددًا كبيرًا ومتنوعًا من أنواع الحقول، نورد فيما يلي بعضًا منها: الحقل الوظيفة BooleanField يتضمن قيمتي True و False، وعادة ما يكون مرتبطًا بمربع الاختيار Checkbox. CharField يستخدم هذا الحقل لإضافة السلاسل النصية Strings القصيرة والمتوسطة الحجم. DateField يستخدم للتعبير عن التاريخ. DateTimeField يستخدم للتعبير عن التاريخ الوقت. DecimalField يتيح استخدام الأرقام العشرية التي تحتوي على فواصل. EmailField عبارة عن حقل حرفي `CharField` ولكنه قادر على التحقق من أن القيمة المدخلة تمتلك صيغة بريد إلكتروني سليمة. FileField يستخدم هذا الحقل لاحتواء الملفات المرفوعة. IntegerField يتيح استخدام الأرقام الصحيحة، ويمكن استخدام الأرقام من -2147483648 إلى 2147483647 بشكل آمن مع أنظمة قواعد البيانات المختلفة. GenericIPAddressField عبارة عن عنوان IPv4 أو IPv6 على هيئة سلسلة نصية. SlugField حقل Slug. TextField يستخدم في لإضافة السلاسل النصية الطويلة. TimeField يستخدم للتعبير عن الوقت. URLField عبارة عن حقل حرفي يتضمن عنوان URL. تفعيل النموذج تستطيع الشيفرة السابقة القيام بأمور كثيرة، حيث يمكن لـ Django أن: ينشئ جدولًا جديدًا خاصًّا بتطبيقنا هذا وذلك بتنفيذ العبارة CREATE TABLE. إنشاء واجهة برمجية API خاصة يمكن من خلالها التعامل مع قاعدة البيانات التي تم إنشاؤها. ولكن قبل أن يشرع Django بأداء هذه المهام، يجب علينا تثبيت تطبيق polls في مشروعنا وذلك من خلال إدراج اسمه ضمن قائمة INSTALLED_APPS في ملف الإعدادات settings.py، لذا توجه إلى هذا الملف وابحث عن القائمة التي تحمل الاسم INSTALLED_APPS، ثم عدل عناصرها لتصبح بالشكل التالي: INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'polls', ] توجّه الآن إلى مجلد المشروع عن طريق سطر الأوامر ونفّذ الأمر التالي: python manage.py makemigrations polls يفترض أن ترى النتيجة التالية في سطر الأوامر: Migrations for 'polls': polls/migrations/0001_initial.py: - Create model Choice - Create model Question - Add field question to choice وظيفة الأمر makemigrations هي إخبار Django بأنّك قد أجريت بعض التعديلات على النماذج وأنّك ترغب في حفظ هذه التعديلات على هيئة ملف تهجير يُحفظ على القرص الصلب كملف بايثون في مجلد migrations، تحت اسم: 0001_initial.py. والآن نفّذ الأمر التالي في سطر الأوامر وذلك لتنفيذ التهجيرات وإنشاء الجداول ضمن قاعدة البيانات: python manage.py migrate يفترض أن تظهر النتيجة التالية في سطر الأوامر: Operations to perform: Apply all migrations: admin, auth, contenttypes, polls, sessions Running migrations: Rendering model states... DONE Applying polls.0001_initial... OK تتلخص وظيفة الأمر migrate في البحث عن التهجيرات غير المنفّذة (يتابع Django التهجيرات غير المنفّذة من خلال جدول خاص في قاعدة البيانات يحمل الاسم django_migrations) وإجرائها على قاعدة البيانات، سواء أكانت هذه التهجيرات تتضمن إنشاء جداول جديدة أو تعديل وتحديث جداول موجودة بالفعل. إذًا يمكن تلخيص عملية إجراء التعديلات على النماذج بالخطوات الثلاثة التالية: إجراء التعديلات على النموذج في ملف models.py. تنفيذ الأمر python manage.py makemigrations لإنشاء التهجيرات المرتبطة بالتعديلات التي تم إجراؤها على النموذج. تنفيذ الأمر python manage.py migrate لتطبيق هذه التعديلات على قاعدة البيانات. الواجهة البرمجية الخاصة بالتعامل مع قاعدة البيانات ذكرنا سابقًا بأن لدى Django واجهة برمجية للتعامل مع قاعدة البيانات، وأفضل طريقة للتعرف على هذه الواجهة هي التعامل المباشر معها من خلال سطر الأوامر وعن طريق صدفة Python. للولوج إلى الصدفة نفّذ الأمر التالي في سطر الأوامر: python manage.py shell أولًا يجب استيراد صنفي النموذج Question و Choice، كما سنحتاج إلى حزمة timezone من مكتبة django.utils للتعامل مع الوقت والتاريخ: from polls.models import Question, Choice from django.utils import timezone يمكن الاستعلام عن جميع الأسئلة الموجودة في جدول Question من خلال الشيفرة: Question.objects.all() وباعتبار أن قاعدة البيانات الخاصة بتطبيقنا هذا خالية تمامًا من الأسئلة، فسنحصل على النتيجة: <QuerySet []> لإنشاء السؤال الأول سنقوم بإنشاء كائن من الصنف Question مع تعريف قيم المعاملات المستخدمة في هذا الصنف وإسناد هذا الكائن إلى متغير، وكما يلي: q = Question(question_text="What's new?", pub_date=timezone.now()) يمكن الآن حفظ السؤال الجديد في قاعدة البيانات من خلال الشيفرة التالية: q.save() والآن، يمكن الوصول إلى جميع المعلومات الخاصة بهذا السؤال وبالشكل التالي: #الحصول على نص السؤال q.question_text #الحصول على تاريخ نشر السؤال q.pub_date # تغيير نص السؤال q.question_text = "What’s up?" q.save() بعد أن أضفنا سؤالًا إلى قاعدة البيانات، سنجري استعلامًا عن جميع الأسئلة في النموذج Question: Question.objects.all() #ستحصل على النتيجة التالية <QuerySet [<Question: Question object>]> نلاحظ أن النتيجة التي حصلنا عليها غريبة بعض الشيء، فالسؤال الذي أضفناه قبل قليل لم يظهر ضمن قائمة الأسئلة، ولحل هذه المشكلة سنحتاج إلى إضافة تابع __str()__ إلى كلا الصنفين، وبالشكل التالي: from django.db import models from django.utils.encoding import python_2_unicode_compatible @python_2_unicode_compatible # إن كنت بحاجة إلى استخدام الإصدار الثاني من بايثون class Question(models.Model): # ... def __str__(self): return self.question_text @python_2_unicode_compatible # إن كنت بحاجة إلى استخدام الإصدار الثاني من بايثون class Choice(models.Model): # ... def __str__(self): return self.choice_text من الضروري استخدام التابع __str__() عند التعامل مع النماذج، لأن نتيجة هذا التابع ستظهر في لوحة التحكم التي يتم إنشائها آليًا من خلال هذه النماذج. وكما قمنا باستخدام أحد التوابع المعرفة مسبقًا في Django فبمقدورنا أن نستخدم توابع مخصّصة تؤدي وظائف ومهام مختلفة، ولتوضيح ذلك، قم باستيراد مكتبة datetime الخاصة بـ Python، ثم أضف الشيفرة التالية في نهاية الصنف Question: import datetime # ... class Question(models.Model): # ... def was_published_recently(self): return self.pub_date >= timezone.now() - datetime.timedelta(days=1) سيقوم هذا التابع بالتحقق من أن السؤال قد تم نشره مؤخّرًا (منذ يوم) أو منذ فترة بعيدة (أكثر من يوم). والآن يمكن استدعاء تابعنا المخصص الجديد بنفس الطريقة التي استدعينا من خلالها تابع الحفظ: q.was_published_recently() افتح الآن صدفة بايثون جديدة، واستورد الأصناف Question و Choice بنفس الطريقة السابقة، ثم نفذ شيفرة الاستعلام عن جميع الأسئلة، ولاحظ الفرق. طرق الاستعلام عن البيانات في Django لا شك أن التطبيقات على أرض الواقع تتضمن قواعد بيانات تحتوي على عدد هائل من البيانات والمعلومات، وهذا يتطلب وسيلة للاستعلام عنها حسب شرط معين، ويقدم Django طرقًا متعددة لإجراء استعلامات مخصصة وبأساليب مختلفة. يقدّم Django ثلاثة توابع خاصة بالصنف QuerySet هي: filter(), exclude(), get()، وجملة الاستعلام عبارة عن معاملات مفتاحية Keyword arguments لهذه التوابع، وتأخذ الصيغة التالية: الحقل__نوع الاستعلام = القيمة. يقوم كل تابع من هذه التوابع الثلاثة بإنشاء كائن جديد للصنف QuerySet يتضمن النتائج التي تم الحصول عليها بعد إجراء الاستعلام. يقوم التابع filter() بإرجاع جميع العناصر المتوافقة مع الاستعلام، أما التابع exclude() فيرجع جميع العناصر غير المتوافقة مع الاستعلام، أما التابع get() فيرجع العنصر الذي يطابق جملة الاستعلام، وفي حالة العثور على أكثر من عنصر واحد يقوم هذا التابع بإطلاق الاستثناء MultipleObjectsReturned وإن لم يعثر على أي عنصر فسيطلق الاستثناء DoesNotExist. إليك بعض الأمثلة التي توضح طريقة عمل هذه التوابع: يمكن البحث عن السؤال الذي يبدأ بعبارة معينة بالشكل التالي: Question.objects.filter(question_text__startswith='What') ستترجم هذه الشيفرة إلى عبارة SQL التالية: SELECT … WHERE question_text LIKE ‘What%’; ويمكن البحث عن سؤال معين من خلال المعرّف الخاص به، فللبحث عن السؤال ذي المعرف رقم 1، يمكن كتابة الشيفرة: Question.objects.filter(id=1) والتي تعادل عبارة SQL التالية: SELECT … WHERE id = 1; مثال على التابع exclude(): Question.objects.exclude(pub_date__gt=datetime.date(2016, 1, 3), question_text = "What’s up?") تترجم هذه الشيفرة إلى عبارة SQL التالية: SELECT … WHERE NOT (pub_date > ‘2016-1-3’ AND question_text = “What’s up?”) يوضح الجدول التالي بعض أنواع الاستعلامات التي يقدّمها Django: نوع الاستعلام الوظيفة exact تطابق تام. iexact تطابق تام مع تجاهل حالة الأحرف. contains البحث عن كلمة مع أخذ حالة الأحرف بنظر الاعتبار. icontains البحث عن كلمة مع تجاهل حالة الأحرف. in البحث ضمن قائمة معينة. gt أكبر من gte أكبر من أو يساوي lt أصغر من lte أصغر من أو يساوي startswith يبدأ بـ istartswith يبدأ بـ مع أخذ حالة الأحرف بنظر الاعتبار. endswith ينتهي بـ iendswith ينتهي بـ مع أخذ حالة الأحرف بنظر الاعتبار. range البحث ضمن مدى معين date البحث عن تاريخ معين year البحث عن سنة معينة month البحث عن شهر معين day البحث عن يوم معين week_day البحث عن أسماء أيام الأسبوع hour البحث عن ساعة minute البحث عن دقيقة second البحث عن ثانية لنستعلم الآن عن السؤال الذي يحمل المفتاح الرئيسي primary key رقم 1 في قاعدة البيانات الخاصة بنا، وإسناد النتيجة إلى متغير: q = Question.objects.get(pk=1) يمكننا الآن الوصول إلى مجموعة الأجوبة choice_set والتي ينشئها Django تلقائيًا عند ربط الأسئلة بالأجوبة من خلال ForeignKey. q.choice_set.all() بطبيعة الحال، فإن مجموعة الأجوبة الخاصة بسؤالنا هذا فارغة، لذا سنقوم بإنشاء بعض الأجوبة وإضافتها إلى هذه المجموعة: q.choice_set.create(choice_text = 'Not much', votes = 0) q.choice_set.create(choice_text = 'The sky', votes = 0) c = q.choice_set.create(choice_text = 'Just hacking again', votes = 0) والآن يمكن التعرف على السؤال المرتبط بالجواب: c.question ويمكن معرفة عدد الأجوبة المتاحة لسؤال معين عن طريق التابع count(): q.choice_set.count() ويمكن حذف إجابة معينة عن طريق التابع delete(): c.delete() خاتمة تعرفنا في هذا الدرس على العنصر الأول من عناصر إطار العمل Django ألا وهو النماذج Models، وتعرفنا كذلك على طريقة التعامل مع قواعد البيانات من خلال هذه النماذج وكيفية تهجيرها والاستعلام عن البيانات برمجيًا. أما الدرس القادم فسيكون عن المسارات URLS وآلية عملها، وكيفية استخدام التعابير النظامية Regular Expressions في إنشائها. المصدر: توثيقات Django.

إن العديد من حزم بايثون تساعد مطوري جانغو Django على العمل بسرعة وفعالية أكبر، حيث أن مكتبات Django هي المفضلة لدى أغلب المطورين فهي توفر الوقت وتقلل من عملية البرمجة وبالتالي تبسط عملهم. سنتكلم في هذا المثال عن ستة حزم لبرامج Django واثنين لهيكلية Django REST، حيث تظهر هذه الحزم في غالبية المشاريع التي نعمل عليها. إضافات جانغو الموفرة للوقت: Django-extensions تعتبر Django-extensions من الحزم المليئة بالأدوات المفيدة مثل أوامر الإدارة التالية: shell_plus: تفتح Django shell مع جميع النماذج الخاصة بقاعدة البيانات والمُحمَّلة بشكل مُسبق، وبالتالي لاتحتاج إلى عمل أي استيراد من التطبيقات المختلفة والتي تحتاجها لعمل اختبار لعلاقة معقدة clean_pyc: تعمل على محي جميع المشاريع ذات اللاحقة .pyc في جميع الأماكن التي تظهر بها داخل مسار المشروع. create_tamplate_tags: تنشئ بنية مجلد خاص بالقوالب داخل التطبيق الذي تحدده. describe_form: تظهر تعريف الواجهة للنموذج ويمكن نسخه فيما بعد إلى forms.py (ولكن من المهم الانتباه إلى أن هذا الأمر ينشئ واجهة جانغو عادية وليست من نوع ModelForm). notes: يظهر هذا الأمر جميع التعليقات من نوع TODO أو FIXME وغيرها خلال المشروع. كما تحوي حزمة Django-extensions على أصناف مجردة مفيدة تستخدم للنماذج الشائعة، حيث تستطيع توريث هذه الأصناف الأساسية عند إنشاء نماذج خاصة بك: TimeStampeModel: يحوي هذه الصنف على حقول created و modified بالإضافة للتابع ()save الذي يحدث هذه الحقول تلقائيًّا. ActivatorModel: في حال كان النموذج الخاص بك يحتاج إلى حقول مثل activate_state، status و deactivate_date عندها يمكنك استخدام هذا الصنف حيث أنه يحوي أيضًا على مدير يوفر لك استعلامات ()active. و ()inactive. TitleSlugDescriptionModel و TitleDescriptionModel: يحوي الصنفان على حقول title، description كما يحوي الصنف الأول على حقل إضافي هو slug الذي يُحدَّث تلقائيًّا بالاعتماد على حقل title. حزمة Django-environ تتيح Django-environ تطبيق المنهجية 12-factor app لإدارة إعداداتك في مشروع جانغو الذي تنشئه، وتجمع هذه الحزمة مكتبات أخرى مثل envparse و honcho والآن وبعد تحميلك لحزمة Django-environ تستطيع إنشاء ملف .env في جذر مشروعك وتعرف في داخله متغيرات الإعدادات التي من الممكن أن تتغير بين البيئات أو التي يجب أن تبقى سرية مثل مفاتيح API أو حالة Debug أو عناوين قاعدة البيانات. بعد ذلك في الملف الخاص بإعدادات المشروع setting.py يمكنك عمل استيراد للبيئة ثم ضبط المتغيرات المتعلقة بـ ()environ.PATH و ()environ.Env كما ورد في المثال. مع العلم أنه يمكن الوصول إلى المتغيرات المُعرّفة في ملف .env باستخدام (’env(‘VARIABLE_NAME إنشاء أوامر الإدارة: Django-click أُنشِئت حزمة Django-click بالاعتماد على حزمة click وهي تساعدك لكتابة أوامر الإدارة جانغو، لكن لاتمتلك هذه الحزمة الكثير من التوثيقات وإنما لديها مجلد من الأوامر التجريبية test commands. لنتعرف على طريقة كتابة الأمر Hello World باستخدام هذه الحزمة: # app_name.management.commands.hello.py import djclick as click @click.command() @click.argument('name') def command(name): click.secho(f'Hello, {name}') ثم نكتب سطر التشغيل الذي يعطي أمر التنفيذ: >> ./manage.py hello Lacey Hello, Lacey التعامل مع آلة ذات حالات منتهية : Django-fsm تضيف حزمة Django-fsm الدعم لحالة الآلات ذات حالات منتهية للنموذج الموجود بالجانغو الخاص بمشروعك، ففي حال كنت تنفذ موقع ويب أخباري و تحتاج إلى مقالات تمر بحالات states مثل الكتابة، التحرير، والنشر، هنا يأتي دور حزمة Django-fsm التي تساعد في تعريف هذه الحالات وإدارة القواعد التي تحكُم الانتقال من حالة إلى أخرى. توفر Django-fsm مايدعى FSMField والذي يستخدم كصفة التي تعرف حالة النموذج وبعد ذلك تستطيع استخدام transition@ من هذه الحزمة من أجل تعريف التوابع التي تحرك النموذج من حالة إلى أخرى وللتعامل مع أي تأثيرات جانبية لذلك الانتقال. وعلى الرغم من أن حزمة Django-fsm لا تملك توثيقات التي تعرفها بشكل جيد ولكن تحوي workflows(states) in Django الذي يمكن أن يعتبر مقدمة جيدة لتعريف مفهومي آلة ذات حالات منتهية وحزمة django-fsm. استمارات التواصل: #django-contact-form إن استمارات التواصل أمر أساسي يتواجد في مواقع الويب، ولكن لا داع لتكتب ترميزها بنفسك إذ يمكن إنشاؤها بدقائق من خلال استخدام الحزمة django-contact-form والتي يأتي معه صنف اختياري spam-filtering contact form (و صنف نظامي، و non-filtering) بالإضافة إلى صنف ContactFormView الذي يحوي على توابع يمكن تخصيصها وإعادة كتابتها وذلك لإنشاء النموذج الخاص بك. تسجيل واستيثاق المستخدمين: django-allauth إن Django-allauth هو برنامج يوفر الواجهات، والروابط لتسجيل المستخدمين، ولتسجيل الدخول والخروج، وإعادة تعيين كلمات السر و استيثاق المستخدمين مع مواقع خارجية مثل GitHub و Twitter. كما أنه يدعم الاستيثاق عن طريق email-as-username وهو مُوثَّق بشكل كبير، لأنه قد يكون مربك قليلًا التعامل معه لأول مرة لذلك يمكنك اتباع تعليمات التثبيت (installation instructions)بحرص، ومن الممكن أن تفيدك أيضًا مقالة تخصيص إعداداتك (customize your setting) للتأكد من أنك قد استخدمت كل الإعدادات التي تحتاجها لتفعيل ميزة محددة. التعامل مع استيثاق المستخدمين ضمن هيكيلية REST Framework: django-rest-auth في حال كان عملك كمطور جانغو يتطلب منك كتابة تطبيقات APIs فإنك على الأرجح تستخدم هيكلية Django REST Framework (DRF)، وعلى الأغلب تعاملت مع حزمة django-rest-auth وهي حزمة تمكننا من تسجيل المستخدمين، تسجيل عمليات الدخول والخروج، إعادة تعيين كلمات المرور، استيثاق وسائل التواصل الاجتماعي (وذلك من خلال إضافة django-allauth والتي تعمل بشكل جيد مع django-rest-auth). تطبيقات الإظهار ضمن هيكلية Django REST Framework API: django-rest-swagger يوفر Django REST Swagger واجهة تعامل بالميزات للتفاعل مع Django REST Framework API، فبعد تثبيت Django REST Swagger وإضافته للبرنامج المثبت مسبقًا يمكنك إضافة Swagger View بالإضافة إلى نمط عنوان URL pattern للملف ruls.py الخاص بـواجهتك البرمجية. تتضمن واجهة المستخدم الخاصة بتطبيقك كل نقط النهاية والتوابع المتاحة مصنفة حسب التطبيق، كما تظهر أيضًا قائمة بالعمليات المتاحة لنقط النهاية هذه والتي تسمح لك بالتفاعل مع الواجهة البرمجية (عمليات الإضافة، الحذف، جلب السجلات على سبيل المثال) كما يمكن توليد توثيق لكل نقطة نهاية وبالتالي سينتج لدينا مجموعة مستندات توثيق خاصة بالمشروع والتي تفيدك كمطور وتفيد مطوري الواجهات الأمامية والمستخدمين. ترجمة –وبتصرّف– للمقال 8 Python packages that will simplify your life with Django لصاحبيه Lacey Williams Henschel و Jeff Triplett

بعد أن تعرّفنا على أساسيات لغة بايثون حان الوقت للانتقال إلى مرحلة جديدة. في هذه السّلسلة من الدّروس سنتعرّف على أساسيات تطوير تطبيقات الويب بلغة بايثون، وذلك بالاستعانة بإطار العمل 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 كل درس سيكون شبه مُستقل عن الدّرس الذي يسبقه، وذلك لتكون الدروس مرجعا لك في حالة نسيان أي جزئية. في نهاية السّلسلة ستكون قادرا على استعمال لغة بايثون لتطوير تطبيق يعمل على المُتصفّح ويتصل بقاعدة بيانات. ختاما في الدّرس المُقبل سنقوم بإعداد بيئة التّطوير بتنصيب الأدوات المطلوبة، كما سننشئ تطبيقا بسيطا لعرض صفحة ويب على المُتصفّح.

يحتار المطورون في اختيار أفضل إطار لمشاريعهم وسيكون هذا تحديًا حقيقيًا للمبتدئين في الأطر الحديثة. بعد العمل على الأطر الثلاثة (Django، Laravel و Rails – والذي يُعرف باسم Ruby On -rails)، سأقارن بين هذه الأطر الرائعة على أساس شعارها، سهولة تعلمها، أدائها، قوة وضعف مكتباتها وقوالبها، دعمها، آفاقها المستقبلية، فرص العمل، التكلفة والصيانة. ملاحظة: ينتقد بعض المعجبين عند التحدث عن نقاط ضعف أطرهم، ولا أستطيع فعل أي شيء لأنه لا يمكن إخفاء الحقيقة، كل إطار لديه بعض المزايا مع بعض العيوب. المقدمة لغة البرمجة أهم فرق بين هذه الأطر هي أن Django بلغة بايثون، Laravel بلغة PHP وRails بلغة الروبي، لذا إذا كنت تنوي استخدام أي من هذه الأطر فيجب عليك تعلم لغتها أولاً، وبسبب هذا، العديد من المطورين يختارون الإطار الذي يتطابق مع اللغة التي يعرفونها. إن التحول من لغة إلى أخرى ليس صعبًا بل يحتاج إلى بعض الوقت، وإذا احترت في اختيار لغة البرمجة، فهذه مقارنة بين لغات بايثون و PHP وروبي. الشعار جميع هذه الأطر من نوع MVC وشعارها ‘لا تكرر نفسك’ أي تدعم إعادة الاستخدام وقابلية النقل، وجميعها مشاريع مجانية ومفتوحة المصدر. المواقع بعض المواقع المعروفة تستخدم Django مثل Pinterest، Instagram، Mozilla، The Washington Times، Disqus، the Public Broadcasting Service و Bitbucket. في حين أن Laravel هو إطار جديد، حيث صدر في يونيو عام 2011، لكنه أصبح مشهورا جدا، ومن بين المواقع التي تستخدمه هي Deltanet Travel، Sublimity، Neighborhood Lender، Sendity و MyRank. يعتبر Rails من الأطر الرائعة فمن المواقع التي تستخدمه Twitter، Shopify، SoundCloud، Heroku، Github، Bloomberg و Hulu. سهولة التعلم على الرغم من أن الأطر الثلاثة لديها مجتمعات كبيرة وتوثيق رسمي، إلا أن تعلم Django وLaravel أسهل بكثير من تعلم Rails، فالتوثيق الحالي ل Django يجعلها الأسهل، وإذا كنت تملك خلفية PHP فيمكنك تعلم Laravel في غضون أسبوعين أو ثلاثة أسابيع، وهذه هي الوثائق الرسمية: وثائق Django ووثائق Laravel وثائق Rails. الأداء الأمن جميع هذه الأطر آمنة جدا إذا لم يرتكب المبرمج أخطاء، فيمتلك Django برمجيات وسيطة ويمتلك Rails Active Records وأما Laravel فيمتلك برمجيات HTTP وسيطة، وتوفر كل هذه الأطر رموز csrf للنماذج. لا يوجد فرق أمني كبير بين هذه الأطر، وكل هذا يعتمد على خبرة المبرمج. تحديث:أشار بعض القراء أن المبرمجين هم بشر وسيخطئون، لذا سأقول في هذه الحالة أن Django هو الأكثر أمانا وLaravel هو الأقل أمانًا، اطلع على هذا التوثيق عن أمن Django وهذا دليل أمن Rails و هذا دليل أمن Laravel، وسأقول أيضا أنه لا يوجد إطار آمن بشكل كامل لأن المطورين هم أيضا بشر، ويمكنك زيادة الأمن لكنك لا تستطيع جعله آمن بنسبة 100%، لكن إذا كتبت التعليمات البرمجية بعناية وحذر فإن جميع الأطر متساوية من ناحية الأمن. السرعة جميع الأطر مكتوبة بشكل صحيح، لذلك سرعتها تعتمد على اللغة البرمجة المستخدمة، فDjango هو الأسرع بسبب البايثون و Laravel هي الأبطأ بسبب PHP. الوقت المطلوب لإنشاء تطبيق إذا كنت تفهم الإطار بشكل كامل فإن إنشاء تطبيق Rails هو الأسرع لأنه يوفر لك الكثير من الاختصارات وبهذا ستكتب أقل عدد من الأسطر البرمجية. ومن جهة أخرى، Laravel هو الأبطأ ولا يوفر مكتبة قوية. إذا كان المشروع معقد فإن الفرق الزمني بين تطبيقات Django وRails سيكون صغيرًا بسبب صياغة بايثون المريحة للمتابعة وأقل أرباك، أما بالنسبة لـ Laravel فيجب عليك كتابة الكثير من الأسطر البرمجية وهذا قد يسبب لك بعض الإرباك وسترتفع نسبة الأخطاء. قوة وضعف المكتبة الأشياء المشتركة في جميع الأطر: جميعها MVC (يسمى Django MTV أيضا لكن على الرغم من أن الاسم مختلف إلا أن المفهوم هو نفسه). تركز جميع الأطر على قابلية القراءة وبساطة الشيفرة البرمجية وتوزيع الملفات. جميعها تستعلم تلقائيًا من قاعدة البيانات، فلا يجب عليك كتابة استعلامات قاعدة البيانات بشكل مباشر. تبنى الجداول تلقائيا في قاعدة البيانات من النماذج (models). جميع الأطر تملك نظام توجيه سهل وآمن، وتعرض صفحات الويب بشكل حيوي. تملك جميعها أنظمة قوالب خاصة بها وكل نظام قوالب غني بالمرشحات والدوال المعرّفة مسبقًا، الفرق الوحيد في الصياغة. جميعها مرنة ومحمولة مع تقنيات حديثة أخرى. Django يمتلك Django مكتبة قوية مع المميزات التالية: يعتبر قسم الإدارة المدمجة، المزخرف (decorator)، وأصناف المناظر نقاط قوة ل Django. الاستمارات المولدة تلقائيا للنماذج مع عملية التحقيق تجعلها سهلة للغاية. يدعم الإطار خاصية التخزين المؤقت وستتمكن من استخدام أي من أساليب التخزين المؤقت المتاحة. يدعم الأصناف البرمجيات الوسطيّة والتي يمكن أن تتدخّل في مراحل مختلفة من معالجة الطلب وتُنفّذ دوال مخصصة. يسمح لك نظام مرسل (dispatcher) داخلي لمكونات التطبيق اتصال الأحداث مع بعضها البعض عبر إشارات محددة مسبقا. يملك نظام تدويل يتضمن ترجمات لمكونات Django إلى لغات مختلفة. يملك نظام تسلسل الذي يمكنك من إنتاج وقراءة تمثيل XML و/أو JSON لمثيلات نموذج Django. واجهة بايثون مدمجة في إطار اختبار الوحدة. نظام مصادقة (authentication) موسّع. واجهة إدارة حيوية. أدوات لتوليد RSS وتغذيات (feed) خلاصات Atom. إطار مواقع تسمح ل Django واحد بتشغيل مواقع متعددة، ولكل منها المحتوى والتطبيقات الخاصة به. يملك أدوات لتوليد Google Sitemap. يملك تقنيات مدمجة للتخفيف من التزوير عبر الموقع، ثغرات XSS، ثغرات حقن SQL، تكسير كلمات المرور وهجمات الويب النموذجية، ومعظمها يعمل افتراضيا. إطار لإنشاء تطبيقات GIS. Laravel على الرغم من أن مكتبات Laravel ليست قوية مثل Django وRails إلا أنها كافية لإنشاء أي نوع من المواقع. يوفر Bundles و composer عدد من حزم نظام وحدات التحزيم والاعتماديات. التوجيه (Routing) – يوّفر طريقة سهلة وبسيطة لإدارة وتوجيه الروابط إلى متحكم أو دالة تُنفَّذ عند زيارة رابط محدَّد. دعم Eloquent ORM – خدمة أخرى مقدمة لتجريد وأتمتة جزء النموذج، حيث سنطبق التقنيات المتعارف عليها على الإعدادات. التهجيرات – طريقة لإصدار سكربتات قواعد البيانات بطريقة أنيقة للغاية، فلا حاجة للحفاظ على جميع التحققات على التهجيرات، يمكن لفريق عمل المشروع سحب الهجرة المقدمة وستعيّن جميعها وستكون جاهزة للعمل. إدارة قائمة الانتظار (Queue management) – لتجريد المهام غير الضرورية ووضعهم في قائمة الانتظار وجعل وقت استجابة المستخدم أسرع بكثير. دعم Redis، ويمكن توسيعها إلى memcached. حقن الإعتماديّة – اختبار سهل وأتمتة تحميل الإعتماديّة. Artisan – لإنشاء تطبيقات سطر الأوامر في لحظة. تعلم استخدام Laravel عن طريق هذه الدروس. Rails يتضمن Rails أدوات لجعل مهام التطوير الشائعة أسهل (خارج الصندوق)، مثل scaffolding الذي يستطيع إنشاء بعض النماذج تلقائيًا والمناظر اللازمة لموقع ويب الأساسي، بالإضافة إلى WEBrick وهو خادم ويب روبي بسيط الموزع مع روبي و Rake والذي هو نظام بناء موزع كـ gem. وتوفر هذه الأدوات جنبا إلى جنب مع Rails بيئة تطوير أساسية. Active record: يلعب دورا رئيسيا في تطبيقات Rails، وهو أفضل من Eloquent ORM في Laravel ومن النماذج في Django. اختصارات: يعبر الكثير من الناس الذين يأتون من لغات برمجة أو إطارات أخرى أن هذا الإطار سحري بسبب الاختصارات الكثيرة، فأغلب الأشياء معرّفة مسبقًا ويجب عليك كتابة بعض الأسطر البرمجية لإنشاء تطبيقات معقدة. التوجيه التلقائي: بعض الدوال الشائع في جدول قاعدة البيانات مثل الإنشاء ، التعديل والعرض مُعرّفة تلقائيًا، وهذا يعني أننا لا نحتاج إلى تضييع الوقت في المهام البسيطة ويمكننا قضاء وقت أطول على الأجزاء المعقدة من المشروع. سطر الأوامر: الكثير من الأشياء يمكن إنجازها عن طريق سطر الأوامر مثل استخدام rake وهي Ruby Make، أداة روبي مستقلة تستبدل أداة يونكس 'make' وتستخدم 'Rakefile' وملفات .rake لبناء قائمة مهام. في Rails، يُستخدم Rake لمهام الإدارة الشائعة، خاصة المعقدة منها التي تبني من بعضها البعض. تحتوي وحدة ActiveModelHelper على أساليب المساعدة لإنشاء النماذج من الكائنات بسرعة التي تتبع اتفاقيات Active Model، بداية من Active Record. خدمات الاستضافة يمكنك تشغيل أي تطبيق على VPS أو على خدمة استضافة مخصصة، وهذه مجموعة من الروابط لمواقع تسمح لك باستضافة مشروعك مجانا أو على خطط الاستضافة المشتركة. Django: بعض من المواقع التي تستضيف مشاريع Django هي: WebFaction، PythonAnywhere ، Heroku ، Digital Ocean ، Bulehost ، Dreamhost ، Arvixe و Google App Engine. Laravel: يمكنك الاستضافة على Heroku ، Bulehost ، Inmotion Hosting ، Site5 ، Dreamhost ، Digital Ocean و Arvixe. Rails: مواقع لتطبيقات Rails هي: Heroku ، Bulehost ، Dreamhost ، Arvixe ، Hosting24 و Digital Ocean. معايير أخرى كل هذه الأطر جيّدة في المستقبل، ففرص العمل، التكلفة والصيانة هي تقريبا نفسها ويمتاز Rails على Django وLaravel في شروط العمل، على الرغم من سرعة نمو Laravel. خاتمة يمكنك أن تختار أي واحدة من هذه الأطر حسب لغة البرمجة والخبرة، وإذا كنت هنا لتقرر أي واحدة يجب عليك تعلمها فأنا أفضل Rails، فعلى الرغم من صعوبة تعلمها إلا أنها مريحة أثناء إنشاء التطبيقات، إذا أردت أشياء سهلة مع الكثير من المميزات فاختر Django، فصياغة بايثون ونماذجه تجعله خيار جيدا، وعلى الرغم من أن تعلم Django قد يستغرق بعض الوقت إلا أنه ليس أصعب من Rails.إذا كانت لدي خبرة في PHP أو إذا أردت التعلم بسرعة فاختر Laravel. ترجمة -وبتصرّف- للمقال Django vs Laravel vs Rails لصاحبه Harish Kumar

چانجو هو إطار عمل مرن يستخدم ﻹنشاء تطبيقات بلغة بايثون، وهذه التطبيقات مُجهزة تلقائيًا لتخزين البيانات في ملف قاعدة بيانات SQLite خفيف ويعمل بشكل جيد في الاستعمالات العادية والصغيرة، لكن استخدام نظام إدارة قواعد بيانات تقليدي سيطوِّر أداء التطبيق تحت ضغط زيادة المستخدمين أو زيادة حجم البيانات. وسنستعرض في هذا الدليل كيفية تثبيت وتهيئة PostgreSQL لاستخدامها مع تطبيقات Django، وسنثبّت الحزم اللازمة وننشئ اعتماديات قاعدة البيانات للتطبيق، ثم نبدأ مشروع Django جديد ونجهّزه ليستخدم هذه اﻹعدادات. المتطلبات خادم يعمل بتوزيعة ديبيان جنو/لينكس إصدار 8 “Jessie” مع مستخدم -غير الجذر- له صلاحية sudo. تثبيت الحزم من مستودعات ديبيان سنثبّت أولًا pip -مدير حزم بايثون- لتثبيت وإدارة حزم بايثون، وسنثبّت أيضًا برنامج قاعدة البيانات والمكتبات اللازمة للتفاعل معهم. يحتاج إصدار بايثون 2 و3 إلى حزم مختلفة قليلًا عن بعضها، لذا اختر الأوامر التي تتوافق مع إصدار بايثون لديك. انسخ الأوامر التالية إن كنت تستخدم بايثون 2: $ sudo apt-get update $ sudo apt-get install python-pip python-dev libpq-dev postgresql postgresql-contrib وهذه إن كنت تستخدم بايثون 3: $ sudo apt-get update $ sudo apt-get install python3-pip python3-dev libpq-dev postgresql postgresql-contrib إنشاء قاعدة البيانات والمستخدم الخاص بها يستخدم Postgres نظام توثيق للاتصالات المحلية اسمه “توثيق النِّدّ Peer Authentication”. وهذا يعني أنه إذا كان اسم المستخدم في نظام التشغيل يطابق اسم Postgres صالح، فإن هذا المستخدم يمكنه الولوج دون الحاجة إلى توثيق. وقد أُنشئ مستخدم للنظام اسمه postgres ليتوافق مع مستخدم postgres المدير لنظام PostgreSQL، وسنحتاج هذا المستخدم لتنفيذ مهام إدارية، ويمكننا أيضًا أن نستخدم sudo وندخل اسم المستخدم من خلال لاحقة u-. سجل الدخول إلى جلسة Postgres تفاعلية عبر كتابة الأمر التالي: $ sudo -u postgres psql وسننشئ أولًا قاعدة بيانات لمشروع Django، ويجب أن يكون لكل مشروع قاعدة البيانات الخاصة به للدواعي الأمنية. وسنسمّي قاعدة البيانات في هذا المقال باسم myproject، لكن من اﻷفضل طبعًا أن تختار اسمًا يصلح لمشروع حقيقي. postgres=# CREATE DATABASE myproject; سيكون الخرج هكذا: CREATE DATABASE أنشئ مستخدمًا لقاعدة البيانات، وسنستعمله للاتصال بقاعدة البيانات والتفاعل معها، وﻻ تنس أن تستبدل myprojectuser باسم قاعدة البيانات الذي اخترته، وتغيّر password بكلمة سر قوية: postgres=# CREATE USER myprojectuser WITH PASSWORD 'password'; سيكون الخرج هكذا: CREATE ROLE واﻵن سنعدّل بعض معاملات الاتصال لهذا المستخدم لتسريع عمليات قاعدة البيانات بما أن القيم الصحيحة لن تضطر إلى أن تمر بعمليات استعلام وضبط في كل مرة يحدث اتصال. فسنضبط الترميز الافتراضي على UTF-8 وهو الترميز الافتراضي الذي يتوقعه Django. وسنضبط القاعدة الافترضية لعزل التعاملات “default transactio isolation scheme” على read committed، والتي تحظر القراءة من التعاملات غير المرسلة “uncommitted transactions”. وأخيرًا، سنضبط المنطقة الزمنية الافتراضية لمشاريع Django على UTC. وهذه الإعدادات يُنصح بها في التوثيق الرسمي لمشروع Django، دعنا نكتب ذلك الآن: postgres=# ALTER ROLE myprojectuser SET client_encoding TO 'utf8'; postgres=# ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed'; postgres=# ALTER ROLE myprojectuser SET timezone TO 'UTC'; ويكون الخرج هكذا: ALTER ROLE ALTER ROLE ALTER ROLE وكل ما نحتاجه الآن هو إعطاء مستخدم قاعدة البيانات صلاحيات الوصول لقاعدة البيانات التي أنشأناها للتو: postgres=# GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser; ويكون الخرج هكذا: GRANT اخرج الآن من محث SQL: postgres=# \q يجب أن تعود الطرفية بك الآن إلى جلسة shell السابقة. تثبيت Django في بيئة افتراضية يمكننا تثبيت Django الآن بما أن قاعدة بياناتنا قد صارت جاهزة، وسنثبته وكل اعتمادياته داخل بيئة بايثون افتراضية لتحقيق مرونة أكثر، وستتيح لنا حزمة virtualenv إنشاء هذه البيئات بسهولة. اكتب هذا السطر في الطرفية لتثبيت virtualenv إن كنت تستخدم Python 2: $ sudo pip install virtualenv وهذا إن كنت تستخدم Python 3: $ sudo pip3 install virtualenv أنشئ مجلدًا جديدًا باسم مشروعك (استبدل اسم مشروعك بـ myproject الذي اخترناه هنا لغرض المثال فقط)، ثم انتقل داخله: $ mkdir ~/myproject $ cd ~/myproject اكتب السطر التالي لإنشاء بيئة افتراضية لتخزين متطلبات بايثون لمشروع Django الخاص بنا: $ virtualenv venv وذلك سيثبّت نسخة محلية من بايثون وأمر pip محلي داخل مجلد اسمه venv داخل مجلد مشروعك. نحتاج الآن إلى تفعيل البيئة الافتراضية قبل تثبيت البرامج داخلها، ويمكننا فعل ذلك عبر الأمر التالي: $ source venv/bin/activate سيتغير المحثّ الآن ليشير إلى أنك تعمل الآن داخل بيئة افتراضية وسيبدو شبيهًا بهذا: (venv)user@host:~/myproject$ ويمكننا الآن تثبيت Django باستخدام pip، ثم سنثبت psycopg2 التي ستتيح لنا استخدام قاعدة البيانات التي أعددناها: (venv) $ pip install django psycopg2 يمكننا الآن أن نبدأ مشروع Django داخل مجلد المشروع (myproject في حالتنا)، وسينشئ هذا مجلدًا فرعيًا بنفس اسم مجلد المشروع ليحتوي الشفرة البرمجية، إضافة إلى مخطوطة إدارية “management script” داخل المجلد الحالي: (venv) $ django-admin.py startproject myproject . ملاحظة: تأكد من إضافة النقطة في نهاية الأمر السابق، فنحن ﻻ نحتاج مستوىً فرعيًا آخر في المجلد بما أننا أنشأنا مجلدًا أبًا للمشروع “parent directory” ليحتوي مجلد البيئة الوهمية، وهو ما كان سيحدث لو لم نضع النقطة في نهاية سطر الأوامر السابق. يجب أن تكون هيكلة مجلدك الحالي شبيهة بهذا: . └── ./myproject/ ├── manage.py ├── myproject/ │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py └── venv/ └── . . . وكما ترى فإن لدينا مجلدًا أبًا للمشروع يحتوي مخطوطة manage.py، ومجلد داخلي للمشروع، ومجلد البيئة الوهمية venv الذي أنشأناه قبل قليل. ضبط إعدادات قاعدة بيانات Django سنضبط الآن مشروعنا كي نستخدم قاعدة البيانات التي أنشأناها، افتح ملف الإعدادات الرئيسية لمشروع Django الموجود في المجلد الفرعي للمشروع: (ملاحظة: استبدل مشروعك بـmyproject) (venv) $ nano ~/myproject/myproject/settings.py قد تحتاج أيضًا إلى تعديل تعليمة ALLOWED_HOSTS قبل إعداد قاعدة البيانات، وتلك التعليمةتحدد قائمة عناوين أو أسماء نطاقات مسموح باستخدامها للاتصال مع مشروع Django، فأي طلب اتصال بترويسة HOST ليس في هذه القائمة سيتم اعتراضه. ويتطلّب Django أن تعدّل هذه التعليمة كي يمنع فئة معينة من الاختراقات الأمنية. ولتعديل هذه التعليمة، أدخل -بين قوسين مربعيْن- عناوين IP أو أسماء النطاقات المرتبطة بخادم Django الخاص بك ويجب أن يكون كل نطاق أو عنوان IP داخل علامتي تنصيص مفردتيْن، وتفصل بين كل واحد منهم فاصلة “,”. وإن رغبت في الاستجابة لطلبات من نطاق ما إضافة إلى النطاقات الفرعية له فضع نقطة قبله أثناء كتابته. إليك أمثلة تعرض لك الطريقة الصحيحة لصيغة هذه التعليمة، استبدل النطاقات وعناوين الـ IP التي تريدها بالأمثلة الموجودة هنا: . . . # أبسط حالة: اكتب العناوين وأسماء النطاقات لخادم چانجو الخاص بك # ALLOWED_HOSTS = [ 'example.com', '203.0.113.5'] # ابدأ اسم النطاق بنقطة للاستجابة له ولأي نطاق فرعي # ALLOWED_HOSTS = ['.example.com', '203.0.113.5'] ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP', . . .] واﻵن ابحث عن قسم DATABASES الذي يبدو كهذا: . . . DATABASES = { 'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': os.path.join(BASE_DIR, 'db.sqlite3'), } } . . . هذا القسم يستخدم SQLite كقاعدة بيانات، ونريد تعديل هذه لكي يستخدم قاعدة بيانات PostgreSQL الخاصة بنا. فأول ما نفعله هو تغيير المحرك كي يستخدم محوّل postgresql_psycopg2 بدلًا من sqlite3، ثم نستخدم اسم قاعدة بياناتنا (myproject في مثالنا) في خانة NAME، ونضيف بعض بيانات تسجيل الدخول مثل اسم المستخدم وكلمة المرور، والمضيف الذي سيتصل به، وسنضيف خانة Port ونتركها فارغة كي يتم اختيار المنفذ الافتراضي: . . . DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': 'myproject', 'USER': 'myprojectuser', 'PASSWORD': 'password', 'HOST': 'localhost', 'PORT': '', } } . . . واﻵن احفظ الملف وأغلقه. نقل قاعدة البيانات واختبار مشروعك يمكننا الآن نقل هياكل البيانات -بما أننا أنهينا ضبط إعدادات Django- إلى قاعدة بياناتنا واختبار الخادم، سنبدأ بإنشاء هيكل ابتدائي لقاعدة البيانات بما أننا ﻻ نملك أي بيانات حقيقية بعد: (venv) $ cd ~/myproject (venv) $ ./manage.py makemigrations (venv) $ ./manage.py migrate أنشئ حسابًا إداريًا: (venv) $ ./manage.py createsuperuser وسيطلب منك النظام اختيار اسم لمستخدم هذا الحساب وعنوان بريد وكلمة مرور له. ملاحظة: قبل أن تجرب خادم التطوير، تأكد أن تفتح منفذًا في جدارك الناري، وإن كنت تستخدم جدار ufw، فإن فتح المنفذ المناسب يتم عبر كتابة هذا الأمر: (venv) $ sudo ufw allow 8000 أما إن كنت تستخدم جدار iptables، فإن الأمر الذي تحتاجه يعتمد على اﻹعدادات التي تستخدمها، الأمر التالي يصلح ﻷغلب الإعدادات: (venv) $ sudo iptables -I INPUT -p tcp --dport 8000 -j ACCEPT يمكنك الآن اختبار عمل قاعدة بياناتك بشكل صحيح من خلال بدء تشغيل خادم تطوير Django: (venv) $ ./manage.py runserver 0.0.0.0:8000 اذهب إلى عنوان IP الخاص بالخادم أو اسم النطاق الخاص به متبوعًا بـ 8000: للوصول إلى الصفحة الجذر الافتراضية لـDjango: http://server_domain_or_IP:8000 يجب أن ترى صفحة index الافتراضية: ضع admin/ في نهاية الرابط، يجب أن تكون قادرًا على الوصول لشاشة تسجيل الدخول إلى واجهة التحكم: أدخل اسم المستخدم وكلمة المرور اللتان أنشأتهما قبل قليل باستخدام createsuperuser، فتدخل إلى لوحة التحكم: وبدخولنا للوحة التحكم نكون قد تأكدنا أن قاعدة البيانات قد خزّنت معلومات حساب المستخدم الخاص بنا ويمكننا الدخول إليه دون مشاكل. يمكنك الآن إيقاف الخادم حين تنتهي من تحققك بالضغط على ctrl-c داخل شاشة الطرفية. وإن أردت وسيلة أخرى لاختبار قاعدة البيانات يمكنك الاستعلام داخل قاعدة بيانات Postgres نفسها باستخدام psql، فمثلًا يمكنك الاتصال بقاعدة بيانات مشروعك (myproject) عن طريق المستخدم myprojectuser وإظهار كل الجداول المتاحة بكتابة الأمر التالي: (venv) $ psql -W myproject myprojectuser -h 127.0.0.1 -f <(echo '\dt') لتفصيل اﻷمر السابق، فإنه يجب أن نستخدم ﻻحقة h- من أجل الاتصال بالمضيف المحلي localhost عبر الشبكة لتحديد أننا نريد توثيق كلمة المرور بدلًا من توثيق النّدّ. أما W- فستجعل psql يسألك عن كلمة المرور المناسبة، وf- لتمرير الأمر الوصفي “meta-command” في psql لتنفيذه، وdt\ لعرض كل الجداول في قاعدة البيانات. List of relations Schema | Name | Type | Owner --------+----------------------------+-------+--------------- public | auth_group | table | myprojectuser public | auth_group_permissions | table | myprojectuser public | auth_permission | table | myprojectuser public | auth_user | table | myprojectuser public | auth_user_groups | table | myprojectuser public | auth_user_user_permissions | table | myprojectuser public | django_admin_log | table | myprojectuser public | django_content_type | table | myprojectuser public | django_migrations | table | myprojectuser public | django_session | table | myprojectuser (10 rows) وكما ترى فإن Django قد أنشأ بعض الجداول داخل قاعدة البيانات الخاصة بنا، وهذا يؤكد لنا أن إعداداتنا كانت صحيحة. الخلاصة قد عرضنا في هذا الدليل كيفية تثبيت وإعداد PostgreSQL كقاعدة بيانات في النهاية الخلفية لمشروع Django، إذ تستفيد أغلب المشاريع من استخدام نظم إدارة متطورة لقواعد البيانات، رغم أن SQLite تتعامل بشكل جيد أثناء تطوير المشروع وأثناء الاستخدام الخفيف له. ترجمة -بتصرف- لمقال How To Use Postgresql with your Django Application on Debian 8 لصاحبه Justin Ellingwood.

Django هو إطار عمل مرن يستخدم ﻹنشاء تطبيقات بلغة بايثون، وهذه التطبيقات مُجهزة تلقائيًا لتخزين البيانات في ملف قاعدة بيانات SQLite خفيف ويعمل بشكل جيد في الاستعمالات العادية والصغيرة، لكن استخدام نظام إدارة قواعد بيانات تقليدي سيطوِّر أداء التطبيق تحت ضغط زيادة المستخدمين أو زيادة حجم البيانات. وسنستعرض في هذا الدرس كيفية تثبيت وتهيئة PostgreSQL لاستخدامها مع تطبيقات Django، وسنثبّت الحزم اللازمة وننشئ اعتماديات قاعدة البيانات للتطبيق، ثم نبدأ مشروع Django جديد ونجهّزه ليستخدم هذه اﻹعدادات. المتطلبات خادم يعمل بتوزيعة أوبنتو 16.04 مع مستخدم -غير الجذر- له صلاحية sudo. تثبيت الحزم من مستودعات أوبنتو سنثبّت أولًا pip -مدير حزم بايثون- لتثبيت وإدارة حزم بايثون، وسنثبّت أيضًا برنامج قاعدة البيانات والمكتبات اللازمة للتفاعل معهم. يحتاج إصدار بايثون 2 و3 إلى حزم مختلفة قليلًا عن بعضها، لذا اختر الأوامر التي تتوافق مع إصدار بايثون لديك. انسخ الأوامر التالية إن كنت تستخدم بايثون 2: $ sudo apt-get update $ sudo apt-get install python-pip python-dev libpq-dev postgresql postgresql-contrib وهذه إن كنت تستخدم بايثون 3: $ sudo apt-get update $ sudo apt-get install python3-pip python3-dev libpq-dev postgresql postgresql-contrib يمكننا الآن إنشاء قاعدة البيانات بما أننا أنهينا تثبيت هذه الحِزّم. إنشاء قاعدة البيانات والمستخدم الخاص بها يستخدم Postgres نظام توثيق للاتصالات المحلية اسمه "توثيق النِّدّ Peer Authentication”. وهذا يعني أنه إذا كان اسم المستخدم في نظام التشغيل يطابق اسم Postgres صالح، فإن هذا المستخدم يمكنه الولوج دون الحاجة إلى توثيق. وقد أُنشئ مستخدم للنظام اسمه postgres ليتوافق مع مستخدم postgres المدير لنظام PostgreSQL، وسنحتاج هذا المستخدم لتنفيذ مهام إدارية، ويمكننا أيضًا أن نستخدم sudo وندخل اسم المستخدم من خلال لاحقة u-. سجل الدخول إلى جلسة Postgres تفاعلية عبر كتابة الأمر التالي: $ sudo -u postgres psql وسننشئ أولًا قاعدة بيانات لمشروع Django، ويجب أن يكون لكل مشروع قاعدة البيانات الخاصة به للدواعي الأمنية. وسنسمّي قاعدة البيانات في هذا المقال باسم myproject، لكن من اﻷفضل طبعًا أن تختار اسمًا يصلح لمشروع حقيقي. ملاحظة: تذكر أن تنهي كل الأوامر في محث SQL بفاصلة منقوطة ; postgres=# CREATE DATABASE myproject; أنشئ مستخدمًا لقاعدة البيانات، وسنستعمله للاتصال بقاعدة البيانات والتفاعل معها، وﻻ تنسَ أن تستبدل myprojectuser باسم قاعدة البيانات الذي اخترته، وتغيّر password بكلمة سر قوية: postgres=# CREATE USER myprojectuser WITH PASSWORD 'password'; واﻵن سنعدّل بعض معاملات الاتصال لهذا المستخدم لتسريع عمليات قاعدة البيانات بما أن القيم الصحيحة لن تضطر إلى أن تمر بعمليات استعلام وضبط في كل مرة يحدث اتصال. فسنضبط الترميز الافتراضي على UTF-8 وهو الترميز الافتراضي الذي يتوقعه Django. وسنضبط النظام الافتراضي لعزل التعاملات "default transactio isolation scheme” على read committed، وذلك لحظر القراءة من التعاملات غير المرسلة "uncommitted transactions”. وأخيرًا، سنضبط المنطقة الزمنية الافتراضية لمشاريع Django على UTC. وهذه الإعدادات يُنصح بها في التوثيق الرسمي لمشروع Django، دعنا نكتب ذلك الآن: postgres=# ALTER ROLE myprojectuser SET client_encoding TO 'utf8'; postgres=# ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed'; postgres=# ALTER ROLE myprojectuser SET timezone TO 'UTC'; وكل ما نحتاجه الآن هو إعطاء مستخدم قاعدة البيانات صلاحيات الوصول لقاعدة البيانات التي أنشأناها للتو: postgres=# GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser; اخرج الآن من محث SQL: postgres=# \q تثبيت Django في بيئة افتراضية يمكننا تثبيت Django الآن بما أن قاعدة بياناتنا قد صارت جاهزة، وسنثبته وكل اعتمادياته داخل بيئة بايثون افتراضية لتحقيق مرونة أكثر، وستتيح لنا حزمة virtualenv إنشاء هذه البيئات بسهولة. اكتب هذا السطر في الطرفية لتثبيت virtualenv إن كنت تستخدم Python 2: $ sudo pip install virtualenv وهذا إن كنت تستخدم Python 3: $ sudo pip3 install virtualenv أنشئ مجلدًا جديدًا باسم مشروعك (استبدل اسم مشروعك بـ myproject الذي اخترناه هنا لغرض المثال فقط)، ثم انتقل داخله: $ mkdir ~/myproject $ cd ~/myproject اكتب السطر التالي لإنشاء بيئة افتراضية لتخزين متطلبات بايثون لمشروع Django الخاص بنا: $ virtualenv myprojectenv وذلك سيثبّت نسخة محلية من بايثون وأمر pip محلي داخل مجلد اسمه myprojectenv داخل مجلد مشروعك. نحتاج الآن إلى تفعيل البيئة الافتراضية قبل تثبيت البرامج داخلها، ويمكننا فعل ذلك عبر الأمر التالي: $ source myprojectenv/bin/activate سيتغير المحثّ الآن ليشير إلى أنك تعمل الآن داخل بيئة افتراضية وسيبدو شبيهًا بهذا: (myprojectenv)user@host:~/myproject$ ويمكننا الآن تثبيت Django باستخدام pip، ثم سنثبت psycopg2 التي ستتيح لنا استخدام قاعدة البيانات التي أعددناها: (ﻻحظ أنه يجب استخدام أمر pip وليس pip3 داخل البيئة الافتراضية بغض النظر عن نسخة بايثون التي لديك) (venv) $ pip install django psycopg2 يمكننا الآن أن نبدأ مشروع Django داخل مجلد المشروع (myproject في حالتنا)، وسينشئ هذا مجلدًا فرعيًا بنفس اسم مجلد المشروع ليحتوي الشفرة البرمجية، إضافة إلى مخطوطة إدارية "management script” داخل المجلد الحالي، ﻻ تنس إضافة النقطة التي في آخر الأمر التالي كي ﻻ يُنشأ مستوى فرعي جديد في المجلد: (venv) $ django-admin.py startproject myproject . سنضبط الآن مشروعنا ليستخدم قاعدة البيانات التي أنشأناها، افتح ملف الإعدادات الرئيسية لمشروع Django الموجود في المجلد الفرعي للمشروع: (ملاحظة: استبدل مشروعك بـmyproject) (myprojectenv) $ nano ~/myproject/myproject/settings.py ستجد قسم DATABASE في نهاية الملف، وسيبدو مشابهًا لهذا: . . . DATABASES = { 'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': os.path.join(BASE_DIR, 'db.sqlite3'), } } . . . هذا القسم يستخدم SQLite كقاعدة بيانات، ونريد تعديل هذه لكي يستخدم قاعدة بيانات PostgreSQL الخاصة بنا. فأول ما نفعله هو تغيير المحرك كي يستخدم محوّل postgresql_psycopg2 بدلًا من sqlite3، ثم نستخدم اسم قاعدة بياناتنا (myproject في مثالنا) في خانة NAME، ونضيف بعض بيانات تسجيل الدخول مثل اسم المستخدم وكلمة المرور، والمضيف الذي سيتصل به، وسنضيف خانة Port ونتركها فارغة كي يتم اختيار المنفذ الافتراضي: . . . DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': 'myproject', 'USER': 'myprojectuser', 'PASSWORD': 'password', 'HOST': 'localhost', 'PORT': '', } } . . . وبما أننا في الملف، فقد تحتاج إلى تعديل تعليمة ALLOWED_HOSTS التي تحدد قائمة عناوين أو أسماء نطاقات مسموح باستخدامها للاتصال مع مشروع Django، فأي طلب اتصال بترويسة HOST ليس في هذه القائمة سيتم اعتراضه. ويتطلّب Django أن تعدّل هذه التعليمة كي يمنع فئة معينة من الاختراقات الأمنية. ولتعديل هذه التعليمة، أدخل -بين قوسين مربعيْن- عناوين IP أو أسماء النطاقات المرتبطة بخادم Django الخاص بك ويجب أن يكون كل نطاق أو عنوان IP داخل علامتي تنصيص مفردتيْن، وتفصل بين كل واحد منهم فاصلة ",”. وإن رغبت في الاستجابة لطلبات من نطاق ما إضافة إلى النطاقات الفرعية له فضع نقطة قبله أثناء كتابته. إليك أمثلة تعرض لك الطريقة الصحيحة لصيغة هذه التعليمة، استبدل النطاقات وعناوين الـ IP التي تريدها بالأمثلة الموجودة هنا: . . . # أبسط حالة: اكتب العناوين وأسماء النطاقات لخادم چانجو الخاص بك # ALLOWED_HOSTS = [ 'example.com', '203.0.113.5'] # ابدأ اسم النطاق بنقطة للاستجابة له ولأي نطاق فرعي # ALLOWED_HOSTS = ['.example.com', '203.0.113.5'] ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP', . . .] واﻵن احفظ الملف وأغلقه. نقل قاعدة البيانات واختبار مشروعك يمكننا الآن نقل هياكل البيانات -بما أننا أنهينا ضبط إعدادات Django- إلى قاعدة بياناتنا واختبار الخادم. سنبدأ بإنشاء هيكل ابتدائي لقاعدة البيانات بما أننا ﻻ نملك أي بيانات حقيقية بعد: (myprojectenv) $ cd ~/myproject (myprojectenv) $ python manage.py makemigrations (myprojectenv) $ python manage.py migrate أنشئ حسابًا إداريًا: (myprojectenv) $ python manage.py createsuperuser وسيطلب منك النظام اختيار اسم لمستخدم هذا الحساب وعنوان بريد وكلمة مرور له. انتبه هنا إلى أنه يجب فتح المنفذ الذي سنستخدمه في الجدار الناري كي نتمكن من الدخول إلى خادم تطوير Django، إن كنت تستخدم UFW فإن فتح المنفذ المناسب يتم بكتابة هذا الأمر: (myprojectenv) $ sudo ufw allow 8000 وبمجرد أن تفتح المنفذ يمكنك اختبار عمل قاعدة البيانات بتشغيل خادم Django: http://server_domain_or_IP:8000 يجب أن ترى صفحة index الافتراضية: ضعadmin/ في نهاية الرابط، يجب أن يدخلك هذا لشاشة تسجيل الدخول إلى واجهة التحكم: أدخل اسم المستخدم وكلمة المرور اللتان أنشأتهما قبل قليل باستخدام createsuperuser، فتدخل إلى لوحة التحكم: وبدخولنا للوحة التحكم نكون قد تأكدنا أن قاعدة البيانات قد خزّنت معلومات حساب المستخدم الخاص بنا ويمكننا الدخول إليه دون مشاكل. يمكنك الآن إيقاف الخادم حين تنتهي من تحققك بالضغط على ctrl-c داخل شاشة الطرفية. الخلاصة قد عرضنا في هذا الدليل كيفية تثبيت وإعداد PostgreSQL كقاعدة بيانات في النهاية الخلفية لمشروع Django، إذ تستفيد أغلب المشاريع من استخدام نظم إدارة متطورة لقواعد البيانات، رغم أن SQLite تتعامل بشكل جيد أثناء تطوير المشروع وأثناء الاستخدام الخفيف له. ترجمة -بتصرف- لمقال How To Use PostgreSQL with your Django Application on Ubuntu 16.04 لصاحبه Justin Ellingwood.

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.

بعد أن تعرفنا في الدرس الأول على طريقة تثبيت 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، وكذلك سنتعرف على كيفية تهجير قواعد البيانات، وكذلك الاستعلام عن البيانات برمجيًا، وذلك لتهيئة قاعدة البيانات التي سنستخدمها في تطبيق الاقتراعات.