Ce tutoriel commence là où le tutoriel 2 s’achève. Nous continuons l’application de sondage Web et allons nous focaliser sur la création de l’interface publique – les « vues ».
\nUne vue est un « type » de page Web dans votre application Django qui sert généralement à une fonction précise et possède un gabarit spécifique. Par exemple, dans une application de blog, vous pouvez avoir les vues suivantes :
\nLa page d’accueil du blog – affiche quelques-uns des derniers billets.
La page de « détail » d’un billet – lien permanent vers un seul billet.
La page d’archives pour une année – affiche tous les mois contenant des billets pour une année donnée.
La page d’archives pour un mois – affiche tous les jours contenant des billets pour un mois donné.
La page d’archives pour un jour – affiche tous les billets pour un jour donné.
Action de commentaire – gère l’écriture de commentaires sur un billet donné.
Dans notre application de sondage, nous aurons les quatre vues suivantes :
\nLa page de sommaire des questions – affiche quelques-unes des dernières questions.
La page de détail d’une question – affiche le texte d’une question, sans les résultats mais avec un formulaire pour voter.
La page des résultats d’une question – affiche les résultats d’une question particulière.
Action de vote – gère le vote pour un choix particulier dans une question précise.
Dans Django, les pages Web et les autres contenus sont générés par des vues. Chaque vue est représentée par une simple fonction Python (ou une méthode dans le cas des vues basées sur des classes). Django choisit une vue en examinant l’URL demandée (pour être précis, la partie de l’URL après le nom de domaine).
\nDans votre expérience sur le Web, vous avez certainement rencontré des perles comme par exemple « ME2/Sites/dirmod.asp?sid=&type=gen&mod=Core+Pages&gid=A6CD4967199A42D9B65B1B ». Vous serez certainement rassuré en sachant que Django permet des styles d’URL bien plus élégants que cela.
\nUn modèle d’URL est simplement la forme générale d’une URL ; par exemple : /archive/<année>/<mois>/.
Pour passer de l’URL à la vue, Django utilise ce qu’on appelle des « URLconf ». Un URLconf associe des modèles d’URL (définis par des expressions régulières) à des vues.
\nCe tutoriel fournit des instructions de base sur l’utilisation des URLconf, et vous pouvez consultez django.core.urlresolvers pour plus de détails.
Ajoutons maintenant quelques vues supplémentaires dans polls/views.py. Ces vues sont légèrement différentes, car elles acceptent un paramètre :
polls/views.pydef detail(request, question_id):\n return HttpResponse("You're looking at question %s." % question_id)\n\ndef results(request, question_id):\n response = "You're looking at the results of question %s."\n return HttpResponse(response % question_id)\n\ndef vote(request, question_id):\n return HttpResponse("You're voting on question %s." % question_id)\nLiez ces nouvelles vues avec leurs URL dans le module polls.urls en ajoutant les appels url() suivants :
polls/urls.pyfrom django.conf.urls import url\n\nfrom . import views\n\nurlpatterns = [\n # ex: /polls/\n url(r'^$', views.index, name='index'),\n # ex: /polls/5/\n url(r'^(?P<question_id>[0-9]+)/$', views.detail, name='detail'),\n # ex: /polls/5/results/\n url(r'^(?P<question_id>[0-9]+)/results/$', views.results, name='results'),\n # ex: /polls/5/vote/\n url(r'^(?P<question_id>[0-9]+)/vote/$', views.vote, name='vote'),\n]\nOuvrez votre navigateur à l’adresse « /polls/34/ ». La méthode detail() sera exécutée et affichera l’ID fourni dans l’URL. Essayez aussi « /polls/34/results/ » et « /polls/34/vote/ », elles afficheront les pages modèles de résultats et de votes.
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 regular expressions in order. After finding the match at\n'^polls/', it strips off the matching text ("polls/") and sends the\nremaining text – "34/" – to the “polls.urls” URLconf for further\nprocessing. There it matches r'^(?P<question_id>[0-9]+)/$', resulting in a\ncall to the detail() view like so:
detail(request=<HttpRequest object>, question_id='34')\nLa partie question_id='34' vient de (?P<question_id>[0-9]+). En utilisant des parenthèses autour d’un motif, cela « capture » le texte correspondant à ce motif et l’envoie en tant que paramètre à la fonction de la vue ; le terme ?P<question_id> définit le nom qui va être utilisé pour identifier le motif trouvé, et [0-9]+ est une expression régulière pour chercher une suite de chiffres (c’est-à-dire un nombre).
Comme les motifs d’URL sont des expressions régulières, il n’y a vraiment aucune limite à ce qu’ils vous permettent de faire. Et il n’y a pas besoin d’ajouter de fioritures aux URL tel que .html – sauf si vous le voulez vraiment, auquel cas vous pouvez faire quelque chose comme ça :
url(r'^polls/latest\\.html$', views.index),\nMais ne le faites pas. C’est stupide.
\nChaque vue est responsable de faire une des deux choses suivantes : retourner un objet HttpResponse contenant le contenu de la page demandée, ou lever une exception, comme par exemple Http404. Le reste, c’est votre travail.
Votre vue peut lire des entrées depuis une base de données, ou pas. Elle peut utiliser un système de gabarits comme celui de Django – ou un système de gabarits tiers – ou pas. Elle peut générer un fichier PDF, produire de l’XML, créer un fichier ZIP à la volée, tout ce que vous voulez, en utilisant les bibliothèques Python que vous voulez.
\nVoilà tout ce que veut Django : HttpResponse ou une exception.
Parce que c’est pratique, nous allons utiliser l’API de base de données de Django, que nous avons vu dans le tutoriel 2. Voici une ébauche d’une nouvelle vue index(), qui affiche les 5 derniers sondages, séparés par des virgules et classés par date de publication :
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# Leave the rest of the views (detail, results, vote) unchanged\nCependant, il y a un problème : l’allure de la page est codée en dur dans la vue. Si vous voulez changer le style de la page, vous devrez modifier votre code python. Nous allons donc utiliser le système de gabarits de Django pour séparer le style du code Python en créant un gabarit que la vue pourra utiliser.
\nTout d’abord, créez un répertoire nommé templates dans votre répertoire polls. C’est là que Django recherche les gabarits.
Le paramètre TEMPLATES de votre projet indique comment Django va charger et produire les gabarits. Le fichier de réglages par défaut configure un moteur DjangoTemplates dont l’option APP_DIRS est définie à True. Par convention, DjangoTemplates recherche un sous-répertoire « templates » dans chaque application figurant dans INSTALLED_APPS.
Dans le répertoire templates que vous venez de créer, créez un autre répertoire nommé polls` dans lequel vous placez un nouveau fichier index.html. Autrement dit, le chemin de votre gabarit doit être polls/templates/polls/index.html. Conformément au fonctionnement du chargeur de gabarit app_directories (cf. explication ci-dessus), vous pouvez désigner ce gabarit dans Django tout simplement par polls/index.html.
Insérez le code suivant dans ce gabarit :
\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 %}\nMettons maintenant à jour notre vue index dans polls/views.py pour qu’elle utilise le template :
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))\nCe code charge le gabarit appelé polls/index.html et lui fournit un contexte. Ce contexte est un dictionnaire qui fait correspondre des objets Python à des noms de variables de gabarit.
Chargez la page en appelant l’URL « /polls/ » dans votre navigateur et vous devriez voir une liste à puces contenant la question « What’s up » du tutoriel 2. Le lien pointe vers la page de détail de la question.
\nrender()Lien vers cette rubrique#Il est très courant de charger un gabarit, remplir un contexte et renvoyer un objet HttpResponse avec le résultat du gabarit\ninterprété. Django fournit un raccourci. Voici la vue index() complète, réécrite :
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)\nNotez qu’une fois que nous avons fait ceci dans toutes nos vues, nous n’avons plus à importer loader et HttpResponse (il faut conserver HttpResponse tant que les méthodes initiales pour detail, results et vote sont présentes).
La fonction render() prend comme premier paramètre l’objet requête, un nom de gabarit comme deuxième paramètre et un dictionnaire comme troisième paramètre facultatif. Elle retourne un objet HttpResponse composé par le gabarit interprété avec le contexte donné.
Attaquons-nous maintenant à la vue du détail d’une question – la page qui affiche le texte de la question pour un sondage donné. Voici la vue :
\npolls/views.pyfrom django.http import Http404\nfrom django.shortcuts import render\n\nfrom .models import Question\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})\nLe nouveau concept ici : la vue lève une exception de type Http404 si une question avec l’ID demandé n’existe pas.
Nous parlerons un peu plus tard de ce que pourriez mettre dans le gabarit polls/detail.html, mais si vous voulez avoir rapidement un exemple qui fonctionne, écrivez simplement ceci :
polls/templates/polls/detail.html{{ question }}\net vous obtiendrez un résultat élémentaire.
\nget_object_or_404()Lien vers cette rubrique#Il est très courant d’utiliser get() et de lever une exception Http404 si l’objet n’existe pas. Django fournit un raccourci. Voici la vue detail() réécrite :
polls/views.pyfrom django.shortcuts import get_object_or_404, render\n\nfrom .models import Question\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 fonction get_object_or_404() prend un modèle Django comme premier paramètre et un nombre arbitraire de paramètres mots-clés, qu’il transmet à la méthode get() du gestionnaire du modèle. Elle lève une exception Http404 si l’objet n’existe pas.
Il y a aussi une fonction get_list_or_404(), qui fonctionne comme get_object_or_404(), sauf qu’elle utilise filter() au lieu de la méthode get(). Elle lève une exception Http404 si la liste est vide.
Revenons à la vue detail() de notre application de sondage. Étant donné la variable de contexte question, voici à quoi le gabarit polls/detail.html pourrait ressembler :
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>\nLe système de gabarits utilise une syntaxe d’accès aux attributs de variables à l’aide de points. Dans cet exemple avec {{ question.question_text }}, Django commence par rechercher un dictionnaire dans l’objet question. En cas d’échec, il cherche un attribut – qui fonctionne dans ce cas. Si la recherche d’attribut n’avait pas fonctionné, Django aurait essayé une recherche d’index sur une liste.
L’appel de méthode a lieu dans la boucle {% for %} : question.choice_set.all est interprété comme le code Python question.choice_set.all(), qui renvoie un itérable d’objets Choice et qui convient pour l’utilisation de la balise {% for %}.
Voir le guide des gabarits pour plus d’informations sur les gabarits.
\nRappelez-vous, lorsque nous avons ajouté le lien vers la question dans le gabarit polls/index.html, le lien a été partiellement codé en dur comme ceci :
<li><a href="/polls/{{ question.id }}/">{{ question.question_text }}</a></li>\nLe problème de cette approche codée en dur et fortement couplée est qu’il devient fastidieux de modifier les URL dans des projets qui ont beaucoup de gabarits. Cependant, comme vous avez défini le paramètre « name » dans les fonctions url() du module polls.urls, vous pouvez supprimer la dépendance en chemins d’URL spécifiques définis dans les configurations d’URL en utilisant la balise de gabarit {% url %} :
<li><a href="{% url 'detail' question.id %}">{{ question.question_text }}</a></li>\nLe principe de ce fonctionnement est que l’URL est recherchée dans les définitions du module polls.urls. Ci-dessous, vous pouvez voir exactement où le nom d’URL de « detail » est défini :
...\n# the 'name' value as called by the {% url %} template tag\nurl(r'^(?P<question_id>[0-9]+)/$', views.detail, name='detail'),\n...\nSi vous souhaitez modifier l’URL de détail des sondages, par exemple sur le modèle polls/specifics/12/, il suffit de faire la modification dans polls/urls.py au lieu de devoir toucher au contenu du ou des gabarits :
...\n# added the word 'specifics'\nurl(r'^specifics/(?P<question_id>[0-9]+)/$', views.detail, name='detail'),\n...\nLe projet du tutoriel ne contient qu’une seule application, polls. Dans des projets Django réels, il peut y avoir cinq, dix, vingt applications ou plus. Comment Django arrive-t-il à différencier les noms d’URL entre elles ? Par exemple, l’application polls possède une vue detail et il se peut tout à fait qu’une autre application du même projet en possède aussi une. Comment peut-on indiquer à Django quelle vue d’application il doit appeler pour une URL lors de l’utilisation de la balise de gabarit {% url %} ?
La réponse est donnée par l’ajout d’espaces de noms à votre configuration d’URL. Dans le fichier polls/urls.py, ajoutez une variable app_name pour définir l’espace de nom de l’application :
polls/urls.pyfrom django.conf.urls import url\n\nfrom . import views\n\napp_name = 'polls'\nurlpatterns = [\n url(r'^$', views.index, name='index'),\n url(r'^(?P<question_id>[0-9]+)/$', views.detail, name='detail'),\n url(r'^(?P<question_id>[0-9]+)/results/$', views.results, name='results'),\n url(r'^(?P<question_id>[0-9]+)/vote/$', views.vote, name='vote'),\n]\nModifiez maintenant la partie suivante du gabarit polls/index.html` :
\npolls/templates/polls/index.html<li><a href="{% url 'detail' question.id %}">{{ question.question_text }}</a></li>\npour qu’elle pointe vers la vue « detail » à l’espace de nom correspondant :
\npolls/templates/polls/index.html<li><a href="{% url 'polls:detail' question.id %}">{{ question.question_text }}</a></li>\nLorsque vous êtes à l’aise avec l’écriture des vues, lisez la partie 4 de ce tutoriel pour apprendre la gestion de formulaires simples et les vues génériques.
\n