Django للمبتدئين — مزايا إطار العمل وأول تجربة عملية

من أكثر الأشياء التي أستمتع بها هو البدء بتعلم تقنية قديمة مملة لم أجربها من قبل، لكنها موجودة منذ أكثر من عشرين عاماً. أشعر براحة كبيرة عندما أجد أن كل مشكلة قد أواجهها قد حُلت بالفعل ألف مرة، فأتمكن من إنجاز الأمور بسهولة.

لطالما راودتني فكرة تعلم إطار عمل ويب شهير مثل Rails أو Django أو Laravel، لكنني لم أتمكن من تحقيق ذلك. بدأتُ بتعلم Django لإنشاء موقع ويب قبل بضعة أشهر، وقد أعجبني الأمر حتى الآن، وإليكم بعض الملاحظات السريعة!

سحر أقل من Rails

قضيت بعض الوقت في محاولة تعلم Rails في عام 2020، وعلى الرغم من أنها كانت تجربة رائعة إلا أنني وجدت أنه إذا رجعت إلى مشروع Rails بعد أشهر دون استخدام،فإنه يصعب عليّ تذكر كيفية إنجاز أي شيء، لأنه (على سبيل المثال) إذا كان مكتوبًا resources :topics في ملف routes.rb، فهذا وحده لا يخبرك بمكان تكوين مسارات المواضيع، فأنت بحاجة إلى تذكر أو البحث عن الاصطلاح.

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

في مشروع Django، أشعر وكأن لدي 5 ملفات رئيسية فقط (بخلاف ملفات الإعدادات): urls.py و models.py و views.py و admin.py و tests.py، وإذا أردت معرفة مكان شيء آخر (مثل قالب HTML)، فعادةً ما تتم الإشارة إليه بشكل صريح من أحد هذه الملفات.

الإدارة المدمجة

في هذا المشروع، أردتُ واجهة إدارة لتعديل أو عرض بعض البيانات في قاعدة البيانات يدويًا. يتميز Django بواجهة إدارة مدمجة رائعة، ويمكنني تخصيصها بسهولة باستخدام القليل من التعليمات البرمجية.

على سبيل المثال، إليك جزء من إحدى فئات الإدارة الخاصة بي، والتي تحدد الحقول التي سيتم عرضها في عرض “القائمة”، والحقل الذي سيتم البحث فيه، وكيفية ترتيبها افتراضيًا.

@admin.register(Zine)
class ZineAdmin(admin.ModelAdmin):
    list_display = ["name", "publication_date", "free", "slug", "image_preview"]
    search_fields = ["name", "slug"]
    readonly_fields = ["image_preview"]
    ordering = ["-publication_date"]

من الممتع أن يكون لديك ORM

في الماضي، كان موقفي هو: “أنظمة إدارة قواعد البيانات العلائقية؟ من يحتاجها؟ يمكنني ببساطة كتابة استعلامات SQL الخاصة بي!”. لكنني أستمتع بنظام إدارة قواعد البيانات العلائقية في Django حتى الآن، وأعتقد أنه من الرائع كيف يستخدم Django __ لتمثيل عملية الربط (JOIN)، كما يلي:

Zine.objects
    .exclude(product__order__email_hash=email_hash)

يتضمن هذا الاستعلام خمسة جداول: zines، وzine_products، وproducts، وorder_products، وorders. ولتنفيذه، كان عليّ فقط إخبار Django بوجود حقل ManyToManyField يربط بين جدولي “orders” و”products”، وحقل ManyToManyField آخر يربط بين جدولي “zines” و”products”، لكي يتمكن من ربط جداول zines وorders وproducts.

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

ليس لدي أي قلق بشأن أداء الاستعلامات التي يتم إنشاؤها بواسطة ORM، لذلك أنا متحمس جدًا لـ ORM في الوقت الحالي، على الرغم من أنني متأكد من أنني سأجد أشياءً تُسبب لي الإحباط في النهاية.

عمليات نقل تلقائية

