gwift-book/source/django/forms.adoc

Forms

Ou comment valider proprement des données entrantes.

Note	intégrer le dessin XKCD avec Little Bobby Table sur l’assainissement des données en entrée :-p

Quand on parle de forms, on ne parle pas uniquement de formulaires Web. On pourrait considérer qu’il s’agit de leur objectif principal, mais on peut également voir un peu plus loin: on peut en fait voir les forms comme le point d’entrée pour chaque donnée arrivant dans notre application: il s’agit en quelque sorte d’un ensemble de règles complémentaires à celles déjà présentes au niveau du modèle.

L’exemple le plus simple est un fichier .csv: la lecture de ce fichier pourrait se faire de manière très simple, en récupérant les valeurs de chaque colonne et en l’introduisant dans une instance du modèle.

Mauvaise idée.

Les données fournies par un utilisateur doivent toujours être validées avant introduction dans la base de données. Notre base de données étant accessible ici par l’ORM, la solution consiste à introduire une couche supplémentaire de validation.

Le flux à suivre est le suivant:

1. Création d’une instance grâce à un dictionnaire

2. Validation des données et des informations reçues

3. Traitement, si la validation a réussi.

Ils jouent également plusieurs rôles:

1. Validation des données, en plus de celles déjà définies au niveau du modèle

2. Contrôle sur le rendu à appliquer aux champs

Ils agissent come une glue entre l’utilisateur et la modélisation de vos structures de données.

Dépendance avec le modèle

Un form peut dépendre d’une autre classe Django. Pour cela, il suffit de fixer l’attribut model au niveau de la class Meta dans la définition.

from django import forms

from wish.models import Wishlist

class WishlistCreateForm(forms.ModelForm):
    class Meta:
        model = Wishlist
        fields = ('name', 'description')

De cette manière, notre form dépendra automatiquement des champs déjà déclarés dans la classe Wishlist. Cela suit le principe de DRY <don’t repeat yourself>`_, et évite qu’une modification ne pourrisse le code: en testant les deux champs présent dans l’attribut `fields, nous pourrons nous assurer de faire évoluer le formulaire en fonction du modèle sur lequel il se base.

Rendu et affichage

Le formulaire permet également de contrôler le rendu qui sera appliqué lors de la génération de la page. Si les champs dépendent du modèle sur lequel se base le formulaire, ces widgets doivent être initialisés dans l’attribut Meta. Sinon, ils peuvent l’être directement au niveau du champ.

from django import forms
from datetime import date
from .models import Accident

class AccidentForm(forms.ModelForm):
    class Meta:
        model = Accident
        fields = ('gymnast', 'educative', 'date', 'information')
        widgets = {
            'date' : forms.TextInput(
                     attrs={
                        'class' : 'form-control',
                        'data-provide' : 'datepicker',
                        'data-date-format' : 'dd/mm/yyyy',
                        'placeholder' : date.today().strftime("%d/%m/%Y")
                     }),
            'information' : forms.Textarea(
                            attrs={
                                'class' : 'form-control',
                                'placeholder' : 'Context (why, where, ...)'
                            })

Squelette par défaut

On a d’un côté le {{ form.as_p }} ou {{ form.as_table }}, mais il y a beaucoup mieux que ça ;-) Voir les templates de Vitor.

Crispy-forms

Comme on l’a vu à l’instant, les forms, en Django, c’est le bien. Cela permet de valider des données reçues en entrée et d’afficher (très) facilement des formulaires à compléter par l’utilisateur.

Par contre, c’est lourd. Dès qu’on souhaite peaufiner un peu l’affichage, contrôler parfaitement ce que l’utilisateur doit remplir, modifier les types de contrôleurs, les placer au pixel près, …​ Tout ça demande énormément de temps. Et c’est là qu’intervient `Django-Crispy-Forms <http://django-crispy-forms.readthedocs.io/en/latest/>`_. Cette librairie intègre plusieurs frameworks CSS (Bootstrap, Foundation et uni-form) et permet de contrôler entièrement le layout et la présentation.

(c/c depuis le lien ci-dessous)

Pour chaque champ, crispy-forms va :

• utiliser le verbose_name comme label.

• vérifier les paramètres blank et null pour savoir si le champ est obligatoire.

• utiliser le type de champ pour définir le type de la balise <input>.

• récupérer les valeurs du paramètre choices (si présent) pour la balise <select>.

http://dotmobo.github.io/django-crispy-forms.html

Validation des données

Note	parler ici des méthodes clean.

En conclusion

1. Toute donnée entrée par l’utilisateur doit passer par une instance de form.

2. euh ?