Bien qu'il y ait quelques bonnes solutions fonctionnelles déjà partagées ici, je pense que le balisage non formel, comme les balises d'image auxiliaires, doit être placé dans les modèles, et non pas ajouté aux widgets de formulaire de Django ou généré dans les classes d'administration des modèles. Une solution plus sémantique est :
Remplacement du modèle d'administration
Note : Apparemment, ma réputation n'est pas assez élevée pour poster plus de deux simples liens, j'ai donc créé des annotations dans le texte suivant et inclus les URLs respectifs au bas de cette réponse.
De la Documentation sur le site d'administration de Django :
Il est relativement facile de remplacer un grand nombre des modèles que le module d'administration utilise pour générer les différentes pages d'un site d'administration. Vous pouvez même remplacer certains de ces modèles pour une application ou un modèle spécifique.
Le programme de Django django.contrib.admin.options.ModelAdmin
(généralement accessible sous l'espace de noms django.contrib.admin.ModelAdmin
) présente une série de chemins de modèles possibles pour Le chargeur de modèles de Django dans l'ordre du plus spécifique au moins spécifique. Cet extrait a été copié directement de django.contrib.admin.options.ModelAdmin.render_change_form
:
return TemplateResponse(request, form_template or [
"admin/%s/%s/change_form.html" % (app_label, opts.model_name),
"admin/%s/change_form.html" % app_label,
"admin/change_form.html"
], context)
Par conséquent, compte tenu de la documentation susmentionnée sur le remplacement des modèles d'administration de Django et des chemins de recherche des modèles, supposons que l'on ait créé une application "articles" dans laquelle est définie une classe de modèle "Article". Si l'on veut remplacer ou étendre seulement le formulaire de modification du site d'administration par défaut de Django pour le modèle articles.models.Article
il faut suivre les étapes suivantes :
- Créez une structure de répertoire modèle pour le fichier de remplacement.
- Bien que la documentation ne le mentionne pas, le chargeur de modèles cherchera d'abord dans les répertoires d'applications si
APP_DIRS
1 est réglé sur True
.
- Étant donné que l'on souhaite remplacer le modèle de site d'administration de Django par une étiquette d'application et par un modèle, la hiérarchie de répertoire résultante serait la suivante :
<project_root>/articles/templates/admin/articles/article/
- Créez le(s) fichier(s) modèle(s) dans votre nouvelle structure de répertoire.
- Seul le formulaire de modification de l'administrateur doit être modifié.
change_form.html
.
- Le chemin final, absolu, sera
<project_root>/articles/templates/admin/articles/article/change_form.html
- Remplacez complètement ou étendez simplement le modèle de formulaire de modification de l'administrateur par défaut.
- Je n'ai pas pu trouver d'informations dans la documentation de Django concernant les données contextuelles disponibles pour les modèles de sites d'administration par défaut, j'ai donc été obligé de consulter le code source de Django.
- Modèle de formulaire de modification par défaut : github.com/django/django/blob/master/django/contrib/admin/templates/admin/change_form.html
- Quelques-unes des définitions pertinentes du dictionnaire contextuel se trouvent à l'adresse suivante
django.contrib.admin.options.ModelAdmin._changeform_view
y django.contrib.admin.options.ModelAdmin.render_change_form
Ma solution
En supposant que le nom de l'attribut ImageField du modèle est "file", le remplacement du modèle pour mettre en œuvre les aperçus d'images serait similaire à ceci :
{% extends "admin/change_form.html" %}
{% block field_sets %}
{% if original %}
<div class="aligned form-row">
<div>
<label>Preview:</label>
<img
alt="image preview"
src="/{{ original.file.url }}"
style="max-height: 300px;">
</div>
</div>
{% endif %}
{% for fieldset in adminform %}
{% include "admin/includes/fieldset.html" %}
{% endfor %}
{% endblock %}
original
semble être l'instance de modèle à partir de laquelle le ModelForm a été généré. Pour l'anecdote, je n'utilise généralement pas de CSS en ligne, mais cela ne valait pas la peine de créer un fichier séparé pour une seule règle.
Sources :
- docs.djangoproject.com/fr/dev/ref/settings/#app-dirs