_/renew/** vers la fonction appelée `renew_book_librarian()` dans **views.py**, et envoyer l'`id` de `BookInstance` comme paramètre sous le nom `pk`. Le motif ne fonctionnera que si `pk` est un `uuid` correctement formaté.
> **Note :** Nous pouvons appeler comme bon nous semble la donnée d'URL "`pk`" que nous avons capturée, car nous contrôlons complètement la fonction de notre vue (nous n'utilisons pas une vue générique "détail", laquelle attendrait des paramètres avec un certain nom). Cependant, le raccourci `pk`, pour "primary key", est une convention qu'il est raisonnable d'utiliser !
### Vue
Comme nous l'avons expliqué ci-dessus dans [Les étapes de gestion d'un formulaire avec Django](#les_étapes_de_gestion_dun_formulaire_avec_django), la vue doit retourner le formulaire par défaut s'il est appelé pour la première fois, et ensuite soit le retourner à nouveau avec les messages d'erreur si les données sont invalides, soit gérer les données et rediriger vers une nouvelle page si elles sont valides. Pour effectuer ces différentes actions, la vue doit être en mesure de savoir si elle est appelée pour la première fois (et retourner le formulaire par défaut) ou pour la deuxième fois ou plus (et valider les données).
Pour les formulaires qui utilisent une requête `POST` pour envoyer une information au serveur, la manière la plus commune de procéder pour la vue est de tester le type de requête `POST` (`if request.method == 'POST':`) pour repérer des requêtes de type validation de formulaire, et `GET` (en utilisant une condition `else`) pour identifier une requête initiale de création de formulaire. Si vous voulez utiliser une requête `GET` pour envoyer vos données, alors une approche classique pour savoir si la vue est invoquée pour la première fois ou non est de lire les données du formulaire (par exemple, lire une valeur cachée dans le formulaire).
Le processus de renouvellement de livre va écrire dans notre base de données, aussi, par convention, nous utiliserons le type de requête `POST`. Le bout de code ci-dessous montre le procédé (très classique) pour cette sorte de vue basée sur des fonctions.
```python
import datetime
from django.shortcuts import render, get_object_or_404
from django.http import HttpResponseRedirect
from django.urls import reverse
from catalog.forms import RenewBookForm
def renew_book_librarian(request, pk):
book_instance = get_object_or_404(BookInstance, pk=pk)
# S'il s'agit d'une requête POST, traiter les données du formulaire.
if request.method == 'POST':
# Créer une instance de formulaire et la peupler avec des données récupérées dans la requête (liaison) :
form = RenewBookForm(request.POST)
# Vérifier que le formulaire est valide :
if form.is_valid():
# Traiter les données dans form.cleaned_data tel que requis (ici on les écrit dans le champ de modèle due_back) :
book_instance.due_back = form.cleaned_data['renewal_date']
book_instance.save()
# Rediriger vers une nouvelle URL :
return HttpResponseRedirect(reverse('all-borrowed'))
# S'il s'agit d'une requête GET (ou toute autre méthode), créer le formulaire par défaut.
else:
proposed_renewal_date = datetime.date.today() + datetime.timedelta(weeks=3)
form = RenewBookForm(initial={'renewal_date': proposed_renewal_date})
context = {
'form': form,
'book_instance': book_instance,
}
return render(request, 'catalog/book_renew_librarian.html', context)
```
Nous importons tout d'abord notre formulaire (`RenewBookForm`) et un certain nombre d'autres objets/méthodes utiles, dont nous nous servons dans le corps de la fonction de notre vue :
- [`get_object_or_404()`](https://docs.djangoproject.com/fr/3.1/topics/http/shortcuts/#get-object-or-404) : Retourne un certain objet depuis un modèle, en se basant sur sa valeur "primary key", et lève une exception `Http404` (_not found_) si l'enregistrement n'existe pas.
- [`HttpResponseRedirect`](https://docs.djangoproject.com/fr/3.1/ref/request-response/#django.http.HttpResponseRedirect) : Cette méthode crée une redirection vers une certaine URL (code de statut HTTP 302).
- [`reverse()`](https://docs.djangoproject.com/fr/3.1/ref/urlresolvers/#django.urls.reverse) : Cette méthode génère une URL à partir d'un nom trouvé dans la configuration d'URL et un ensemble d'arguments. C'est l'équivalent Python du tag `url` que nous avons utilisé dans nos templates.
- [`datetime`](https://docs.python.org/3/library/datetime.html) : Une bibliothèque Python pour manipuler des dates et des heures.
Dans la vue, nous utilisons d'abord l'argument `pk` dans la fonction `get_object_or_404()` afin d'obtenir la `BookInstance` courante (si cette instance n'existe pas, la vue se termine immédiatement et la page va afficher une erreur). Si ce n'est _pas_ une requête `POST` (cas géré par la clause `else`), alors nous créons le formulaire par défaut en lui passant une valeur `initial` pour le champ `renewal_date` (comme montré ci-dessous, c'est la date actuelle plus 3 semaines).
```python
book_instance = get_object_or_404(BookInstance, pk=pk)
# S'il s'agit d'une requête GET (ou toute autre méthode), créer le formulaire par défaut.
else:
proposed_renewal_date = datetime.date.today() + datetime.timedelta(weeks=3)
form = RenewBookForm(initial={'renewal_date': proposed_renewal_date})
context = {
'form': form,
'book_instance': book_instance,
}
return render(request, 'catalog/book_renew_librarian.html', context)
```
Après la création du formulaire, nous appelons la fonction `render()` pour créer la page HTML, en précisant le template et un contexte qui contient notre formulaire. Dans ce cas, le contexte contient aussi notre `BookInstance`, que nous allons utiliser dans le template pour fournir des informations à propos du livre que nous sommes en train de renouveler.
En revanche, s'il s'agit d'une requête `POST`, alors nous créons notre objet `form` et le peuplons avec des données récupérées dans la requête. Ce processus est appelé "_binding_" (liaison) et nous permet de valider le formulaire.
Ensuite nous vérifions que le formulaire est valide, ce qui déclenche tout le code de validation sur tous les champs — ce qui inclut à la fois le code générique vérifiant que notre champ de date est effectivement une date valide, et notre fonction `clean_renewal_date()`, spécifique à notre formulaire, pour vérifier que la date est dans le bon intervalle.
```python
book_instance = get_object_or_404(BookInstance, pk=pk)
# S'il s'agit d'une requête POST, traiter les données du formulaire.
if request.method == 'POST':
# Créer une instance de formulaire et la peupler avec des données récupérées dans la requête (liaison) :
form = RenewBookForm(request.POST)
# Vérifier que le formulaire est valide :
if form.is_valid():
# Traiter les données dans form.cleaned_data tel que requis (ici on les écrit dans le champ de modèle due_back) :
book_instance.due_back = form.cleaned_data['renewal_date']
book_instance.save()
# Rediriger vers une nouvelle URL :
return HttpResponseRedirect(reverse('all-borrowed') )
context = {
'form': form,
'book_instance': book_instance,
}
return render(request, 'catalog/book_renew_librarian.html', context)
```
Si le formulaire n'est pas valide, nous appelons à nouveau la fonction `render()`, mais cette fois les valeurs passées dans le contexte vont inclure les messages d'erreur.
Si le formulaire est valide, alors nous pouvons commencer à utiliser les données, en y accédant à travers l'attribut `form.cleaned_data` (par exemple, `data = form.cleaned_data['renewal_date']`). Ici, nous ne faisons que sauvegarder les données reçues dans la valeur `due_back` de l'objet `BookInstance` associé.
> **Attention :** Alors que vous pouvez accéder aussi aux données de formulaire directement à travers la requête (par exemple, `request.POST['renewal_date']`, ou `request.GET['renewal_date']` si vous utilisez une requête GET), ce n'est PAS recommandé. Les données nettoyées sont assainies, validées et converties en types standard Python.
L'étape finale dans la partie "gestion de formulaire" de la vue est de rediriger vers une autre page, habituellement une page "success". Dans ce cas, nous utilisons `HttpResponseRedirect` et `reverse()` pour rediriger vers la vue appelée `'all-borrowed'` (qui a été créée dans la partie "challenge" de [Django didactique section 8 : Authentification des utilisateurs et permissions](/fr/docs/Learn/Server-side/Django/Authentication#challenge_yourself). Si vous n'avez pas créé cette page, vous pouvez rediriger vers la page d'accueil à l'URL '`/`').
C'est tout ce qui est requis pour la gestion du formulaire lui-même, mais il nous faut encore restreindre l'accès à la vue aux seuls libraires connectés. Nous utilisons `@login_required` en exigeant que l'utilisateur se soit connecté, et le décorateur de fonction `@permission_required` avec notre permission existante `can_mark_returned` afin d'autoriser l'accès (les décorateurs sont traités en séquence). À noter que nous aurions dû créer un nouveau réglage de permission dans `BookInstance` ("`can_renew`"), mais nous réutilisons celui existant pour garder l'exemple plus simple.
Le résultat final de la vue est donc comme indiqué ci-dessous. Veuillez copier ceci en bas de **locallibrary/catalog/views.py**.
```python
import datetime
from django.contrib.auth.decorators import login_required, permission_required
from django.shortcuts import get_object_or_404
from django.http import HttpResponseRedirect
from django.urls import reverse
from catalog.forms import RenewBookForm
@login_required
@permission_required('catalog.can_mark_returned', raise_exception=True)
def renew_book_librarian(request, pk):
"""View function for renewing a specific BookInstance by librarian."""
book_instance = get_object_or_404(BookInstance, pk=pk)
# S'il s'agit d'une requête POST, traiter les données du formulaire.
if request.method == 'POST':
# Créer une instance de formulaire et la peupler avec des données récupérées dans la requête (liaison) :
form = RenewBookForm(request.POST)
# Vérifier que le formulaire est valide :
if form.is_valid():
# Traiter les données dans form.cleaned_data tel que requis (ici on les écrit dans le champ de modèle due_back) :
book_instance.due_back = form.cleaned_data['renewal_date']
book_instance.save()
# Rediriger vers une nouvelle URL :
return HttpResponseRedirect(reverse('all-borrowed'))
# S'il s'agit d'une requête GET (ou toute autre méthode), créer le formulaire par défaut.
else:
proposed_renewal_date = datetime.date.today() + datetime.timedelta(weeks=3)
form = RenewBookForm(initial={'renewal_date': proposed_renewal_date})
context = {
'form': form,
'book_instance': book_instance,
}
return render(request, 'catalog/book_renew_librarian.html', context)
```
### Le template
Créez le template référencé dans la vue (**/catalog/templates/catalog/book_renew_librarian.html**) et copiez-y le code suivant :
```html
{% extends "base_generic.html" %}
{% block content %}
Renew: \{{ book_instance.book.title }}
Borrower: \{{ book_instance.borrower }}
Due date: \{{ book_instance.due_back }}
{% endblock %}
```
La majeure partie de ce code devrait vous être familière si vous avez suivi les tutoriels précédents.
Nous étendons le template de base et ensuite redéfinissons le block "content". Nous sommes en mesure de référencer `\{{ book_instance }}` (et ses variables), puisqu'il a été passé dans l'objet contexte par la fonction `render()`, et nous utilisons tout cela pour lister le titre du livre, son emprunteur et la date originale de retour.
Le code du formulaire est relativement simple. Nous déclarons d'abord les balises `form`, en précisant où le formulaire doit être adressé (`action`) et la `method` utilisée pour soumettre les données (ici un "HTTP `POST`"). Si vous vous rappelez ce qui a été dit en haut de cette page (aperçu sur les [Formulaires HTML](#formulaires_html)), une `action` vide comme ici signifie que les données de formulaire seront postées à nouveau à l'URL actuelle (ce qui est le comportement que nous voulons !). À l'intérieur des balises, nous définissons le bouton `submit` sur lequel l'utilisateur peut appuyer pour envoyer les données. Le `{% csrf_token %}` ajouté juste à l'intérieur des balises `form` est un des éléments de protection utilisés par Django contre les "_cross-site forgery_" (falsification de requête inter-site).
> **Note :** Ajoutez le `{% csrf_token %}` à tout template Django que vous créez et qui utilise `POST` pour soumettre les données. Cela réduira les risques qu'un utilisateur mal intentionné pirate vos formulaires.
Tout ce qui reste est la variable de template `\{{ form }}`, que nous avons passée au template dans le dictionnaire de contexte. Peut-être sans surprise, quand il est utilisé comme indiqué, il fournit le rendu par défaut de tous les champs de formulaire, y compris leurs labels, widgets et textes d'aide. Voici le rendu :
```html
Renewal date:
Enter date between now and 4 weeks (default 3 weeks).
```
> **Note :** Ce n'est peut-être pas évident, car nous n'avons qu'un seul champ, mais, par défaut, chaque champ est défini dans sa propre ligne de tableau. Ce même rendu est fourni si vous référencez la variable de template `\{{ form.as_table }}`.
Si vous aviez entré une date invalide, vous obtiendriez en plus sur la page une liste des erreurs (voir `errorlist` ci-dessous).
```html
Renewal date:
Invalid date - renewal in past
Enter date between now and 4 weeks (default 3 weeks).
```
#### Autres façons d'utiliser la variable de template du formulaire
Si vous utilisez `\{{ form.as_table }}` comme indiqué ci-dessus, chaque champ est rendu comme une ligne de tableau. Vous pouvez également rendre chaque champ comme un élément de liste (en utilisant `\{{ form.as_ul }}`) ou comme un paragraphe (en utilisant `\{{ form.as_p }}`).
Il est également possible d'avoir un contrôle complet sur le rendu de chaque partie du formulaire, en indexant ses propriétés grâce à la notation pointée. Ainsi, par exemple, nous pouvons accéder à un certain nombre d'éléments distincts pour notre champ `renewal_date` :
- `\{{ form.renewal_date }}` : Le champ complet.
- `\{{ form.renewal_date.errors }}` : La liste des erreurs.
- `\{{ form.renewal_date.id_for_label }}` : L'`id` du label.
- `\{{ form.renewal_date.help_text }}` : Le texte d'aide du champ.
Pour plus d'exemples sur la manière de rendre manuellement des formulaires dans des templates, et boucler de manière dynamique sur les champs du template, voyez [Utiliser des formulaires > Affichage manuel des champs](https://docs.djangoproject.com/fr/3.1/topics/forms/#rendering-fields-manually) (Documentation de Django).
### Tester la page
Si vous avez accepté le "challenge" dans [Django didactique - section 8 : Authentification des utilisateurs et permissions](/fr/docs/Learn/Server-side/Django/Authentication#challenge_yourself), vous avez une liste de tous les livres empruntés dans la bibliothèque, ce qui n'est visible que pour le staff de la bibliothèque. Nous pouvons ajouter un lien vers notre page de renouvellement après chaque élément, en utilisant le code de template suivant.
```html
{% if perms.catalog.can_mark_returned %} Renew {% endif %}
```
> **Note :** Souvenez-vous que votre login de test devra avoir la permission "`catalog.can_mark_returned`" pour pouvoir accéder à la page de renouvellement de livre (utilisez peut-être votre compte superuser).
Vous pouvez aussi construire manuellement une URL de test comme ceci : `http://127.0.0.1:8000/catalog/book//renew/` (un `bookinstance_id` valide peut être obtenu en naviguant vers une page de détail de livre dans votre bibliothèque, et en copiant le champ `id`).
### À quoi cela ressemble-t-il ?
Si tout a bien marché, le formulaire par défaut ressemblera à ceci :
Le formulaire avec valeur erronée ressemblera à ceci :
La liste de tous les livres avec les liens vers le renouvellement ressemblera à ceci :
## ModelForms
Créer une classe en utilisant l'approche décrite ci-dessus est très flexible et vous autorise à créer le type de page de formulaire que vous voulez, et à l'associer à tout type de modèle(s).
Cependant, si vous avez seulement besoin d'un formulaire qui répertorie les champs d'un modèle _unique_, alors votre modèle définira déjà la plupart des informations requises dans votre formulaire : champs, labels, texte d'aide, etc. Plutôt que de créer à nouveau les définitions du modèle dans votre formulaire, il est plus facile d'utiliser la classe d'aide [ModelForm](https://docs.djangoproject.com/fr/3.1/topics/forms/modelforms/) pour créer le formulaire d'après votre modèle. Ce `ModelForm` peut dès lors être utilisé à l'intérieur de vos vues exactement de la même manière qu'un `Form` ordinaire.
Un `ModelForm` basique, contenant le même champ que notre `RenewBookForm` d'origine, est montré ci-dessous. Tout ce que vous avez à faire pour créer le formulaire, c'est ajouter `class Meta` avec le `model` (`BookInstance`) associé, et une liste des `fields` du modèle à inclure dans le formulaire.
```python
from django.forms import ModelForm
from catalog.models import BookInstance
class RenewBookModelForm(ModelForm):
class Meta:
model = BookInstance
fields = ['due_back']
```
> **Note :** Vous pouvez inclure tous les champs en utilisant `fields = '__all__'`, ou bien utiliser `exclude` (au lieu de `fields`) pour préciser les champs à ne _pas_ importer du modèle.
>
> Aucune approche n'est recommandée, car tout nouveau champ ajouté au modèle est automatiquement inclus dans le formulaire (sans considération du développeur de répercussions sécuritaires éventuelles).
> **Note :** Cela peut ne pas sembler beaucoup plus simple que d'utiliser un simple `Form`, et ça ne l'est effectivement pas dans ce cas, parce que nous n'avons qu'un seul champ. Cependant, si vous avez beaucoup de champs, cela peut réduire notablement la quantité de code !
Le reste de l'information vient des définitions de champ données par le modèle (par exemple, les labels, les widgets, le texte d'aide, les messages d'erreur). S'ils ne sont pas suffisamment satisfaisants, nous pouvons les réécrire dans notre `class Meta`, en précisant un dictionnaire contenant le champ à modifier et sa nouvelle valeur. Par exemple, dans ce formulaire, nous pourrions souhaiter, pour notre champ, un label tel que "_Renewal date_" (plutôt que celui par défaut, basé sur le nom du champ : _Due Back_), et nous voulons aussi que notre texte d'aide soit spécifique à ce cas d'utilisation. La classe `Meta` ci-dessous vous montre comment réécrire ces champs, et vous pouvez pareillement définir `widgets` et `error_messages` si les valeurs par défaut ne sont pas suffisantes.
```python
class Meta:
model = BookInstance
fields = ['due_back']
labels = {'due_back': _('New renewal date')}
help_texts = {'due_back': _('Enter a date between now and 4 weeks (default 3).')}
```
Pour ajouter une validation, vous pouvez utiliser la même approche que pour un `Form` normal : vous définissez une fonction appelée `clean_field_name()`, et vous levez des exceptions de type `ValidationError` pour les valeurs non valides. La seule différence par rapport à notre formulaire original, c'est que le champ de modèle est appelé `due_back` et non "`renewal_date`". Ce changement est nécessaire, dans la mesure où le champ correspondant dans `BookInstance` est appelé `due_back`.
```python
from django.forms import ModelForm
from catalog.models import BookInstance
class RenewBookModelForm(ModelForm):
def clean_due_back(self):
data = self.cleaned_data['due_back']
# Vérifier que la date ne se situe pas dans le passé.
if data < datetime.date.today():
raise ValidationError(_('Invalid date - renewal in past'))
# Vérifier que la date tombe dans le bon intervalle (entre maintenant et dans 4 semaines).
if data > datetime.date.today() + datetime.timedelta(weeks=4):
raise ValidationError(_('Invalid date - renewal more than 4 weeks ahead'))
# N'oubliez pas de toujours renvoyer les données nettoyées.
return data
class Meta:
model = BookInstance
fields = ['due_back']
labels = {'due_back': _('Renewal date')}
help_texts = {'due_back': _('Enter a date between now and 4 weeks (default 3).')}
```
La classe `RenewBookModelForm` ci-dessus est maintenant fonctionnellement équivalente à notre `RenewBookForm` d'origine. Vous pourriez l'importer et l'utiliser partout où vous utilisez `RenewBookForm`, du moment que vous changez aussi de `renewal_date` en `due_back` le nom de variable du formulaire correspondant, comme dans la deuxième déclaration du formulaire : `RenewBookModelForm(initial={'due_back': proposed_renewal_date}`.
## Vues génériques d'édition
L'algorithme de gestion des formulaires que nous avons utilisé ci-dessus, dans notre exemple de vue fonctionnelle, représente un processus extrêmement commun dans les vues destinées à éditer un formulaire. Django abstrait pour vous la plus grande partie de ce processus répétitif (boilerplate ) en proposant des [vues génériques d'édition](https://docs.djangoproject.com/fr/3.1/ref/class-based-views/generic-editing/) pour les vues de création, édition et suppression basées sur des modèles. Ces vues génériques non seulement assument le comportement d'une vue, mais elles créent automatiquement la classe de formulaire (un `ModelForm`) pour vous à partir du modèle.
> **Note :** En plus des vues d'édition décrites ici, il existe aussi une classe [FormView](https://docs.djangoproject.com/fr/3.1/ref/class-based-views/generic-editing/#formview), qui se tient, en termes de rapport "flexibilité"/"effort codage", à mi-chemin entre notre vue basée sur une fonction et les autres vues génériques. En utilisant `FormView`, vous avez encore besoin de créer votre `Form`, mais vous n'avez pas besoin d'implémenter tous les éléments d'une gestion standard de formulaire. À la place, vous n'avez qu'à fournir une implémentation de la fonction qui sera appelée une fois que les données envoyées sont reconnues valides.
Dans cette section, nous allons utiliser des vues génériques d'édition pour créer des pages afin de pouvoir ajouter les fonctionnalités de création, d'édition et de suppression des enregistrements de type `Author` de notre bibliothèque, fournissant efficacement une réimplémentation basique de certaines parties du site Admin (cela peut être intéressant si vous avez besoin d'offrir une fonctionnalité admin d'une manière plus flexible que ce qui peut être présenté par le site admin).
### Vues
Ouvrez le fichier vue (**locallibrary/catalog/views.py**) et ajoutez le bloc de code suivant à la fin :
```python
from django.views.generic.edit import CreateView, UpdateView, DeleteView
from django.urls import reverse_lazy
from catalog.models import Author
class AuthorCreate(CreateView):
model = Author
fields = ['first_name', 'last_name', 'date_of_birth', 'date_of_death']
initial = {'date_of_death': '11/06/2020'}
class AuthorUpdate(UpdateView):
model = Author
fields = '__all__' # Non recommandé (problème potentiel de sécurité si on ajoute d'autres champs)
class AuthorDelete(DeleteView):
model = Author
success_url = reverse_lazy('authors')
```
Comme vous pouvez le voir, pour les vues "créer", "modifier" et "supprimer", vous avez besoin de dériver respectivement des vues génériques `CreateView`, `UpdateView`, et `DeleteView`, et de définir ensuite le modèle associé.
Pour les cas "créer" et "modifier", vous devez aussi préciser les champs à afficher dans le formulaire (en utilisant la même syntaxe que pour la classe `ModelForm`). Dans ce cas, nous montrons à la fois la syntaxe pour afficher "tous" les champs, et comment vous pouvez les lister un par un. Vous pouvez aussi spécifier les valeurs initiales pour chacun des champs en utilisant un dictionnaire de paires _nom_du_champ/valeur_ (ici nous définissons arbitrairement la date de mort, uniquement dans un but de démonstration — sans doute voudrez-vous l'enlever !). Par défaut, ces vues vont rediriger en cas de succès vers une page affichant l'élément nouvellement créé ou modifié, ce qui, dans notre cas, sera la vue "détail" d'un auteur, créée dans un précédent tutoriel. Vous pouvez spécifier un autre lieu de redirection en déclarant explicitement le paramètre `success_url` (comme indiqué dans la classe `AuthorDelete`).
La classe `AuthorDelete` ne requiert pas l'affichage d'aucun champ, aussi n'ont-ils pas besoin d'être précisés. Par contre, il vous faut bien spécifier la `success_url`, car Django n'a pas de valeur par défaut pour cela. Dans ce cas, nous utilisons la fonction [`reverse_lazy()`](https://docs.djangoproject.com/fr/3.1/ref/urlresolvers/#reverse-lazy) pour rediriger vers notre liste d'auteurs après qu'un auteur a été supprimé. `reverse_lazy()` est une version de `reverse()` exécutée mollement ("_lazily_"), que nous utilisons ici parce que nous fournissons une URL à un attribut de vue basée sur une classe.
### Templates
Les vues "créer" et "modifier" utilisent le même template par défaut, lequel sera nommé d'après votre modèle : *model_name*\_**form.html** (vous pouvez changer le suffixe en autre chose que **\_form** en utilisant le champ `template_name_suffix` dans votre vue, par exemple, `template_name_suffix = '_other_suffix'`).
Créez le fichier de template **locallibrary/catalog/templates/catalog/author_form.html** et copiez-y le texte suivant.
```html
{% extends "base_generic.html" %}
{% block content %}
{% endblock %}
```
Ce formulaire est semblable à nos formulaires précédents et affiche les champs en utilisant un tableau. Notez aussi comment nous déclarons à nouveau le `{% csrf_token %}` pour nous assurer que nos formulaires résisteront à d'éventuelles attaques par CSRF (_Cross-Site Request Forgery_).
La vue "supprimer" s'attend à trouver un template avec un nom au format *model_name*\_**confirm_delete.html** (de nouveau, vous pouvez changer le suffixe en utilisant `template_name_suffix` dans votre vue). Créez le fichier de template **locallibrary/catalog/templates/catalog/author_confirm_delete.html** et copiez-y le texte suivant.
```html
{% extends "base_generic.html" %}
{% block content %}
Delete Author
Are you sure you want to delete the author: \{{ author }}?
{% endblock %}
```
### Configurations d'URL
Ouvrez votre fichier de configuration d'URL (**locallibrary/catalog/urls.py**) et ajoutez-y à la fin la configuration suivante :
```python
urlpatterns += [
path('author/create/', views.AuthorCreate.as_view(), name='author-create'),
path('author//update/', views.AuthorUpdate.as_view(), name='author-update'),
path('author//delete/', views.AuthorDelete.as_view(), name='author-delete'),
]
```
Il n'y a rien de particulièrement nouveau ici ! Vous pouvez voir que les vues sont des classes, et doivent dès lors être appelée via `.as_view()`, et vous devriez être capable de reconnaître les motifs d'URL dans chaque cas. Nous devons utiliser `pk` comme nom pour la valeur de nos clés primaires capturées, car c'est le nom de paramètre attendu par les classes de vue.
Les pages de création, modification et suppression d'auteur sont maintenant prêtes à être testées (nous ne nous mettons pas en peine pour cette fois, bien que vous puissiez le faire si vous le souhaiter, de les accrocher dans la barre latérale du site).
> **Note :** Les utilisateurs observateurs auront remarqué que nous n'avons rien fait pour empêcher les utilisateurs non autorisés d'accéder à ces pages ! Nous laissons cela comme exercice pour vous (suggestion : vous pourriez utiliser le `PermissionRequiredMixin`, et soit créer une nouvelle permission, soit réutiliser notre permission `can_mark_returned`).
### Test de la page
Tout d'abord, connectez-vous au site avec un compte ayant les permissions que vous avez définies comme nécessaires pour accéder aux pages d'édition d'auteur.
Ensuite, naviguez à la page de création d'auteur, _