diff --git a/source/images/xkcd-327.png b/source/images/xkcd-327.png new file mode 100644 index 0000000..530ddc0 Binary files /dev/null and b/source/images/xkcd-327.png differ diff --git a/source/part-1-workspace/00-main.adoc b/source/part-1-workspace/00-main.adoc index dc43bf0..a4f141b 100644 --- a/source/part-1-workspace/00-main.adoc +++ b/source/part-1-workspace/00-main.adoc @@ -6,7 +6,7 @@ Les morceaux de code seront développés pour Python3.6+ et Django 3.0+. Ils né Django fonctionne sur un link:++roulement de trois versions mineures pour une version majeure++[https://docs.djangoproject.com/en/dev/internals/release-process/], clôturé par une version LTS (_Long Term Support_). -image::http://ser-libre.com.ar/wp-content/uploads/2016/11/django.png[Support des versions Django] +image:http://ser-libre.com.ar/wp-content/uploads/2016/11/django.png[Support des versions Django] Ce sera une bonne indication à prendre en considération pour nos dépendances, puisqu'en visant une version particulière, on ne devra pratiquement pas se soucier (bon, un peu quand même...) des dépendances à installer, pour peu qu'on reste sous un certain seuil. diff --git a/source/part-1-workspace/unit_tests.adoc b/source/part-1-workspace/unit_tests.adoc index dd25e18..9c72c0a 100644 --- a/source/part-1-workspace/unit_tests.adoc +++ b/source/part-1-workspace/unit_tests.adoc @@ -53,6 +53,10 @@ Vous trouverez ci-dessous une comparaison entre des tests avec les deux framewor ---- +=== Fixtures + +https://realpython.com/django-pytest-fixtures/[Lien]: super bien expliqué, et pourquoi les fixtures dans Pytest c'est 'achement plus mieux que les tests unitaires de Django. + === Couverture de code Dans un premier temps, *le pourcentage de code couvert par nos tests*. Une fois ce pourcentage évalué, le but du jeu va consister à *ce que ce pourcentage reste stable ou augmente*. Si vous modifiez une ligne de code et que la couverture passe de 73% à 72%, vous avez perdu et vous devez faire en sorte de corriger. diff --git a/source/part-1-workspace/venvs.adoc b/source/part-1-workspace/venvs.adoc index 7e333b2..27c5ed3 100644 --- a/source/part-1-workspace/venvs.adoc +++ b/source/part-1-workspace/venvs.adoc @@ -9,7 +9,7 @@ Cette pratique est cependant fortement déconseillée pour plusieurs raisons: . Il est tout à fait envisagable que deux applications différentes soient déployées sur un même hôte, et nécessitent chacune deux versions différentes d'une même dépendance. . Pour la reproductibilité d'un environnement spécifique. Cela évite notamment les réponses type "Ca juste marche chez moi", puisque la construction d'un nouvel environnement fait partie intégrante du processus de construction et de la documentation du projet; grace à elle, on a la possibilité de construire un environnement sain et d'appliquer des dépendances identiques, quelle que soit la machine hôte. -image::https://res.cloudinary.com/teepublic/image/private/s--hOdhXtVV--/t_Preview/b_rgb:ffffff,c_limit,f_jpg,h_630,q_90,w_630/v1464028809/production/designs/521845_1.jpg +image:https://res.cloudinary.com/teepublic/image/private/s--hOdhXtVV--/t_Preview/b_rgb:ffffff,c_limit,f_jpg,h_630,q_90,w_630/v1464028809/production/designs/521845_1.jpg Depuis la version 3.5 de Python, le module `venv` est https://docs.python.org/3/library/venv.html[recommandé] afin de créer un environnement virtuel. diff --git a/source/part-3-django-concepts/00-main.adoc b/source/part-3-django-concepts/00-main.adoc index a747f20..6680629 100644 --- a/source/part-3-django-concepts/00-main.adoc +++ b/source/part-3-django-concepts/00-main.adoc @@ -6,4 +6,8 @@ include::models.adoc[] include::admin.adoc[] -include::forms.adoc[] \ No newline at end of file +include::forms.adoc[] + +include::mvc.adoc[] + +include::urls.adoc[] \ No newline at end of file diff --git a/source/django/auth.adoc b/source/part-3-django-concepts/auth.adoc similarity index 100% rename from source/django/auth.adoc rename to source/part-3-django-concepts/auth.adoc diff --git a/source/django/forms.adoc b/source/part-3-django-concepts/forms.adoc similarity index 80% rename from source/django/forms.adoc rename to source/part-3-django-concepts/forms.adoc index c2bf7cd..6404d30 100644 --- a/source/django/forms.adoc +++ b/source/part-3-django-concepts/forms.adoc @@ -2,13 +2,13 @@ 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 +image::images/xkcd-327.png[] 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. +Mauvaise idée. On peut proposer trois versions d'un même code, de la version simple (lecture du fichier csv et jonglage avec les indices de colonnes), puis une version plus sophistiquée (et plus lisible, à base de https://docs.python.org/3/library/csv.html#csv.DictReader[DictReader]), et la version +++ à base de form. 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. @@ -19,13 +19,22 @@ Le flux à suivre est le suivant: . Traitement, si la validation a réussi. -Ils jouent également plusieurs rôles: +Ils jouent également deux rôles importants: -. Validation des données, en plus de celles déjà définies au niveau du modèle -. Contrôle sur le rendu à appliquer aux champs +. Valider des données, en plus de celles déjà définies au niveau du modèle +. Contrôler le rendu à appliquer aux champs. Ils agissent come une glue entre l'utilisateur et la modélisation de vos structures de données. +=== Flux de validation + +| .Validation +| .is_valid +| .clean_fields +↓ .clean_fields_machin + +NOTE: A compléter ;-) + === 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. @@ -51,10 +60,13 @@ Le formulaire permet également de contrôler le rendu qui sera appliqué lors d [source,python] ---- -from django import forms from datetime import date + +from django import forms + from .models import Accident + class AccidentForm(forms.ModelForm): class Meta: model = Accident @@ -72,17 +84,18 @@ class AccidentForm(forms.ModelForm): '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. +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 et en passant par `widget-tweaks`. === 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 `_. 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. +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 http://django-crispy-forms.readthedocs.io/en/latest/[Django-Crispy-Forms]. 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) @@ -96,11 +109,8 @@ Pour chaque champ, crispy-forms va : http://dotmobo.github.io/django-crispy-forms.html -== Validation des données -NOTE: parler ici des méthodes `clean`. - -== En conclusion +=== En conclusion . Toute donnée entrée par l'utilisateur **doit** passer par une instance de `form`. . euh ? diff --git a/source/django/logging.adoc b/source/part-3-django-concepts/logging.adoc similarity index 100% rename from source/django/logging.adoc rename to source/part-3-django-concepts/logging.adoc diff --git a/source/django/mvc.adoc b/source/part-3-django-concepts/mvc.adoc similarity index 100% rename from source/django/mvc.adoc rename to source/part-3-django-concepts/mvc.adoc diff --git a/source/django/mvc/layout.adoc b/source/part-3-django-concepts/mvc/layout.adoc similarity index 100% rename from source/django/mvc/layout.adoc rename to source/part-3-django-concepts/mvc/layout.adoc diff --git a/source/django/mvc/my-first-wishlists.png b/source/part-3-django-concepts/mvc/my-first-wishlists.png similarity index 100% rename from source/django/mvc/my-first-wishlists.png rename to source/part-3-django-concepts/mvc/my-first-wishlists.png diff --git a/source/django/mvc/sessions.adoc b/source/part-3-django-concepts/mvc/sessions.adoc similarity index 100% rename from source/django/mvc/sessions.adoc rename to source/part-3-django-concepts/mvc/sessions.adoc diff --git a/source/django/mvc/templates.adoc b/source/part-3-django-concepts/mvc/templates.adoc similarity index 100% rename from source/django/mvc/templates.adoc rename to source/part-3-django-concepts/mvc/templates.adoc diff --git a/source/django/mvc/urls.adoc b/source/part-3-django-concepts/mvc/urls.adoc similarity index 100% rename from source/django/mvc/urls.adoc rename to source/part-3-django-concepts/mvc/urls.adoc diff --git a/source/django/mvc/views.adoc b/source/part-3-django-concepts/mvc/views.adoc similarity index 100% rename from source/django/mvc/views.adoc rename to source/part-3-django-concepts/mvc/views.adoc diff --git a/source/django/template-tag.adoc b/source/part-3-django-concepts/template-tag.adoc similarity index 100% rename from source/django/template-tag.adoc rename to source/part-3-django-concepts/template-tag.adoc diff --git a/source/part-3-django-concepts/urls.adoc b/source/part-3-django-concepts/urls.adoc new file mode 100644 index 0000000..d868d4f --- /dev/null +++ b/source/part-3-django-concepts/urls.adoc @@ -0,0 +1 @@ +=== URLs \ No newline at end of file