fetch old django content

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.
 

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. 

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.
 

source/part-3-django-concepts/00-main.adoc

@@ -6,4 +6,8 @@ include::models.adoc[]
 
 include::admin.adoc[]
 
-include::forms.adoc[]
+include::forms.adoc[]
+
+include::mvc.adoc[]
+
+include::urls.adoc[]

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 <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. 
+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 ?

source/part-3-django-concepts/urls.adoc

@@ -0,0 +1 @@
+=== URLs