Why Do We Need a Framework? — ليه بنحتاج Framework؟
الفرق بين الكتابة من الصفر واستخدام إطار عمل جاهز
الطالب دلوقتي عارف Python — بس محتاج طريقة أسرع عشان يبني Web Applications كاملة. من غير Framework، كل مشروع هتكتب فيه كل حاجة من الصفر: الـ Routing، الـ Forms، الـ Database Logic، الـ Templates، الـ Admin... ده بيضيع وقت ضخم جداً ومليان أخطاء.
❌ بدون Framework
- تكتب الـ Routing يدوياً من الصفر
- تبني الـ Database Layer وحدك
- تعمل الـ Admin Interface يدوياً
- تتعامل مع الـ Security وحدك
- بطيء جداً وعرضة للأخطاء
✅ مع Django Framework
- الـ Routing جاهز وسهل التكوين
- ORM بيتعامل مع الـ Database بكود Python
- Admin Panel جاهز تلقائياً
- Security Features مدمجة
- سريع، آمن، ومنظم
📐 Structure
بيخلي الـ Team يشتغل على أسلوب واحد منظم — كل حاجة في مكانها الصح.
⚡ Speed
بتبني Features أسرع بكتير عشان الأساسيات موجودة جاهزة.
🔒 Security
الـ Framework بيحميك من أشهر الثغرات زي SQL Injection و CSRF تلقائياً.
What is Django? — ما هو Django؟
تعريف شامل للـ Framework واللي بيميزه
الـ Django هو Web Framework مبني بـ Python ومصمم للـ Rapid Development (التطوير السريع). هو مش لغة برمجة — Python هي اللغة، وDjango هو إطار العمل المبني فوقيها.
🔋 "Batteries Included" — Django بيجي بكل حاجة:
- نظام الـ Routing جاهز
- Admin Interface مدمج
- ORM للتعامل مع الـ Database
- نظام الـ Authentication
- معالجة الـ Forms
- حماية من الثغرات الشائعة
🎯 ليه Django للتعليم؟
- Readable و Practical زي Python
- قريبة من طريقة عمل الـ Industry الحقيقي
- Python + Web + Templates + URLs + Models في بيئة واحدة
- Community ضخم جداً ودعم ممتاز
MVT Architecture — معمارية نموذج-عرض-قالب
قلب Django — Model · View · Template
{{ var }}، {% for %}، {% if %}.| الدور | في MVC | في Django MVT |
|---|---|---|
| إدارة البيانات | Model | Model |
| المنطق والـ Logic | Controller | View (اسمه مختلف!) |
| العرض للمستخدم | View | Template (اسمه مختلف!) |
Django Request–Response Flow — رحلة الـ Request في Django
من المتصفح للـ Response — خطوة بخطوة
Setup Workflow — خطوات إعداد بيئة Django
من الصفر لسيرفر شغّال — 10 خطوات
File → Open Folder → your_project_folder — افتح الفولدر كله مش ملف واحد، عشان VS Code يدير المشروع كـ Workspace كامل ويفتح الـ Terminal في المكان الصح.Terminal → New Terminal أو Ctrl + ` — الـ Terminal هو المكان اللي هتكتب فيه كل أوامر Django.python --version — لو ظهر رقم إصدار كل حاجة تمام. لو ظهر "not recognized" يبقى Python مش مثبت أو مش في الـ PATH.python -m venv venv — بيعمل بيئة Python معزولة للمشروع ده بس. بعد التنفيذ هيتعمل فولدر اسمه venv/ في مشروعك.venv\Scripts\activatemacOS/Linux:
source venv/bin/activateلازم تشوف
(venv) في أول سطر الـ Terminal — ده دليل إن البيئة شغّالة.
pip install django — بيحمّل Django في الـ Virtual Environment بس مش في النظام كله. تأكد إن الـ venv شغّال الأول!django-admin startproject myproject — بيولّد هيكل المشروع تلقائياً مع كل الملفات الأساسية.cd myproject — ضروري! لازم تكون في نفس الفولدر اللي فيه ملف manage.py عشان أوامر Django تشتغل.python manage.py runserver — بيبدأ الـ Local Development Server. هيظهر في الـ Terminal عنوان السيرفر. وقفه بـ Ctrl + Chttp://127.0.0.1:8000/ — الـ IP 127.0.0.1 يعني جهازك (localhost). البورت 8000 هو البورت الافتراضي لـ Django.| المشكلة | السبب المحتمل | الحل |
|---|---|---|
| "python is not recognized" | Python مش مثبت أو مش في الـ PATH | أعد التثبيت وفعّل "Add Python to PATH" |
Django مش موجود بعد pip install | الـ Virtual Environment مش شغّال | تأكد من وجود (venv) في الـ Terminal |
| Port 8000 مشغول | تطبيق تاني شغّال على نفس البورت | استخدم python manage.py runserver 8001 |
| "manage.py not found" | إنت في الفولدر الغلط | تأكد إنك داخل فولدر المشروع الصح |
Virtual Environment — البيئة الافتراضية
عزل مشروعك عن باقي المشاريع على نفس الجهاز
الـ Virtual Environment هو بيئة Python معزولة خاصة بكل مشروع. فكّر فيه زي "طاولة مختبر خاصة" — كل الأدوات (الـ Packages) اللي على الطاولة دي بتاعة المشروع ده بس.
❌ بدون Virtual Environment
- كل الـ Packages بتتثبت globally في النظام
- مشروعين محتاجين نفس الـ Package بإصدارات مختلفة = مشكلة
- صعب تنقل المشروع لجهاز تاني
✅ مع Virtual Environment
- كل مشروع عنده Packages منفصلة
- مفيش تعارض بين المشاريع
- سهل تنقل المشروع بـ requirements.txt
# إنشاء الـ Virtual Environment
python -m venv venv
# تشغيله على Windows
venv\Scripts\activate
# تشغيله على macOS/Linux
source venv/bin/activate
# لو شغّال هتشوف في الـ Terminal:
(venv) C:\Users\...>
# إيقافه
deactivate
pip install django. لو نسيت، الـ Django هيتثبت في النظام كله مش في المشروع.Project Structure — هيكل مشروع Django
كل ملف بيعمل إيه؟
myproject! الأول هو الفولدر الخارجي (Outer). الثاني هو الـ Python Package الداخلي (Inner) اللي فيه الإعدادات.نقطة دخول أوامر Django — الأمر ده بتشتغل منه:
python manage.py runserver— تشغيل السيرفرpython manage.py startapp— إنشاء Apppython manage.py makemigrations— إنشاء Migrationspython manage.py migrate— تطبيق Migrationspython manage.py createsuperuser— إنشاء Admin User
manage.py.لوحة التحكم الرئيسية للمشروع — فيه:
INSTALLED_APPS— قائمة الـ Apps المثبتةDATABASES— إعدادات الـ DatabaseTEMPLATES— إعدادات الـ TemplatesSTATIC_URL— مسار الملفات الثابتةDEBUG— وضع التطوير (True/False)
خريطة الطرق (Road Map) — بيربط URL Paths بالـ Views. لما المتصفح يطلب /students/، Django بيبص في urls.py عشان يعرف أي View يشتغل.
ملفات الـ Deployment — بتساعد الـ Web Servers يتكلم مع Django.
- WSGI (Web Server Gateway Interface) — للـ Traditional Servers
- ASGI (Async Server Gateway Interface) — للـ Async Servers
Django Project vs Django App — الفرق بين المشروع والتطبيق
أحد أهم المفاهيم للمبتدئين في Django
الـ Project هو الحاوية الكبيرة (Container) للموقع كله. بيتنشأ بالأمر: django-admin startproject myproject
- الـ Overall Configuration بتاعة الموقع
- الـ Global URLs
- الـ Database Settings
- بيحتوي على كذا App جوّاه
الـ App هو Module متكامل بيركّز على Feature معينة. بيتنشأ بالأمر: python manage.py startapp students
- بيحتوي على Models, Views, Templates, URLs خاصة بيه
- مثال:
students،courses،blog - Python Package مكتمل
- ممكن يتستخدم في مشاريع تانية
INSTALLED_APPS في settings.py عشان Django يعرف بيها!INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'students', # ← ضيف اسم الـ App هنا
]
تنويه: علمياً، الـ Django App هي "Python package with its own components"، وصيغة "extended package..." غير دقيقة، لكن للامتحان نختار Both.
Views & URL Configuration — الـ Views والـ Routing
ربط الـ URLs بالـ Python Logic
الـ View في Django هو Python Function (أو Class) بيستقبل HTTP Request ويرجع HTTP Response. هو اللي بيشتغل على الـ Logic ويقرر إيه اللي هيترجع للمستخدم.
from django.http import HttpResponse
def home(request): # كل View لازم تاخد request
return HttpResponse("Hello, Django!")
def about(request):
return HttpResponse("About page")
HttpResponse بيرجع نص بسيط — مناسب للـ Testing. في الواقع بنستخدم render() عشان نرجع Template HTML كاملة.الـ urls.py بيحدد "لما المستخدم يطلب URL معين، أي View تشتغل؟" — بيستخدم الدالة path() عشان يربط URL بـ View.
from django.urls import path
from . import views
urlpatterns = [
path('', views.home, name='home'), # /
path('students/', views.student_list, name='students'), # /students/
path('about/', views.about, name='about'), # /about/
]
المشروع الكبير (Project) بيستخدم include() عشان يحوّل الـ Requests للـ App المناسبة — بيخلي كل App تدير URLs بتاعتها.
from django.contrib import admin
from django.urls import path, include
urlpatterns = [
path('admin/', admin.site.urls),
path('students/', include('students.urls')), # ← يحوّل لـ App
]
from django.shortcuts import render
def student_list(request):
students = ["Ali", "Mona", "Sara"] # أو من الـ Database
return render(request, 'students/list.html', {
'students': students, # Context Dictionary
'title': 'Student List',
})
render(request, template_name, context) بتاخد ثلاثة حاجات: الـ Request، اسم الـ Template، والـ Context Dictionary اللي فيه البيانات اللي هترجع للـ Template.Django Templates — قوالب Django
Dynamic HTML باستخدام Django Template Language (DTL)
{{ }} — Variables
بيعرض قيمة متغير Python — Django بيبدّل {{ name }} بقيمة الـ Variable من الـ context dictionary.
{% %} — Template Tags
للـ Logic والـ Control Flow — زي for، if، block، load. مش بتعرض قيمة، بتعمل منطق.
<!-- {{ }} للمتغيرات — بيتبدّل بقيمة Python -->
<h1>Hello, {{ name }}!</h1>
<!-- {% %} للـ Logic والـ Control -->
{% for student in students %}
<p>{{ student.name }}</p>
{% endfor %}
{% if user.is_authenticated %}
<p>Welcome back!</p>
{% else %}
<p>Please login.</p>
{% endif %}
<!-- {# #} للـ Comments (مش بتظهر في HTML) -->
{# ده comment مش بيظهر للمستخدم #}
{{ name }} = Variable (بيتبدّل بقيمة Python). {% tag %} = Logic Tag (for, if, block). {# comment #} = Comment.| الخاصية | الوصف | مثال |
|---|---|---|
forloop.counter | رقم التكرار الحالي (يبدأ من 1) | 1، 2، 3... |
forloop.counter0 | رقم التكرار الحالي (يبدأ من 0) | 0، 1، 2... |
forloop.revcounter | عدد التكرارات المتبقية (من 1) | 3، 2، 1... |
forloop.first | True لو دي أول دورة | True / False |
forloop.last | True لو دي آخر دورة | True / False |
forloop.counter بدون أقواس. لو الامتحان عرضلك forloop.counter() بأقواس → ده غلط! الـ forloop attributes مش methods، مش ليها أقواس. وكمان forloop.reverse وforloop.previous وforloop.lastitem = مش موجودين.{% for student in students %}
<tr>
<td>{{ forloop.counter }}</td> {# الرقم من 1 #}
<td>{{ student.name }}</td>
{% if forloop.first %}
<td>First Student!</td>
{% endif %}
</tr>
{% empty %}
<tr><td>No students found.</td></tr>
{% endfor %}
# ✅ الصح — Template Tag في Django
{% for x in y %}
{{ x }}
{% endfor %}
# ❌ غلط — أقواس Python عادية
(for x in y)
# ❌ غلط — صيغة PHP أو ERB
<% for x in y %>
{% for x in y %} — مش (for x in y) ومش <% for x in y %>.Migrations — ترحيل التغييرات للـ Database
إزاي Django بيطبّق تغييرات الـ Model على الـ Database
الـ Migrations هي الطريقة اللي Django بيترجم بيها التغييرات اللي عملتها في الـ Models (Python Classes) لتغييرات حقيقية في الـ Database Tables. بدل ما تكتب SQL يدوياً، Django بيكتبه عنك.
python manage.py makemigrations
- بيفحص التغييرات في الـ Models
- بيولّد ملف Migration في
migrations/ - مش بيعدّل الـ Database فعلياً — بس بيجهّز الخطة
python manage.py migrate
- بيقرأ ملفات الـ Migrations
- بيطبّقها على الـ Database الفعلي
- بيعمل الجداول الجديدة أو يعدّل الموجودة
python manage.py makemigrations ثم python manage.py migrate.Django Admin — لوحة الإدارة المدمجة
واجهة جاهزة لإدارة البيانات من غير ما تكتب كود
الـ Django Admin هو Interface جاهز ومدمج في Django بيخليك تتعامل مع البيانات في الـ Database بدون ما تكتب أي كود HTML أو Python إضافي. عبره تقدر تضيف وتعدّل وتحذف Records مباشرة.
🔑 ليه بيحبّوه؟
- جاهز من أول يوم بدون Setup
- بيعرض البيانات في Interface نظيف
- مناسب للـ Testing في بداية التطوير
⚙️ خطوات الاستخدام:
- سجّل الـ Model في
admin.py - أنشئ Superuser
- افتح
/admin/في المتصفح
from django.contrib import admin
from .models import Student
admin.site.register(Student) # ← الـ Syntax الصح!
# ❌ غلط: admin.register(Student)
# ❌ غلط: site.admin.register(Student)
# ❌ غلط: models.admin.register(Student)
admin.site.register(Model_name). مش admin.register() ومش django.admin.register(). ده السؤال الأكثر تكراراً في المادة!python manage.py createsuperuser
# الـ Terminal هيطلب منك:
# Username: admin
# Email: admin@example.com
# Password: ****
# بعدين افتح: http://127.0.0.1:8000/admin/
python manage.py createsuperuser — مش python manage.py createuser.# ✅ الصح — من امتحان 2024
from members.models import Member
# ❌ غلط
import Member from members
import members.Member
Member من App اسمها members؟ الإجابة الصح: from members.models import Member.أسئلة الامتحانات — Django Part I
أسئلة من امتحانات 2021 و 2024 و 2025 مرتبة حسب ترتيب الشرح 🇪🇬
Django هو Python Web Framework — مش لغة برمجة ومش Software عام ومش Database. Python هي اللغة، وDjango هو الـ Framework المبني بيها.
🇪🇬 زي الفرق بين اللغة الإنجليزية (Python) وكتاب مكتوب بيها (Django).
Django بيستخدم نمط MVT (Model–View–Template). الـ View في Django بيشتغل زي الـ Controller في MVC، والـ Template بيشتغل زي الـ View في MVC.
🇪🇬 المصطلح: Model = البيانات، View = المنطق، Template = الشكل.
MVT = Model + View + Template. الثلاثة مع بعض ضروريين.
🇪🇬 لما السؤال يسأل عن Django Architecture → دايماً الإجابة الثلاثة مع بعض.
علمياً، الـ Django App هي Python Package ولها مكوناتها الخاصة (Models, Views, Templates, URLs). صياغة "An extended package..." في الاختيار A غير دقيقة تقنياً، لكن تم احتسابها كـ Both في الامتحان.
🇪🇬 لما السؤال يقول "Both" أو "All" في Django، الغالب هي الإجابة المطلوبة في الامتحانات!
django start my_tennis_clubpy manage.py start-django my_tennis_clubdjango-admin startproject my_tennis_clubdjango-admin startproject my_tennis_clubالأمر الصح لإنشاء مشروع Django جديد هو
django-admin startproject project_name.
🇪🇬 حفظ: django-admin = أداة الأوامر. startproject = إنشاء مشروع.
{{ name }} mean in Django Templates?الأقواس المزدوجة
{{ name }} في الـ Template = متغير Python. Django بيبدّل {{ name }} بالقيمة الفعلية من الـ context dictionary.
🇪🇬 {{ }} = Variable. {% %} = Logic Tag. {# #} = Comment.
{% %} is used for:{% %} = template tags للـ Logic (for, if, block, load). مش للعرض ومش للـ comments.
🇪🇬 Option A غلط لأن {{ }} هو اللي بيعرض variable. {% %} للـ Logic زي for وif.
الـ Valid forloop attributes هي:
counter، counter0، revcounter، first، last.ملاحظة مهمة: الامتحان ظهر فيه
forloop.counter() بأقواس — ده غلط! بدون أقواس. وforloop.reverse و forloop.previous و forloop.lastitem = مش موجودين.
🇪🇬 الـ forloop attributes مش Methods — مش ليها أقواس!
(for x in y)<% for x in y %>{% for x in y %}{% for x in y %}الـ Django Template Language بيستخدم
{% %} للـ Tags. الـ for loop يبدأ بـ {% for x in y %} وبينتهي بـ {% endfor %}.
🇪🇬 Option A صيغة Python عادية. Option B صيغة PHP/ERB. الصح دايماً {% %} في Django.
admin.site.register(Model_name)admin.register(Model_name)django.admin.register()Model.admin.register()admin.site.register(Model_name)ده السؤال الأكثر تكراراً — جاء في 2021 و2024 معاً! الـ Syntax الصح دايماً هو
admin.site.register().
🇪🇬 احفظ ده كويس: admin.site.register(اسم الـ Model). لازم يكون admin.site مش admin بس.
عشان Model يظهر في الـ Admin Panel، لازم تسجّله في
admin.py بالأمر admin.site.register(Model_name).
🇪🇬 من 2025: للـ Admin بتسجّل في admin.py مش settings.py!
الـ Migrations بتعمل الثلاثة حاجات: تتبّع تغييرات الـ Schema، بتتنشأ بـ makemigrations، وبتتطبّق بـ migrate.
🇪🇬 لما السؤال يقول "All" في Django، الغالب هي الإجابة الصح!
python manage.py runmigrationspython manage.py executemigrationspython manage.py makemigrationsالأمر اللي بيخلي التغييرات تتنفذ فعلياً في الـ Database هو
python manage.py migrate وهو مش موجود في الاختيارات. makemigrations بيجهّز ملف الترحيل بس.
🇪🇬 makemigrations = خطوة 1 (بيجهّز). migrate = خطوة 2 (بيطبّق في الـ DB).
members, and a model named Member, what is the correct syntax to import the model?from members.models import Memberimport Member from membersimport members.Memberfrom members.models import Memberالـ Models في Django بتكون في ملف
models.py داخل الـ App. الـ Syntax الصح هو from app_name.models import ModelName.
🇪🇬 دايماً: from [اسم الـ App].models import [اسم الـ Model]
الـ Views في Django تمثل الـ Logic Layer (زي الـ Controller في MVC). الـ Presentation Layer هو الـ Templates — اللي بيتحكم في إيه اللي المستخدم بيشوفه.
🇪🇬 View = Logic. Template = Presentation. الخلط بينهم من أشهر الأخطاء!
admin.py file to view it in the administration site of Django.صح — بنسجّل الـ Models في
admin.py بالأمر admin.site.register(Model) عشان تظهر في الـ Admin Interface.
لما تعمل
django-admin startproject، الملفات اللي بتتولد هي: manage.py، settings.py، urls.py، wsgi.py، asgi.py. ملف templates مش من ضمن الملفات الافتراضية — إنت اللي بتعمله يدوياً.
🇪🇬 الـ templates folder مش بيتعمل تلقائياً مع startproject.
python mange.py createuserالجزء الأول صح — Django عنده Admin Interface مدمج. لكن الأمر
python manage.py createuser غلط!الأمر الصح هو:
python manage.py createsuperuser
🇪🇬 احفظ: createsuperuser مش createuser!
الأمر
migrate بيطبّق التغييرات على الـ Database (Apply Changes) — مش بيعرضها فقط. اللي بيعمل الملف الوصفي هو makemigrations.
🇪🇬 migrate = بيطبّق. makemigrations = بيولّد ملف التغييرات.
الـ WSGI (Web Server Gateway Interface) بيتعامل مع الـ Requests بشكل Synchronous / Sequential — طلب طلب بالترتيب. للتعامل مع الـ Requests بشكل Async، بيستخدم ASGI.
🇪🇬 WSGI = Sequential (متزامن). ASGI = Async (غير متزامن).
settings.py file.الـ settings.py مكانه تسجيل الـ Apps (في INSTALLED_APPS) — مش الـ Models. الـ Models بتتسجّل في
admin.py بالأمر admin.site.register().
🇪🇬 settings.py = للـ Apps. admin.py = للـ Models.