Remarques de situphen et artragis sur la doc

doc/source/back-end-code/arborescence-back.rst

@@ -20,7 +20,7 @@ On retrouve un dossier pour chaque module du site :
     │   └── ...
     ├── member/ # module des membres
     │   └── ...
-    ├── mp/ # module des MPs
+    ├── mp/ # module des messages privés
     │   └── ...
     ├── munin/ # module de Munin, utilisé pour le monitoring
     │   └── ...
@@ -42,7 +42,7 @@ On retrouve également dans ce dossier les quelques fichiers suivants, nécéssa
     zds/
     ├── urls.py # définition générale des URLs du site, inclus celle de chacun des modules
     ├── settings.py # paramètres du site
-    ├── settings_test.py # paramètres spécifiques à une version locale
+    ├── settings_test.py # paramètres spécifiques aux tests
     └── wsgi.py
 
 Contenu d'un module
@@ -55,10 +55,13 @@ Chacun des modules possède dans son dossier une arborescence fort semblable, et
     module/
     ├── migrations/
     │   └── ...
+    ├── api/
+    │   └── ...
     ├── tests/
     │   ├── tests.py
     │   └── ...
     ├── admin.py
+    ├── commons.py
     ├── factories.py
     ├── feeds.py
     ├── forms.py
@@ -73,8 +76,7 @@ Fichiers principaux
 
 Django étant basé sur une architecture de type Modèle-Vue-Controleur, on retrouve les modèles dans le fichier ``models.py`` et les vues associées à celles-ci dans ``views.py``. Ces dernières peuvent employer des classes formulaires qui sont définis dans ``forms.py``. Les URLs associées au module et permetant d'accéder aux vues sont définies dans ``urls.py``. On retrouve finalement des vues spécifiques associées aux fils RSS et Atom dans ``feeds.py``.
 
-Le contenu de ces fichiers est documenté dans la `documentation technique <back-end.html>`__.
-
+On retrouve également des validateurs dans le fichier ``commons.py`` (voir à ce sujet `la documentation de Django <https://docs.djangoproject.com/en/dev/ref/validators/>`__).
 
 Tests unitaires
 ---------------
@@ -104,6 +106,15 @@ Cela permetra aux autres dévellopeurs de répercuter les modifications en utili
 
     python manage.py migrate
 
+
+API
+---
+
+Une description fonctionnelle de l'API est faite `sur la page correspondante <../api.html>`__.
+
+Les fichiers correspondants à une API du module (si elle existe) se situent dans le dossier ``api/``. Dans celui-ci, principalement de nouvelles vues (``api/views.py``), URLs (``api/urls.py``) et tests (``api/tests.py``). On retrouve également des *serializers* dans ``api/serializers.py``, nécéssaires à la création de l'API (voir à ce sujet `la documentation du REST framework <http://www.django-rest-framework.org/api-guide/serializers/>`__).
+
+
 Autres
 ------
 

doc/source/back-end-code/utils.rst

@@ -36,8 +36,8 @@ Tutoriels (``tutorials.py``)
 .. automodule:: zds.utils.tutorials
     :members:
 
-Les processeurs de contexte ``context_processor.py``
-====================================================
+Les processeurs de contexte (``context_processor.py``)
+======================================================
 
 La doc de Django explique le principe des *context_processors* comme suis :
 
@@ -46,6 +46,8 @@ La doc de Django explique le principe des *context_processors* comme suis :
 | Les processeurs de contexte personnalisés peuvent se trouver n’importe où dans le code. Tout ce que Django demande, c’est que le réglage ``TEMPLATE_CONTEXT_PROCESSORS`` contienne le chemin vers le processeur personnalisé.
 |
 
+(pour plus de détails, `voir la documenation de Django à ce sujet <https://docs.djangoproject.com/en/dev/ref/templates/api/#subclassing-context-requestcontext>`__)
+
 .. automodule:: zds.utils.context_processor
     :members:
 

doc/source/front-end.rst

@@ -2,9 +2,15 @@
 Le *front-end*
 ==============
 
-Le terme *front-end* désigne la partie du code associée à l'affichage des données issues du `back-end <back-end.html>`__. Il s'agit donc de la partie du code ayant attrait au design et à l'affichage, écrite en HTML (en employant le `langage de template de Django <https://docs.djangoproject.com/en/dev/topics/templates/>`__), à l'aide de SASS pour les feuilles de style et de Javascript (au travers de Node.js).
+Le terme *front-end* désigne la partie du code associée à l'affichage des données issues du `back-end <back-end.html>`__.
 
-Le dévellopement du *front-end* requiert des outils spécifiques que vous pouvez retrouver `dans la partie dédiée à son instalation <install/frontend-install.html>`__.
+Il s'agit donc de la partie du code définissant le design et l'affichage, mais aussi de l'ergonomie, la réactivité et l'expérience utilisateur. Sa mise en place est basée sur trois langages :
+
++ Le HTML, aidé du `langage de template de Django <https://docs.djangoproject.com/en/dev/topics/templates/>`__ ;
++ `SASS <http://sass-lang.com/>`__ pour les feuilles de style ;
++ Javascript pour les interactions.
+
+`NodeJS <https://nodejs.org/>`__, son gestionnaire de packet (`npm <https://www.npmjs.com/>`__) et `Gulp <http://gulpjs.com/>`__ sont utilisés pour générer le code finale minifié et cohérent. Le développement du *front-end* requiert donc des outils spécifiques dont l'instalation `est expliquée ici <install/frontend-install.html>`__.
 
 .. toctree::
    :maxdepth: 2