Questo tutorial inizia dove si è interrotto il Tutorial 2 . Stiamo proseguendo con l’applicazione dei questionari online e ci focalizzeremo nella creazione dell’interfaccia pubblica – «views.»
\n\nUna view è un «tipo» di pagina web nella tua applicazione Django, che generalmente serve una specifica funzione ed ha un template specifico. Per esempio, in una applicazione blog, potresti avere le seguenti views:
\nHome page del blog – mostra le ultime voci.
Pagina di «dettaglio» della voce – pagina permanente per una singola voce.
Pagina di archivio in base all’anno – visualizza tutti i mesi con le voci nell’anno specificato.
L’archivio mensile – mostra tutti i giorni con le relative pubblicazioni in un dato mese.
L’archivio giornaliero – mostra tutte le pubblicazioni in un determinato giorno.
L’azione per i commenti – gestisce la possibilità di commentare una determinata pubblicazione.
Nella nostra applicazione di sondaggi, avremo le seguenti quattro visualizzazioni:
\nL” «indice» delle domande – mostra una selezione delle ultime domande.
La pagina «dettagli» della domanda – mostra il testo della domanda, senza risultati ma con un form per votare.
La pagina «risultati» delle domande – mostra i risultati per una determinata domanda.
L’azione del voto – gestisce il voto per una scelta particolare in una azione particolare.
In Django, le pagine web e gli altri contenuti sono serviti dalle views. Ogni view è rappresentata da una funzione Python (o un metodo, in caso di views basate su classi). Django sceglierà una view esaminando la URL che viene richiesta (per essere precisi, la parte di URL dopo il nome di dominio).
\nAdesso, nel tempo che hai trascorso sul web potresti essere incappato in amenità come ME2/Sites/dirmod.htm?sid=&type=gen&mod=Core+Pages&gid=A6CD4967199A42D9B65B1B. Sarai felice di sapere che Django ci permette di utilizzare pattern per le URL che sono molto più eleganti di quelli.
Un pattern URL è la forma generale di una URL - per esempio: /newsarchive/<year>/<month>/.
Per prendere una URL da una view, Django usa quelle che sono chiamate “URLconfs”. Una URLconf mappa i pattern delle URL sulle view.
\nQuesto tutorial fornisce istruzioni di base per l’uso di URLconfs e puoi fare riferimento a URL dispatcher per maggiori informazioni.
\nAdesso aggiungiamo poche altre view a polls/views.py. Queste view sono leggermente differenti, perchè prendono un argomento:
polls/views.pydef detail(request, question_id):\n return HttpResponse("You're looking at question %s." % question_id)\n\n\ndef results(request, question_id):\n response = "You're looking at the results of question %s."\n return HttpResponse(response % question_id)\n\n\ndef vote(request, question_id):\n return HttpResponse("You're voting on question %s." % question_id)\nCollega queste nuove view nel modulo polls.urls aggiungendo le seguenti chiamate path():
polls/urls.pyfrom django.urls import path\n\nfrom . import views\n\nurlpatterns = [\n # ex: /polls/\n path("", views.index, name="index"),\n # ex: /polls/5/\n path("<int:question_id>/", views.detail, name="detail"),\n # ex: /polls/5/results/\n path("<int:question_id>/results/", views.results, name="results"),\n # ex: /polls/5/vote/\n path("<int:question_id>/vote/", views.vote, name="vote"),\n]\nTake a look in your browser, at «/polls/34/». It’ll run the detail()\nfunction and display whatever ID you provide in the URL. Try\n«/polls/34/results/» and «/polls/34/vote/» too – these will display the\nplaceholder results and voting pages.
When somebody requests a page from your website – say, «/polls/34/», Django\nwill load the mysite.urls Python module because it’s pointed to by the\nROOT_URLCONF setting. It finds the variable named urlpatterns\nand traverses the patterns in order. After finding the match at 'polls/',\nit strips off the matching text ("polls/") and sends the remaining text –\n"34/" – to the “polls.urls” URLconf for further processing. There it\nmatches '<int:question_id>/', resulting in a call to the detail() view\nlike so:
detail(request=<HttpRequest object>, question_id=34)\nLa parte question_id=34 viene da <int:question_id>. L’utilizzo delle parentesi angolari «cattura» parte della URL e la invia come argomento keyword alla funzione della view. La parte question_id della stringa definisce un nome che sarà utilizzato per identificare il pattern individuato, e la parte int è un elemento di conversione che determina quali pattern dovrebbero essere individuati da questa parte del percorso URL. I due punti (:) separano il convertitore dal nome del pattern.
Ogni view è responsabile di fare una delle due cose: restituire un oggetto HttpResponse con il contenuto della pagina richiesta oppure sollevare una eccezione come Http404. Il resto spetta a te.
La tua view può leggere dati dal database oppure no. Può usare un sistema di template come quello di Django – o un sistema di template per Python di terze parti – o no. Può generare un file PDF, un XML in output, creare un file ZIP sul momento, usare qualsiasi libreria Python tu voglia.
\nTutto quel che Django vuole è quella HttpResponse. Oppure un’eccezione.
Dal momento che conviene, usiamo l’API database di Django, che abbiamo visto nella guida 2. Ecco una prova per la nuova view index(), che mostra le ultime 5 domande dei sondaggi nel sistema, separati dalla virgola, secondo la data di pubblicazione:
polls/views.pyfrom django.http import HttpResponse\n\nfrom .models import Question\n\n\ndef index(request):\n latest_question_list = Question.objects.order_by("-pub_date")[:5]\n output = ", ".join([q.question_text for q in latest_question_list])\n return HttpResponse(output)\n\n\n# Leave the rest of the views (detail, results, vote) unchanged\nEppure c’è un problema qui: il design della pagina è codificato nella view. Se vuoi cambiare il modo in cui la pagina appare, dovrai modificare questo codice Python. Usiamo il sistema di template di Django per separare il design da Python creando un template che la view possa usare.
\nPer prima cosa, crea una directory chiamata templates nella tua directory polls. Django cercherà i templates lì dentro.
L’impostazione TEMPLATES del tuo progetto descrive come Django caricherà e mostrerà i template. Il file di impostazioni di default configura un backend DjangoTemplates` la cui opzione APP_DIRS è impostata a True. Per convenzione DjangoTemplates cerca una sottocartella «templates» in ognuna delle INSTALLED_APPS.
Nella directory templates che hai appena creato, crea un’altra directory chiamata polls, e in quella crea un file chiamato index.html. In altre parole, il tuo template dovrebbe trovarsi in polls/templates/polls/index.html. Siccome il caricamento dei template delle app_directories lavora come spiegato poco fa, puoi fare riferimento a questo template in Django come polls/index.html.
Inserisci il seguente codice nel template:
\npolls/templates/polls/index.html{% if latest_question_list %}\n <ul>\n {% for question in latest_question_list %}\n <li><a href="/polls/{{ question.id }}/">{{ question.question_text }}</a></li>\n {% endfor %}\n </ul>\n{% else %}\n <p>No polls are available.</p>\n{% endif %}\nOra aggiorniamo la nostra vista index in polls/views.py per utilizzare il modello:
polls/views.pyfrom django.http import HttpResponse\nfrom django.template import loader\n\nfrom .models import Question\n\n\ndef index(request):\n latest_question_list = Question.objects.order_by("-pub_date")[:5]\n template = loader.get_template("polls/index.html")\n context = {\n "latest_question_list": latest_question_list,\n }\n return HttpResponse(template.render(context, request))\nIl codice carica il template chiamato polls/index.html e gli passa un context. Il context è un dizionario che associa i nomi delle variabili nel template agli oggetti Python.
Carica la pagina puntando il browser su «/polls/», e dovresti vedere una lista puntata che contiene la domanda «Come va» dal Tutorial 2. Il link punta alla pagina di dettaglio della domanda.
\nrender()Link to this heading#E” un idioma molto comune per caricare un template, quello di riempire un context e restituire un oggetto HttpResponse con il risultato del template mostrato. Django fornisce una scorciatoia. Ecco la view index() completa, riscritta:
polls/views.pyfrom django.shortcuts import render\n\nfrom .models import Question\n\n\ndef index(request):\n latest_question_list = Question.objects.order_by("-pub_date")[:5]\n context = {"latest_question_list": latest_question_list}\n return render(request, "polls/index.html", context)\nNota che una volta che abbiamo fatto questo in tutte le view, non abbiamo più bisogno di importare loader e HttpResponse (potresti voler tenere HttpResponse nel caso tu non abbia ancora i metodi stub per detail, results e vote).
La funzione render() prende l’oggetto request come primo argomento, un nome di template come secondo argomento ed un dizionario come terzo argomento opzionale. Restituisce un oggetto HttpResponse del template dato reso con il contesto dato.
Adesso affrontiamo la questione della view del dettaglio – la pagina che mostra il testo della domanda per un dato sondaggio. Ecco la view:
\npolls/views.pyfrom django.http import Http404\nfrom django.shortcuts import render\n\nfrom .models import Question\n\n\n# ...\ndef detail(request, question_id):\n try:\n question = Question.objects.get(pk=question_id)\n except Question.DoesNotExist:\n raise Http404("Question does not exist")\n return render(request, "polls/detail.html", {"question": question})\nIl concetto nuovo qui: La view solleva l’eccezione Http404 se non esiste un sondaggio con l’ID richiesto.
Discuteremo cosa potresti mettere in quel template polls/detail.html un po” più tardi, ma se ti piacerebbe avere l’esempio di cui sopra funzionale in un tempo rapido, un file che contiene solo:
polls/templates/polls/detail.html{{ question }}\nti farà iniziare per ora.
\nget_object_or_404()Link to this heading#E” un idioma molto comune usare get() e sollevare Http404 se l’oggetto non esiste. Django offre una scorciatoia. Ecco la view detail(), riscritta:
polls/views.pyfrom django.shortcuts import get_object_or_404, render\n\nfrom .models import Question\n\n\n# ...\ndef detail(request, question_id):\n question = get_object_or_404(Question, pk=question_id)\n return render(request, "polls/detail.html", {"question": question})\nLa funzione get_object_or_404() prende un modello Django come primo argomento e un numero arbitrario di argomenti keyword, che passa alla funzione get() del manager del modello. Solleva Http404 se l’oggetto non esiste.
Esiste anche un funzione get_list_or_404() , che funziona esattamente come get_object_or_404() – ad eccezione di usare filter() invece di get(). Solleva Http404 se la lista è vuota.
Torniamo alla view detail() della nostra applicazione dei sondaggi. Data la variabile di contesto question`, ecco come potrebbe apparire il template polls/detail.html:
polls/templates/polls/detail.html<h1>{{ question.question_text }}</h1>\n<ul>\n{% for choice in question.choice_set.all %}\n <li>{{ choice.choice_text }}</li>\n{% endfor %}\n</ul>\nIl sistema di template usa una sintassi «a ricerca con il punto» per accedere alle variabili attributo. Nell’esempio di {{ question.question_text }}, prima Django effettua una ricerca a dizionario sull’oggetto question. Fallendo quella, prova una ricerca dell’attributo – che funziona, in questo caso. Se la ricerca dell’attributo avesse fallito, avrebbe provato con una ricerca sugli indici della lista.
La chiamata a metodo avviene nel {% for %} loop: question.choice_set.all viene interpretato come il codice Python question.choice_set.all(), che restituisce un iterable di oggetti Choice ed è adatto ad essere usato nel tag {% for %}.
Vedi la template guide per maggiori informazioni sui templates.
\nRicorda, quando abbiamo scritto il link ad una domanda nel template polls/index.html, il link era parzialmente hardcodato come:
<li><a href="/polls/{{ question.id }}/">{{ question.question_text }}</a></li>\nThe problem with this hardcoded, tightly-coupled approach is that it becomes\nchallenging to change URLs on projects with a lot of templates. However, since\nyou defined the name argument in the path() functions in\nthe polls.urls module, you can remove a reliance on specific URL paths\ndefined in your url configurations by using the {% url %} template tag:
<li><a href="{% url 'detail' question.id %}">{{ question.question_text }}</a></li>\nIl modo in cui funziona è ricercando la definizione della URL così come è definita nel modulo polls.urls. Puoi vedere esattamente dove il nome della URL di “detail” è definita qui sotto:
...\n# the 'name' value as called by the {% url %} template tag\npath("<int:question_id>/", views.detail, name="detail"),\n...\nSe vuoi cambiare la URL della vista di dettaglio del sondaggio a qualcos’altro, magari a qualcosa come polls/specifics/12/ invece di farlo nel template (o nei template) lo cambieresti in polls/urls.py:
...\n# added the word 'specifics'\npath("specifics/<int:question_id>/", views.detail, name="detail"),\n...\nIl progetto del tutorial ha solo una app, polls. Nei veri progetti Django, ci possono essere cinque, dieci, venti app o anche più. Come fa Django a differenziare i nomi delle URL tra di esse? Per esempio, l’app polls ha una view detail, e così potrebbe averla una app sullo stesso progetto che serve per un blog. Come si a fare in modo che Django sappia quale view di quale app creare da un url quando si usa il tag di template {% url %}?
La risposta è di aggiungere namespaces al tuo URLconf. Nel file polls/urls.py, procedi ed inserisci un app_name per impostare il namespace della applicazione.
polls/urls.pyfrom django.urls import path\n\nfrom . import views\n\napp_name = "polls"\nurlpatterns = [\n path("", views.index, name="index"),\n path("<int:question_id>/", views.detail, name="detail"),\n path("<int:question_id>/results/", views.results, name="results"),\n path("<int:question_id>/vote/", views.vote, name="vote"),\n]\nAdesso cambia il tuo template polls/index.html da:
polls/templates/polls/index.html<li><a href="{% url 'detail' question.id %}">{{ question.question_text }}</a></li>\nper puntare al namespace detail della vista:
\npolls/templates/polls/index.html<li><a href="{% url 'polls:detail' question.id %}">{{ question.question_text }}</a></li>\nQuando ti senti a tuo agio a scrivere le view, leggi la parte 4 di questo tutorial per imparare le basi del processamento dei form e le view generiche.
\n