{"title":"Écriture de votre première application Django, 7ème partie","version":"6.1","locale":"fr","docname":"intro/tutorial07","url":"/fr/6.1/intro/tutorial07/","canonical":"https://djangodocs.dev/fr/6.1/intro/tutorial07/","summary":"Ce tutoriel commence là où le tutoriel 6 s’achève. Nous continuons l’application de sondage Web et allons nous focaliser sur la personnalisation du site…","html":"

Écriture de votre première application Django, 7ème partieLien vers cette rubrique#

\n

Ce tutoriel commence là où le tutoriel 6 s’achève. Nous continuons l’application de sondage Web et allons nous focaliser sur la personnalisation du site d’administration généré automatiquement par Django, que nous avons déjà exploré dans le tutoriel 2.

\n\n
\n

Personnalisation du formulaire d’administrationLien vers cette rubrique#

\n

Quand vous avez inscrit le modèle Question avec admin.site.register(Question), Django a été capable de représenter l’objet dans un formulaire par défaut. Il sera cependant souvent souhaitable de personnaliser l’affichage et le comportement du formulaire. Cela se fait en indiquant certaines options à Django lors de l’inscription de l’objet.

\n

Voyons comment cela fonctionne, en réordonnant les champs sur le formulaire d’édition. Remplacez la ligne admin.site.register(Question) par :

\n
polls/admin.py
\n
Python
from django.contrib import admin\n\nfrom .models import Question\n\n\nclass QuestionAdmin(admin.ModelAdmin):\n    fields = ["pub_date", "question_text"]\n\n\nadmin.site.register(Question, QuestionAdmin)\n
\n

Vous suivrez cette méthode – c’est-à-dire créer une classe d’administration de modèle, puis le transmettre en tant que deuxième paramètre de admin.site.register() – à chaque fois que vous aurez besoin de modifier les options d’administration pour un modèle.

\n

Cette modification fait que la « Date de publication » apparaît avant le champ « Question » :

\n\"Les\n

Ce n’est pas spécialement impressionnant avec seulement deux champs, mais pour un formulaire d’administration avec des dizaines de champs, choisir un ordre intuitif est un détail d’utilisation important.

\n

Et en parlant de formulaires avec des dizaines de champs, il peut être utile de partager le formulaire en plusieurs sous-ensembles (fieldsets) :

\n
polls/admin.py
\n
Python
from django.contrib import admin\n\nfrom .models import Question\n\n\nclass QuestionAdmin(admin.ModelAdmin):\n    fieldsets = [\n        (None, {"fields": ["question_text"]}),\n        ("Date information", {"fields": ["pub_date"]}),\n    ]\n\n\nadmin.site.register(Question, QuestionAdmin)\n
\n

Le premier élément de chaque tuple dans fieldsets est le titre du groupe de champs. Voici ce à quoi notre formulaire ressemble à présent :

\n\"Le\n
\n\n
\n

Personnalisation de la liste pour modification de l’interface d’administrationLien vers cette rubrique#

\n

Maintenant que la page d’administration des Questions présente un peu mieux, améliorons la page « liste pour modification » – celle qui affiche toutes les questions du système.

\n

Voici à quoi ça ressemble pour l’instant :

\n\"Page\n

Par défaut, Django affiche le str() de chaque objet. Mais parfois, il serait plus utile d’afficher des champs particuliers. Dans ce but, utilisez l’option list_display, qui est une liste de noms de champs à afficher, en colonnes, sur la page liste pour modification de l’objet :

\n
polls/admin.py
\n
Python
class QuestionAdmin(admin.ModelAdmin):\n    # ...\n    list_display = ["question_text", "pub_date"]\n
\n

Pour la démonstration, incluons également la méthode was_published_recently() du tutoriel 2:

\n
polls/admin.py
\n
Python
class QuestionAdmin(admin.ModelAdmin):\n    # ...\n    list_display = ["question_text", "pub_date", "was_published_recently"]\n
\n

À présent, la page liste pour modification des questions ressemble à ceci :

\n\"Page\n

Vous pouvez cliquer sur les en-têtes de colonne pour trier selon ces valeurs – sauf dans le cas de l’en-tête was_published_recently, parce que le tri selon le résultat d’une méthode arbitraire n’est pas pris en charge. Notez aussi que l’en-tête de la colonne pour was_published_recently est, par défaut, le nom de la méthode (avec les soulignements remplacés par des espaces) et que chaque ligne contient la représentation textuelle du résultat.

\n

Vous pouvez améliorer cela en appliquant le décorateur display() à cette méthode (en étendant le fichier polls/models.py créé lors du tutoriel 2), comme ceci :

\n
polls/models.py
\n
Python
from django.contrib import admin\n\n\nclass Question(models.Model):\n    # ...\n    @admin.display(\n        boolean=True,\n        ordering="pub_date",\n        description="Published recently?",\n    )\n    def was_published_recently(self):\n        now = timezone.now()\n        return now - datetime.timedelta(days=1) <= self.pub_date <= now\n
\n

Pour plus d’informations sur les propriétés configurables par ce décorateur, consultez list_display.

\n

Modifiez encore une fois le fichier polls/admin.py et améliorez la page de liste pour modification des Questions: ajout de filtrage à l’aide de l’attribut list_filter. Ajoutez la ligne suivante à QuestionAdmin:

\n
Code
list_filter = ["pub_date"]\n
\n

Cela ajoute une barre latérale « Filter » qui permet de filtrer la liste pour modification selon le champ pub_date :

\n\"Page\n

Le type de filtre affiché dépend du type de champ à filtrer. Comme pub_date est un champ DateTimeField, Django sait fournir des options de filtrage appropriées : « Toutes les dates », « Aujourd’hui », « Les 7 derniers jours », « Ce mois-ci », « Cette année ».

\n

Ça a meilleure forme. Ajoutons une fonctionnalité de recherche :

\n
Code
search_fields = ["question_text"]\n
\n

Cela ajoute une boîte de recherche en haut de la liste pour modification. Quand quelqu’un saisit des termes de recherche, Django va rechercher dans le champ question_text. Vous pouvez indiquer autant de champs que vous le désirez – néanmoins, en raison de l’emploi d’une requête LIKE en arrière-plan, il s’agit de rester raisonnable quant au nombre de champs de recherche, sinon la base de données risque de tirer la langue !

\n

Now’s also a good time to note that change lists give you free pagination. The\ndefault is to display 100 items per page.

\n\n
\n
\n

Personnalisation de l’apparence de l’interface d’administrationLien vers cette rubrique#

\n

Clairement, avoir « Django administration » en haut de chaque page d’administration est ridicule. C’est juste du texte de substitution.

\n

Toutefois, vous pouvez le changer en utilisant le système de gabarits de Django. Le site d’administration de Django est écrit lui-même avec Django, et ses interfaces utilisent le système de gabarits propre à Django.

\n
\n

Personnalisation des gabarits de votre projetLien vers cette rubrique#

\n

Créez un répertoire s’appelant templates dans le répertoire djangotutorial. Les gabarits peuvent se trouver à n’importe quel endroit du système de fichiers, pourvu qu’ils soient accessibles par Django (Django utilise le même utilisateur que celui qui a démarré votre serveur). Cependant, par convention, il est recommandé de conserver les gabarits à l’intérieur du projet.

\n

Ouvrez votre fichier de configuration (mysite/settings.py, souvenez-vous) et ajoutez une option DIRS dans le réglage TEMPLATES:

\n
mysite/settings.py
\n
Python
TEMPLATES = [\n    {\n        "BACKEND": "django.template.backends.django.DjangoTemplates",\n        "DIRS": [BASE_DIR / "templates"],\n        "APP_DIRS": True,\n        "OPTIONS": {\n            "context_processors": [\n                "django.template.context_processors.request",\n                "django.contrib.auth.context_processors.auth",\n                "django.contrib.messages.context_processors.messages",\n            ],\n        },\n    },\n]\n
\n

DIRS est une liste de répertoires du système de fichiers que Django parcourt lorsqu’il doit charger les gabarits ; il s’agit d’un chemin de recherche.

\n\n

Créez maintenant dans templates un répertoire nommé admin et copiez-y le gabarit admin/base_site.html à partir du répertoire par défaut des gabarits d’administration dans le code source de Django (django/contrib/admin/templates).

\n\n

Ensuite, éditez le fichier et remplacez {{ site_header|default:_('Django administration') }} (y compris les accolades) par le nom de votre propre site. Cela devrait donner quelque chose comme :

\n
Django template
{% block branding %}\n<div id="site-name"><a href="{% url 'admin:index' %}">Polls Administration</a></div>\n{% if user.is_anonymous %}\n  {% include "admin/color_theme_toggle.html" %}\n{% endif %}\n{% endblock %}\n
\n

Nous utilisons cette approche pour vous apprendre comment surcharger des gabarits. Dans un projet réel, vous auriez probablement utilisé l’attribut django.contrib.admin.AdminSite.site_header pour faire cette même modification de manière plus simple.

\n

Ce fichier gabarit contient beaucoup de texte comme {% block branding %} et {{ title }}. Les balises {% et {{ font partie du langage de gabarit de Django. Lorsque Django génère admin/base_site.html, le langage de gabarit est évalué afin de produire la page HTML finale, tout comme nous l’avons vu dans le 3ème tutoriel.

\n

Notez que tous les gabarits de l’interface d’administration par défaut de Django peuvent être remplacés. Pour remplacer un gabarit, faites la même chose qu’avec base_site.html, copiez-le depuis le répertoire par défaut dans votre répertoire personnalisé, et faites les modifications nécessaires.

\n
\n
\n

Personnalisation des gabarits de votre applicationLien vers cette rubrique#

\n

Les lecteurs avisés demanderont : mais si DIRS était vide par défaut, comment Django trouvait-il les gabarits par défaut de l’interface d’administration ? La réponse est que dans la mesure où APP_DIRS est défini à True, Django regarde automatiquement dans un éventuel sous-répertoire templates/ à l’intérieur de chaque paquet d’application, pour l’utiliser en dernier recours (n’oubliez pas que django.contrib.admin est aussi une application).

\n

Notre application de sondage n’est pas très compliquée et ne nécessite pas de gabarits d’administration personnalisés. Mais si elle devenait plus sophistiquée et qu’il faille modifier les gabarits standards de l’administration de Django pour certaines fonctionnalités, il serait plus logique de modifier les gabarits de l”application, et non pas ceux du projet. De cette façon, vous pourriez inclure l’application « polls » dans tout nouveau projet en étant certain que Django trouve les gabarits personnalisés nécessaires.

\n

Lisez la documentation sur le chargement de gabarits pour des informations complètes sur la manière dont Django trouve ses gabarits.

\n
\n
\n
\n

Personnalisation de la page d’accueil de l’interface d’administrationLien vers cette rubrique#

\n

De la même manière, il peut être souhaitable de personnaliser l’apparence de la page d’index de l’interface d’administration de Django.

\n

Par défaut, il affiche toutes les applications de INSTALLED_APPS qui ont été inscrites dans l’application admin, par ordre alphabétique. Il est possible de faire des modifications significatives sur la mise en page. Après tout, la page d’index est probablement la page la plus importante du site d’administration, donc autant qu’elle soit facile à utiliser.

\n

Le gabarit à personnaliser est admin/index.html (faites la même chose qu’avec admin/base_site.html dans la précédente section – copiez-le depuis le répertoire par défaut vers votre répertoire de gabarits personnel). Éditez le fichier, et vous verrez qu’il utilise une variable de gabarit appelée app_list. Cette variable contient toutes les applications Django installées et inscrites. À la place, vous pouvez écrire en dur les liens vers les pages d’administration spécifiques aux objets de la manière qui vous convient.

\n

Lorsque vous vous serez familiarisé avec le site d’administration, lisez la partie 8 de ce tutoriel pour apprendre comment intégrer des paquets tiers.

\n
","rootId":"writing-your-first-django-app-part-7","toc":[{"title":"Personnalisation du formulaire d’administration","anchor":"customize-the-admin-form","children":[]},{"title":"Ajout d’objets liés","anchor":"adding-related-objects","children":[]},{"title":"Personnalisation de la liste pour modification de l’interface d’administration","anchor":"customize-the-admin-change-list","children":[]},{"title":"Personnalisation de l’apparence de l’interface d’administration","anchor":"customize-the-admin-look-and-feel","children":[{"title":"Personnalisation des gabarits de votre projet","anchor":"customizing-your-project-s-templates","children":[]},{"title":"Personnalisation des gabarits de votre application","anchor":"customizing-your-application-s-templates","children":[]}]},{"title":"Personnalisation de la page d’accueil de l’interface d’administration","anchor":"customize-the-admin-index-page","children":[]}],"breadcrumbs":[{"docname":"intro/index","title":"Premiers pas","url":"/fr/6.1/intro/"}],"prev":{"docname":"intro/tutorial06","title":"Écriture de votre première application Django, 6ème partie","url":"/fr/6.1/intro/tutorial06/"},"next":{"docname":"intro/tutorial08","title":"Écriture de votre première application Django, 8ème partie","url":"/fr/6.1/intro/tutorial08/"},"formats":{"html":"/fr/6.1/intro/tutorial07/","markdown":"/fr/6.1/intro/tutorial07.md","json":"/fr/6.1/intro/tutorial07.json"},"source":"https://github.com/django/django/blob/stable/6.1.x/docs/intro/tutorial07.txt","official":"https://docs.djangoproject.com/fr/6.1/intro/tutorial07/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11","1.10","1.9"],"inLocales":["en","sv","zh-hans","ga","fr","ja","id","it","pt-br","ko","es","el","pl"]}