الميزة الرائعة الأخرى في نظام إدارة الكائنات العلائقية (ORM) هي عمليات الترحيل!

إذا قمت بإضافة أو حذف أو تغيير حقل في ملف models.py، فسيقوم Django تلقائيًا بإنشاء نص برمجي للترحيل مثل migrations/0006_delete_imageblob.py.

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

أدرك الآن أن القدرة على إجراء عمليات الترحيل بسهولة أمر مهم بالنسبة لي في الوقت الحالي لأنني أقوم بتغيير نموذج البيانات الخاص بي بشكل متكرر إلى حد ما بينما أكتشف كيف أريده أن يعمل.

أحب الوثائق

كانت لدي عادة سيئة تتمثل في عدم قراءة التوثيق، لكنني استمتعت حقًا بأجزاء توثيق Django التي قرأتها حتى الآن.

على سبيل المثال، تسرد مقدمة النماذج أهم الحقول الشائعة التي قد ترغب في تعيينها عند استخدام ORM.

استخدام SQLite

بعد تجربة سيئة مع Postgres وعدم فهمي لما يجري، قررتُ تشغيل جميع مواقعي الصغيرة باستخدام SQLite. الأمور تسير على نحو أفضل بكثير، وأُحبّ ميزة النسخ الاحتياطي التي تُتيح لي استخدام أمر VACUUM INTO ثم نسخ الملف الناتج.

لقد اتبعت هذه التعليمات لاستخدام SQLite مع Django في بيئة الإنتاج.

بريد إلكتروني مدمج (وأكثر من ذلك)

يبدو أن Django “يحتوي على جميع الميزات المطلوبة”، وهو ما أحبه – إذا كنت أريد حماية من هجمات CSRF، أو سياسة أمان المحتوى، أو أردت إرسال بريد إلكتروني، فكل شيء موجود هناك!

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

لقد وضعت هذا الملف settings/dev.py:

EMAIL_BACKEND = "django.core.mail.backends.filebased.EmailBackend"
EMAIL_FILE_PATH = BASE_DIR / "emails"

ثم قمت بإعداد بريد الإنتاج الإلكتروني على النحو التالي في ملف settings/production.py

EMAIL_BACKEND = "django.core.mail.backends.smtp.EmailBackend"
EMAIL_HOST = "smtp.whatever.com"
EMAIL_PORT = 587
EMAIL_USE_TLS = True
EMAIL_HOST_USER = "xxxx"
EMAIL_HOST_PASSWORD = os.getenv('EMAIL_API_KEY')

هذا جعلني أشعر بأنه إذا كنت أريد ميزة أساسية أخرى للموقع الإلكتروني، فمن المحتمل أن تكون هناك طريقة سهلة للقيام بذلك مدمجة بالفعل في Django.

لا يزال ملف الإعدادات يحتوي على الكثير

ما زلت أشعر ببعض التردد حيال ملف settings.py: يعمل نظام إعدادات Django عن طريق تعيين مجموعة من المتغيرات العامة في ملف، وأشعر ببعض القلق حيال… ماذا لو أخطأت في كتابة اسم أحد هذه المتغيرات؟ كيف سأعرف؟ ماذا لو كتبت WSGI_APPLICATOIN = “config.wsgi.application” بدلاً من WSGI_APPLICATION؟

يمكن التغلب على مشكلة الأخطاء الإملائية في المتغيرات باستخدام أدوات تحليل الكود (Linters) مثل pylint-django أو flake8، والتي تنبه المطور فوراً داخل محرر الأكواد (مثل VS Code) إذا كان هناك خطأ في كتابة الإعدادات.

أعتقد أنني اعتدت على أن يخبرني خادم لغة بايثون عندما أرتكب خطأً إملائيًا، ولذا أشعر الآن ببعض الارتباك عندما لا أستطيع الاعتماد على دعم خادم اللغة.

هذا كل شيء!

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

لا يزال هناك الكثير لأتعلمه، ولم أتعمق بعد في أدوات التحقق من صحة النماذج أو أنظمة المصادقة الخاصة بـ Django.