01. מבוא, יצירת אפליקציה וכתובות ניתוב
Django, (להלן גם ג’אנגו) הוא פריימוורק חינמי מבוסס קוד קוד פתוח, הפופולארי ביותר לבניית אפליקציות אינטרנט (אתרים) בעזרת פייתון.
בחברות המשתמשות בפלטפורמה זו נוכל למצוא את אינסטגרם, יוטיוב, ספוטיפיי ועוד רבות אחרות.
אתרי אינטרנט לעיתים קרובות עושים שימושים במאגרי מידע (DataBases) וניהול משתמשים. ג’אנגו מגיעה עם פיצ׳רים מוכנים הניתנים להגדרה בקלות, מה שהופך תהליך זה לעבודה לקלה במיוחד.
כמו כן ג’אנגו מגיע עם חבילות קוד מובנות רבות בשביל לחסוך לנו עבודה. כמו למשל סביבת ניהול (admin site). חבילה לצורך רישום משתמשים (Authentication), מנגנון זיכרון קאש (Caching) מנגנוני הגנה מהתקפות רשת נפוצות ועוד.
אז בואו נתחיל…
יצירת פרויקט חדש
לפני שנתחיל לעבוד עם ג’אנגו, נצטרך כמובן להתקין אותו, אז נריץ מתוך הטרמינל את הפקודה:
pip install django
לאחר שהתקנו את ג’אנגו, הפקודה django-admin תהיה מוכרת לסביבת העבודה שלנו, ולכן אם מתוך הטרמינל נכתוב django-admin ואז אנטר, נוכל לראות את רשימת הפקודות שג’אנגו מאפשרת. (תכף נכיר פקודות פרקטיות)
למעשה לאחר ההתקנה, תחת ספריית django ישנו קובץ:
<project_path>/venv/Lib/__main__.py
(אם אנו עובדים ב-mac או לינוקס, אז תחת venv/bin נראה את הקובץ django-admin, החלופה של הנ”ל)
קובץ זה הוא סקריפט הניהול של ג’אנגו, ופקודות django-admin שראינו, מאחורי הקלעים מריצה קובץ זה.
אז בואו ונכיר את הפקודה הראשונה – יצירת פרוייקט חדש של ג’אנגו:
django-admin startproject <project_name>
פקודה זו יוצרת פרויקט חדש.
אם לצורך הדוגמה נבחר לפרויקט את השם my_project, אז נכתוב:
django-admin startproject my_project
לאחר שנריץ את הפקודה, נראה שנוצרה לנו תיקיה חדשה עם שם הפרויקט שבחרנו. בדוגמה האחרונה, עם השם my_project. (אם אתם לא רואים את התיקייה שנוצרה, תעשו ריפרש)
תחת התיקיה החדשה – תיקיית הפרויקט, נשים לב ל-2 רכיבים.
- קובץ בשם manage.py – זהו הקובץ שדרכו נבצע פקודות ג’אנגו (תכף נראה דוגמאות) למעשה זהו קובץ דומה לקובץ הראשי שהזכרנו של פקודות django-admin, אבל הקובץ manage.py הוא ספציפי לפרויקט החדש שיצרנו, ולכן פקודות של הפרויקט יעברו דרכו.
- תיקיה שגם נושאת את שם הפרויקט my_project.
תחת תיקיה זו נמצאים קבצי ההגדרות של הפרויקט. למשל נזהה שם קובץ בשם settings.py. ביצירת פרויקט חדש בג’אנגו, נוצרים לנו גם מספר קבצים תחת תיקייה זו ותכף נכיר את הקבצים השונים ומה מטרתם.
אז עד כה אם נסכם: התקנו את ג’אנגו, ובאמצעות פקודת django–admin יצרנו פרוייקט חדש, ופקודת היצירה של הפרוייקט גם יצרה לנו מספר תיקיות וקבצים בסביבה שלנו.
הפעלת השרת
שרת (server) כשמו כן הוא, תפקידו “לשרת”.
השרת הוא תוכנה ש”מקשיבה” לקריאות/בקשות ברשת, ומחזירה ערכים/תכנים כלשהם בתגובה לבקשות שהתקבלו.
נחדד: כאשר אנו פונים לאתר של facebook מתוך הדפדפן שלנו, אז השרת של facebook מקבל את הקריאה הזו (כי שמנו את הכתובת של פייסבוק בשורת הכתובת) והוא מחזיר חזרה דף html שמכיל את התוצאה שאנו רואים בדפדפן.
ונחזור אלינו…
בשביל לגרום לשרת ג’אנגו שלנו “לעלות לאוויר” ולהתחיל להקשיב לבקשות, נכתוב בטרמינל את הפקודה:
manage.py runserver
שימו לב – את הפקודה צריך להריץ לאחר ש”נכנסנו” לתוך תיקית הפרויקט שנוצרה.
למשל אם נמשיך עם שם הפרויקט מהדוגמה, אז לאחר שנפתח את חלון ה-terminal, נעשה:
cd my_project
פקודה זו “מעבירה” אותנו לתיקיית הפרויקט של ג’אנגו, ואז נריץ את הפקודה runserver כנ”ל.
הפקודה runserver מפעילה שרת ג’אנגו שמקשיב לבקשות http בפורט הדיפולטיבי 8000.
מה זה פורט? פורט הוא נקודת תקשורת במחשב. על פורט אחד רק שרת אחד יכול להתחבר.
לידע כללי:
כאשר אנו פונים לכתובת כלשהי ברשת מתוך הדפדפן שלנו (למשל לפייסבוק…) אז הפורט שאליו אנו פונים הוא פורט ברירת המחדל 80, (או 443 אם זה שרת מאובטח) אלא אם כן נציין אחרת. אצלינו, בסביבת הפיתוח של ג’אנגו, השרת מתחבר דווקא לפורט 8000.
ונמשיך:
מתוך פלט הפקודה runserver נוכל לזהות את הכתובת (הלוקאלית-מקומית) המלאה שהשרת מאזין לה:
http://127.0.0.1:8000/
אם נלך לדפדפן ונפתח כתובת זו (שהיא כאמור כתובת מקומית לפורט על המחשב שלנו), אנו נראה את דף ברירת המחדל של ג’אנגו:
אם נחזור למסך הטרמינל, נוכל לראות שבכל פעם שנעשה ריפרש בדפדפן על העמוד שנפתח, שזה בעצם גם פנייה לשרת, אז בפלט למסך בטרמינל תופיע שורה שמציגה את הקריאה (log).
מאחר וג’אנגו מוגדר כברירת מחדל לרוץ במצב debug, אז אנו רואים את הפלטים הללו. אם נרצה, נוכל לגשת לקובץ בשם settings שיש לנו בפרוייקט:
/my_project/my_project/settings.py
קובץ זה מכיל את ההגדרות הכלליות של פרויקט הג’אנגו שלנו.
אם נמצא ונשנה את ערך המשתנה DEBUG המופיע שם להיות False במקום True, כמות הלוגים (הפלטים) במסך שלנו תהיה “נמוכה” יותר אבל ממש אין סיבה לעשות זאת בשלב הזה.
בשביל לעצור את השרת, נלחץ בטרמינל ctrl+c.
אז אם נסכם, למדנו:
- להתקין את ג’אנגו.
- ליצור פרויקט חדש.
- להרים את השרת כך שיוכל להקשיב לקריאות.
יצירת אפליקציית ג’אנגו
בשלב הבא נרצה ליצור “אפליקציה” – הכוונה היא לשירות שג’אנגו מספק שישמש אותנו בשביל ליצור Backend עבור אתר אינטרנט.
במילים אחרות – האפליקציה היא אתר האינטרנט שאנו רוצים לבנות תחת מעטפת הפרויקט שיצרנו.
במדריך זה אנו נעבוד עם אפליקציה אחת. אבל הלוגיקה של החלוקה הזו בין פרויקט לאפליקציה היא כדי שיהיה אפשר ליצור מספר אפליקציות תחת פרויקט אחד. ומעוד סיבות שלאט לאט נבין יותר.
אז בשביל ליצור אפליקציה חדשה נריץ בטרמינל את הפקודה:
python manage.py startapp my_app
תוודאו לפני ההרצה, שהטרמינל “יושב” בתוך התיקיה שבה קובץ ה- manage.py נמצא. אחרת, תיקיית האפליקציה עלולה להיווצר במקום הלא נכון, או שבכלל הפקודה כלל לא תתבצע.
ובכן, תוצאת הפקודה הנ”ל תהיה “אפליקציה חדשה” – שזה אומר שתיווצר תיקיה חדשה בשם של האפליקציה שהגדרנו.
תחת תיקיית האפליקצייה שנוצרה ישנם מספר קבצים שבהם נשתמש בשביל הגדרות כאלו ואחרות.
בשביל לחבר את פרויקט הג’אנגו שלנו לאפליקציה, נרצה להוסיף את השם my_app (שם האפליקציה החדשה) לרשימה של INSTALLED_APPS. בקובץ settings.
ברשימה כבר ישנם כל מיני אפליקציות ברירת מחדל שמגיעות עם דג’אנגו, ונוסיף את שלנו לרשימה:
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'my_app',
]
נזכיר: בג’אנגו, אנו מקבלים הרבה דברים “בחינם”. מה שנדרש מאיתנו זה להגדיר נכון את מבנה התיקיות ואת קבצי ההגדרות. לכן חשוב שנדייק בחלקים הללו, כמו למשל בדוגמה זו האחרונה של חיבור נכון בין האפליקציה לפרויקט.
אם נסכם:
למדנו להתקין את ג’אנגו, ליצור פרוייקט, ליצור אפליקציה תחת הפרוייקט ולשייך את האפליקציה לפרויקט.
מניסיון: בהתחלה יש קושי להבין את החלוקה של התיקיות בג’אנגו.
אז חשוב לא לבלבל בין תיקית הפרויקט לתיקית ההגדרות של הפרויקט יש להן את אותו שם אבל הן מתפקדות אחרת. כמו כן, נבדיל בין תיקיית הגדרות הפרוייקט ותיקיית האפליקציה, שיושבות שתיהן תחת תיקיית הפרוייקט הכללית.
אם כך מבנה הפרויקט הוא כזה:
> my_project (project root)
> my_project (project settings folder)
> my_app (app folder)
> manage.py (manager script)
מיד נראה איך להוסיף לוגיקה כלשהי לאפליקצייה שיצרנו.
פונקציות ניתוב
תקשורת בין שרת ללקוח נעשית בפרוטוקול הנקרא HTTP.
כזכור, אחת המטרות המרכזיות של שרת היא לקבל קריאה מדפדפן (או כל מקור אחר) ולהגיב.
התגובה נעשית על ידי פונקציה שנקראת פונקצית ניתוב, או באנגלית: view function.
אם כך, שרת הג’אנגו שמקבל קריאת http ממקור כלשהו (למשל מדפדפן), יפעיל בהתאם פונקציית ניתוב שהיא זו שתהיה אחראית מה יוחזר בתגובה לקריאה.
את פונקציות הניתוב של אפליקציית ג’אנגו ננהל תחת תיקיית האפליקציה בקובץ בשם views.py. שימו לב, הקובץ כבר קיים שם.
אז בואו נפתח את הקובץ views.py ושם ניצור פונקציה חדשה, נקרא לה (לדוגמה) index. ונגדיר אותה כך שהיא תחזיר את המשפט “שלום עולם”.
כך ייראה הקובץ views.py:
from django.http import HttpResponse
def index(request):
return HttpResponse("hello world")
יש פה כמה דברים לשים לב אליהם.
הפונקציה index צריכה להיות מוגדרת כך שהיא מקבלת פרמטר המייצג את הבקשה שהתקבלה (בדוגמה כאן קראנו לו request, שזו מוסכמה נוחה לכך).
מאחר ופונקצית הניתוב מגיבה לקריאה שעשויה להגיע עם נתונים כאלו או אחרים, הנתונים של הקריאה מתקבלים בתוך פרמטר זה.
בנוסף, הפונקציה מחזירה אובייקט httpResponse. האוביקט הזה מוכר לדג’נגו והוא יודע איך לקחת אותו ולייצר ממנו תשובה מובנת למשתמש.
האובייקט HttpResponse מקבל בדרך כלל מחרוזת המייצגת את תוכן הדף שנציג ללקוח (בדפדפן).
נחדד קצת, שהארגומנט request המתקבל לפונקציה הוא אובייקט ממחלקת WSGIRequest שזה קיצור של Web Server Gateway Interface. זוהי מחלקה היורשת מהמחלקה העיקרית המייצגת את הבקשות המתקבלות לניתוב, הנקראת HttpRequest.
כאמור, המשתנה הזה זהו אובייקט שמייצג את הבקשה של ג’אנגו לניתוב הנוכחי. בין השאר דרכו נוכל לדעת את “סוג” הקריאה – על ידי פנייה ל- request.method שיכיל למשל POST או GET.
דרכו נוכל גם לגשת למידע המופיע בבקשה, על ידי פניה ל-body או headers וכדומה.
אז יצרנו פונקציה שיודעת לקבל קריאה ולהחזיר מחרוזת.
איך נחבר את הפונקציה הזו לכתובת כלשהי שאפשר יהיה לפנות אליה?
את מערכת הניתוב של הפונקציות (ה-urls שהלקוח יפנה אליהם שיפעילו את פונקציות הניתוב) נגדיר בקובץ נפרד.
אז נפתח קובץ חדש תחת תיקיית האפליקציה, נקרא לו urls.py (השם לא קריטי, אבל זו מוסכמה אז נצמד לכך).
בתוך קובץ זה ניצור משתנה-רשימה בשם urlpatterns (חייב להיות כתוב בדיוק כך).
בתוך הרשימה נציין את הניתובים באופן הבא:
from django.urls import path
from . import views
urlpatterns = [
path("hello", views.index)
]
אם נבין את מה שכתבנו:
יצרנו רשימה של “ניתובים”, וכרגע שמנו בה רק ניתוב אחד, המנתב את הכתובת hello לפונקצייה index. (שימו לב שצריך רק לציין את שם הפונקציה, בלי לבצע אליה ממש קריאה עם סוגריים עגולות).
בעצם בהגדרה זו אנו קובעים שכל מי שייגש לכתובת hello, יפעיל את הפונקציה index, ומה שהיא תחזיר, זה מה שמי שביצע קריאה ייראה כתשובה.
אבל הגדרה זו של כתובת הניתוב הינה ברמת האפליקציה. אנו נרצה שברמת הפרויקט (השרת) יהיה קישור בין כתובות הניתוב של האפליקציה לכתובות הניתוב שהשרת מזהה. לשם כך, תחת תיקית הפרוייקט, נזהה שכבר קיים גם כן קובץ בשם urls.py.
בקובץ זה יש כבר רשימה בשם urlpatterns, ומה שנרצה זה “להוסיף אליה” את הקובץ החדש של כתובות הניתוב שאנו יצרנו לאפליקציה.
לשם כך, ולשם הדוגמה, נניח שכל פניה לשרת עם כתובת הניתוב שמתחילה במילה app תשמש כניתוב לכתובות הניתוב של האפליקציה.
אז נוסיף את השורה הבאה בקובץ urls של הפרויקט (צריך להוסיף גם את שורת ה-import למעלה):
from django.urls import include
urlpatterns = [
path('app/', include('my_app.urls')),
path('admin/', admin.site.urls),
]
בשורה זו אנו מציינים לשרת, שכאשר הוא מקבל פנייה מהרשת והכתובת שנותבה אליו הגיעה לכתובת app (ואולי גם איזשהו המשך, כמו app/something), אז שינסה להתאים את ההמשך של הכתובת לכל מה שמופיע ב-urlpatterns שבבקובץ my_app.urls.
שוב – נזכור לא להתבלבל בין תיקיית הגדרות הפרוייקט, המכילה קובץ בשם urls.py לבין תיקיית האפליקצייה, שגם בה יצרנו קובץ עם שם זהה.
כעת נרצה “להרים” את השרת מחדש עם האפליקציה.
בטרמינל נריץ את הפקודה שאנו כבר מכירים:
python manage.py runserver
ואם כעת נלך לדפדפן, ונכנס לכתובת:
http://127.0.0.1:8000/app/hello
נראה את הפלט hello world (שהגדרנו שיוחזר מפונקצית הניתוב index) בדף שייפתח.
מוזמנים לעשות inspect על הדף, ולראות שהדפדפן יצר באופן אוטומטי מעטפת של html, ושהקריאה עצמה התקבלה עם סטטוס-קוד (200).
אנו נוכל במקום מחרוזת hello world, לציין קוד html, והוא יוצג יפה באתר.
למשל:
def index(request):
html = "<p> Hello </p> <br> <p>world</p>"
return HttpResponse(html)
זו לא הדרך החכמה במיוחד להחזיר דף html, אבל הכרנו אותה רק כדי להבין איך הדברים עובדים.
בשיעורים הקרובים נראה איך להחזיר בצורה נוחה וקלה דפי HTML למשתמש.
ולמרות שהאובייקט HttpResponse המוחזר מפונקצית הניתוב, בדרך כלל מקבל את התוכן כמחרוזת, אפשר גם להתייחס לאובייקט זה כקובץ, ו”לכתוב” אליו ערכים, למשל:
res = HttpResponse()
res.write("<h1> some text inside html tag </h1>")
res.write("<h1> some other text inside html tag </h1>")
return res
כמו כן, האובייקט HttpResponse יודע לקבל גם איטרטורים, והוא פשוט יריץ אותם וימיר את התוצאה לטקסט.
מתוך הדוקומנטציה:
you can pass HttpResponse an iterator rather than strings. HttpResponse will consume the iterator immediately, store its content as a string, and discard it.
ולסיום אציין שהאובייקט HttpResponse מסוגל גם לקבל מילון בתור פרמטר נוסף בשם headers. זהו תוכן נוסף שיתווסף למה שהדפדפן יקבל, אבל זה לא יהיה חלק מתוכן הדף שיצג, אלא יופיע ב-headers של התשובה.
מה זה header?
ובכן, בקשה ברשת בפרוטוקול http מכילה גם חלק שנקרא header שמכיל נתונים כלליים על הבקשה. כמו איזה פורמט התוכן שלה וכדומה.
אם נבחר להוסיף header כלשהו לתשובה של הפונקציה, נוכל לבחון את התוספת הזו מתוך ה-inspect בדפדפן.
ולפני שנמשיך, אני מציע לקרוא את התיעוד שמופיע כהערה בקוד בקובץ urls.py של הפרויקט. יש שם סיכום נחמד של כל הדברים שנדרשנו לעשות.
לפני שנבצע תרגיל, אספר לכם שבעת יצירת הפרויקט, אפשר גם ליצור אותו באמצעות הפקודה הבאה:
django-admin startproject my_project
באופן כזה, הפרוייקט יווצר בתיקייה הנוכחית ללא תוספת התיקייה החיצונית הנושאת את שם הפרויקט. כך שאם הרצנו את הפקודה מתוך תיקייה בשם my_folder אז מבנה הקבצים ייראה כך:
תרגיל:
צרו כתובת ניתוב לאפליקציה שלכם, כך שכל מי שיפנה ל:
http://127.0.0.1:8000/app/my_name
יקבל כתשובה את השם שלכם.
למתקדמים: נסו שצבע הטקסט של התשובה יהיה בצבע אדום על ידי שימוש ב-html.
פתרון
נצטרך להגדיר פונקציה חדשה, למשל בשם serve_my_name באופן הבא:
def serve_my_name(request):
return HttpResponse("Ori")
לאחר מכן, נצטרך להוסיף ניתוב בקובץ url של האפליקציה תחת urlpatterns:
path("my_name", views.serve_my_name),
ואת רשימת ה-urlpatterns נצטרך כמובן לחבר ל-urls של הפרוייקט כמו שעשינו בשיעור.
אם פתרתם לבד, בטח שמתם לב תוך כדי המשחקים, שכאשר כתובת הניתוב לא נמצאה על ידי השרת, הוא מציג לדפדפן את רשימת הכתובות שהוא כן ניסה לגשת אליהם.
כדאי להבין היטב את מנגנון ההתאמה הזה!
הערה: לאחר כל שינוי שאתם מבצעים ושומרים בקוד, באופן אוטומטי השרת נטען מחדש. לא צריך לאתחל אותו ידנית.
שאלה:
מה יקרה אם בתוך כתובת הניתוב תהיה לנו שגיאה בקוד, exception?
תשובה:
לדפדפן תוחזר שגיאה עם סטטוס קוד 500 שמציין internal server error.
אנו בעיקרון נרצה לעטוף קטעי קוד “מסוכנים” ב- try-catch כך שנוכל לשלוט על התשובה שיראה המשתמש. נוכל להשתמש באובייקטים נוספים מתוך django.http כמו למשל
return HttpResponseServerError("Sorry, the server is facing some errors. please try again later")
המשתמש מצידו ייראה תגובה רגילה (במיוחד אם נעטוף אותה יפה ב-html) אבל הסטטוס קוד ישאר זהה במקרה הנוכחי – 500.
זו הזדמנות להכיר את הסטטוס-קוד המתאים לכל שגיאה. תוכלו לראות כאן סיכום יפה.
דיבאג
בשביל לדבג את הקוד שלנו, אם אנו עובדים עם pycharm נוכל להגדיר מחדש את הכפתור run שבצד שמאל למעלה:
לאחר שנלחץ על Edit Configurations, ייפתח לנו המסך הבא, בו נגדיר את סקריפט ה- manage.py להיות הקובץ שיורץ בעת לחיצה. (ראו בתמונה)
בשורה מתחתיו תחת parameters נוסיף את הפרמטר runserver.
כעת אם נלחץ על כפתור ה-run הירוק, השרת יתחיל לרוץ. יותר מזה, אם נשים breakpoint באיזושהי נקודה בקוד, ונריץ במצב דיבאג אז הקוד ייעצר כשיגיע לשם.
לפני שאתם ממשיכים:
נסו לשים נקודת עצירה תחת פונקצית ניתוב שהגדרתם, ואז לראות שאכן קריאה מהדפדפן לכתובת זו, עוצרת את הקוד בנקודה שהגדרתם.
תוך כדי למידה, לעיתים קרובות תיתקלו בבעיות שלא תבינו מאין הן נוצרות. היכולת שלנו לדבג את פונקציות הניתוב היא יכולת חשובה וקריטית לשלב הלמידה.
ניתוב מבוסס מחלקות
למדנו ליצור פונקציות ניתוב כפונקציות פשוטות.
ג’אנגו מאפשרת לנו גם ליצור “מחלקה” שתשמש לקבלת ניתוב. הפונקציות של המחלקה יהיו פונקציות בשם get/post וכדומה, וכל פונקציה באופן אוטומטי תתאים לסוג ה-method שהתקבל.
טרם דיברנו על כך, אבל בקשות ברשת בפרוטוקול http מאופיינות גם ב”סוג” (method) בקשה. סוג הבקשה יכול להיות post או get, שזה דברים שנכיר יותר לעומק בהמשך הקורס.
ובכן, מחלקה של ניתוב צריכה לרשת מ-View, והנה דוגמה למימוש:
from django.views import View
class MyViewClass(View):
def get(self, request):
return HttpResponse('hello from get')
def post(self, request):
return HttpResponse('hello from post')
הקוד הנ”ל נכון שיישב תחת קובץ ה-views של האפליקצייה, ובשביל לנתב למחלקה קריאות, תחת קובץ ה-urls נוסיף ב-urlpatterns את השורה הבאה:
path('some_path', views.MyViewClass.as_view())
נשים לב – מאחר ומדובר במחלקה, נצטרך להשתמש בפונקציה as_view (פונקציה שמומשה במחלקה view ממנה המחלקה שלנו יורשת), והיא מאחורי הקלעים יודעת ליצור את מבנה הפונקציות שירוצו בהתאם ל-method שהתקבל.
בצורה כזו, המשתמש ייגש לאותה הכתובת עם method שונה, בכל פעם תופעל פונקציה אחרת בהתאם לסוג הבקשה.
מה קורה מאחורי הקלעים? במחלקה View ישנה פונקציה בשם dispatch שמקבלת את הבקשה, ומפנה אותה לאן שנדרש לפי סוג הבקשה. (לפעמים נרצה לעשות override לפונקציה זו, בשביל לוודא שהגישה בוצעה כראוי)
לסגירת הנושא, אציין שיש לנו דרך להחזיר ניתוב חדש מתוך פונקצית הניתוב.
למשל, אם מתוך פונקצית הניתוב נחזיר את האובייקט הבא:
return HttpResponseRedirect("https://logicode.study")
אז פניה לפונקצית הניתוב הזו, “תעביר” את המשתמש לאתר לוגיקוד.
את האובייקט יש לייבא כך:
from django.http import HttpResponseRedirect
טוב, זה היה פרק ארוך וקצת מתיש, אבל אם הצלחנו להבין אותו אז כבר יש לנו הבנה בסיסית על מנגנון הניתובים של ג’אנגו.
אני מציע לכם לפני שאתם ממשיכים, לראות שאתם מצליחים לחזור שוב על כל הפעולות שעשינו – ליצור פרוייקט, ליצור אפליקציה, ולהגדיר נכון פונקצית ניתוב לכתובת כלשהי.
בשיעור הבא נלמד על היכולת של ג’אנגו להחזיר מתוך פונקציות הניתוב קבצי html בעלי תוכן נעים יותר לעומת המחרוזות שהכרנו עד כה.
