flask_cms تطوير نظام لإدارة المُحتوى باستخدام إطار العمل Flask - إنشاء الملفّات المطلوبة

مقدّمة

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

بنية التّطبيق المُعتادة

سابقا، كنّا نستعمل ملفّا رئيسيّا واحدا ونقوم بتشغيله ليعمل الخادوم ونتمكّن من الوصول إلى التّطبيق عبر المُتصفّح من العنوان المُعتاد، وهكذا تكون جميع الموجّهات في ملفّ واحد، والملفّات السّاكنة في مجلّد واحد، وملفّات القوالب (ملفّات HTML) تكون جميعها في نفس المُجلّد.

ملفّات التّطبيق المعتادة تكون على الشّكل التّالي:

├── app.py    # ملفّ التّطبيق الرّئيسي
├── config.py # ملفّ الإعدادات
├── static    # مجلّد الملفّات السّاكنة
│   ├── css
│   │   └── style.css
│   ├── img
│   │   └── logo.png
│   └── js
│       └── main.js
├── templates # مجلّد القوالب
│   ├── index.html
│   ├── posts.html

مادام التّطبيق بسيطا فكلّ شيء سيكون على ما يرام، لكن ماذا لو كان التّطبيق يمتلك قسما لتسجيل المُستخدمين، عرض صفحاتهم الشّخصيّة، عرض المقالات، صفحات الأخطاء (مثل عدم تواجد صفحة أو خطأ بالخادوم …)، لوحة تحكّم للمُدير، لوحات التّحكم بأجزاء التّطبيق، واجهة برمجيّة للمُطوّرين API وغير ذلك من الخصائص التّي يتمتّع بها كل تطبيق كبير ذو وظائف مُتعدّدة.

إن استعملت البنية المُشار إليها سابقا، ستواجه العديد من المشاكل، أولا سيكون الملفّ الرّئيسي مليئا بالموجّهات والدّوال، وقد يصل إلى آلاف الأسطر البرمجيّة ما سيجعل مهمّة الصّيانة وإضافة خصائص جديدة أمرا صعبا، كما أنّ ملفّات القوالب ستكون مجتمعة في مجلّد واحد، وإن كنت تعمل على تطوير التّطبيق مع فريق من المُطوّرين فسيجد كل شخص نفسك أمام ملفّات وشيفرات لا علاقة له بها، مثلا لو قُسّمت المهام بحيث يعمل كلّ مطوّر على قسم معيّن من التّطبيق، زيد هنا يعمل على نظام تسجيل للمُستخدمين، وعامر يعمل على إضافة قسم لعرض آخر التّعليقات المُضافة، وسعيد، مُصمّم الويب يعمل على تصميم صفحات أخطاء جميلة، وعبد القادر يعمل على لوحة تحكّم الإدارة، فكيف يُمكن لزيد أن يُعدّل الشيفرة التّي تقوم بتسجيل المُستخدمين دون المساس بالشّيفرة التّي تقوم بإعداد المقالات لعرضها على صفحة المقالات؟

المُخطّطات Blueprints

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

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

هناك نوعان معروفان من المُخطّطات، النّوع الأول يُقسّم ملفّات القوالب مع كلّ وظيفة ليكون كالتّالي:

.
├── run.py
├── config.py
├── project
│   ├── __init__.py
│   ├── posts
│   │   ├── __init__.py
│   │   ├── templates
│   │   │   ├── index.html
│   │   │   ├── post.html
│   │   │   ├── posts_by_category.html
│   │   ├── views.py
│   ├── static
│   │   └── css
│   │       └── style.css
│   ├── templates
│   │   ├── base.html
│   └── users
│       ├── __init__.py
│       ├── templates
│       │   ├── login.html
│       │   └── register.html
│       ├── views.py

أمّا النّوع الثّاني فتجتمع فيه جميع ملفّات HTML في مُجلّد واحد كما يلي:

.
├── run.py
├── config.py
├── project
│   ├── __init__.py
│   ├── posts
│   │   ├── __init__.py
│   │   ├── views.py
│   └── users
│       ├── __init__.py
│       ├── views.py
│   ├── templates
│   │   ├── base.html
│   │   ├── posts/
│   │   ├── users/
│   ├── static
│   │   └── css
│   │       └── style.css

في المثالين السّابقين، لدينا مُخطّطان، مُخطّط خاصّ بالمقالات تحت مجلّد posts، وآخر خاصّ بالمُستخدمين في مجلّد users، ملفّ run.py مسؤول عن تشغيل التّطبيق وأمّا ملفّات __ini__.py فهي لجعل بايثون يفهم بأنّ كلّا من مجلّد المشروع project ومجلّدي المقالات والمُستخدمين عبارة عن حزم.

