DJ #5: view e mapping delle URL

All’interno della directory ‘blog’, che contiene il codice dell’omonima applicazione, si trovano, tra gli altri, i due file:

  • views.py
  • urls.py

Il primo conterrà le funzioni che implementano le view di cui l’applicazione farà uso, mentre il secondo contiene le regole per mappare tali view su delle URL specifiche.

Modifico il file views.py, importando la funzione HttpResponse e aggiungendo due semplici funzioni:

from django.shortcuts import render
from django.http import HttpResponse


def home(request):
    return HttpResponse('<h1>Blog Home</h1>')


def about(request):
    return HttpResponse('<h1>Blog About</h1>')

Le funzioni sono abbastanza autoesplicative: prendono in input una richiesta e restituiscono una risposta che consiste in una stringa che rappresenta una pagina html.

Ora modifico il file urls.py (quello nella directory blog) in modo tale da mappare due URL distinte sulle due funzioni:

from django.urls import path
from . import views


urlpatterns = [
    path('', views.home, name='blog-home'),
    path('about/', views.about, name='blog-about'),
]

In questo file ho definito la lista urlpatterns che contiene due path: uno vuoto, che rimanda alla funzione views.home, e l’altro che intercetta il pattern about che invece rimanda alla funzione views.about.

Tuttavia, il mapping siffatto non ha ancora alcun effetto. Affinché abbia qualche effetto, si deve intervenire anche sul file urls.py all’interno della directory del progetto (journey) che è quello che viene preso in considerazione dal sistema di routing di Django. Questo è il contenuto di quel file opportunamente modificato:

from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('blog/', include('blog.urls'))
]

La prima riga importa il modulo admin da django.contrib, e si tratta di una applicazione che fornisce il sistema di amministrazione del progetto. Per il momento è ininfluente. Successivamente si importano le funzioni path (inclusa anche in blog/urls.py) e include dal pacchetto django.urls.

Anche in questo file è definita una lista urlpatterns che serve a mappare le diverse URL, ma invece di mapparle direttamente a delle view le mappa su altri file che definiscono a loro volta delle regole di mapping. In particolare si dice che tutte le URL che iniziano con il pattern blog/ sono soggette alle regole definite nel file urls del modulo (applicazione) ‘blog’.

Sintetizzando, se si avvia il server di test (./manage.py runserver) e si visita la URL http://localhost:8000/blog/ allora viene invocata la funzione views.home dell’applicazione blog, mentre se si visita la URL http://localhost:8000/blog/about/ viene invocata la funzione views.about sempre dell’applicazione blog.

Se si volesse rendere l’applicazione blog quella di default, ovvero quella mostrata quando si visita http://localhost:8000, allora sarebbe sufficiente modificare il file urls.py principale in questo modo:

from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', include('blog.urls'))
]

La cosa importante da notare è che, una volta fatto il matching della URL con i pattern specificati nel file urls.py principale, nei file delle singole applicazioni si andrà a cercare il match della URL depurato della parte già matchata. (mi scuso, ma non mi viene un termine italiano che renda l’idea di matching)

Nei post successivi mostrerò la definizione dei dati che si andranno a rappresentare nel Model dell’applicazione blog e come integrare l’applicazione nel progetto principale. Più avanti tornerò anche in maniera un po’ più dettagliata sulla gestione delle URL.

Ciao 🙂