أمّا ملفّا views.py فسيحتويان على الموجّهات المعنيّة بكلّ وظيفة، فمثلا مُوجّه عرض المقالات “/posts” سيكون في ملفّ posts/views.py أمّا موجّه تسجيل دخول المُستخدمين /login فسيكون في ملفّ users/views.py.

لإخبار فلاسك بأنّ مجلّدي posts و users عبارة عن مُخطّطات، سنعرّف أولا كائنًا من صنف Blueprint في كل من ملفّات __init__.py في المُجلّدين، وبعدها سنقوم بتسجيلهما مع تطبيقنا الذي نُعرّفه في ملفّ __init__.py الأساسي -وهو المُتواجد في مجلّد project-.

لك حريّة استخدام أي نمط تُريده، ففي النّهاية إطار فلاسك مُصمّم ليُوفّر لك كامل الحريّة في طريقة تنظيمك لملفّات التّطبيق، لكن اتّباع نمط مُتعارف عليه أفضل في مُعظم الحالات.

سنستخدم في مشروعنا النّمط الأول، أي أنّ ملفّات HTML ستكون منفصلة حسب الوظيفة.

بايثون 3

سنستعمل في إنشائنا لهذا التّطبيق النّسخة 3 من لغة بايثون، لن يتغيّر الكثير، فالاختلاف بين Python 2 و Python 3 بسيط جدا، وسأقوم بذكر أهم الاختلافات أثناء بناء التّطبيق في الدّروس القادمة.

إذا كنت لا تزال تعتمد على بايثون 2 فأنصحك بأن تنتقل إلى بايثون 3 لأنّ الدّعم لهذه الأخيرة قد أصبح كبيرا ومُعظم مُطوري بايثون يستعملونها الآن، كما أنّها أحدث نُسخة.

إذا أردت أن تتعلم كيفيّة تجهيز بايثون 3 على نظامك، يُمكنك اتّباع هذا الدّرس.

تطبيق كلمة

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

في البداية، سننشئ الملفّات التّاليّة:

.
├── run.py
├── project
│   ├── __init__.py
│   ├── posts
│   │   ├── __init__.py
│   │   ├── templates
│   │   │   ├── posts.html
│   │   ├── views.py
│   ├── static
│   │   └── css
│   │       └── style.css
│   ├── templates
│   │   ├── base.html
│   └── users
│       ├── __init__.py
│       ├── templates
│       │   ├── users.html
│       │   ├── login.html
│       ├── views.py

يُمكنك إمّا إنشاء المُجلّدات والملفّات يدويّا أو عبر نسخ الشيفرة التّالية وحفظها في ملفّ باسم create_app.py لإنشاء الملفّات والمُجلّدات باستعمال لغة بايثون تلقائيّا.

import os
import sys


def mkapp(app_name, blueprints):
    dirs = ['{}', '{}/static', '{}/static/css', '{}/templates']
    static_files = ['{s}/css/style.css']
    templates_files = ['{t}/index.html', '{t}/base.html']


    for d in dirs:
        os.mkdir(d.format(app_name))
    open(app_name + '/' + "__init__.py", "w").close() # project/__init__.py

    for b in blueprints:
        os.mkdir(app_name + '/' + b) # project/posts
        os.mkdir(app_name + '/' + b + '/templates') # project/posts/templates
        open(app_name + '/' + b + '/' + "views.py", "w").close() # project/posts/views.py
        open(app_name + '/' + b + '/' + "__init__.py", "w").close() #project/posts/__init__.py
        open(app_name + '/' + b + '/templates/' + b + ".html", "w").close() # project/posts/templates/index.html


    for sf in static_files:
        static_file = app_name + '/' + sf.format(s='static') # project/static
        open(static_file, 'w').close()

    for tf in templates_files:
        templates_file = app_name + '/' + tf.format(t='templates') # project/templates
        open(templates_file, 'w').close()

if __name__ == '__main__':
    app = sys.argv[1]
    blueprints = sys.argv[2:]
    mkapp(app, blueprints)

يُمكنك تنفيذ السكربت بالأمر التّالي:

$ python3 create_app.py project posts users

بعدها أنشئ ملفّ login.html في مجلّد project/users/templates لأنّ السكربت لن يقوم بإنشائه.

عليك كذلك إنشاء ملفّي run.py وconfig.py داخل مُجلّد kalima، الملفّ الأول مسؤول عن تشغيل الخادوم/ أمّا الملفّ الثّاني فمسؤول عن إعدادات التّطبيق.

خاتمة

تعرّفنا في هذا الدّرس على بنية التّطبيق الذي سنبنيه وكيفيّة توزيع ملفّاته إذ أنشأنا المُجلّدات والملفّات التّي ستكون مسؤولة عن الجانب العملي للتّطبيق، في الدّرس القادم، سنبدأ بتجهيز البيئة البرمجيّة وتنصيب أهم الحزم التّي سنحتاج إليها للبدء بتطوير التّطبيق.