--- a/doc/administration.rst Mon Dec 02 17:48:02 2013 +0100
+++ b/doc/administration.rst Mon Dec 02 18:17:21 2013 +0100
@@ -2,9 +2,9 @@
Administration
**************
-Django et ses modules d'extensions propose de nombreuses commande d'administration. Le but est ici d'en lister les plus utiles pour l'administration de l'application.
-L`accès à ces commandes se fait par le script ``manage.py`` situee dans le répertoire ``src`` de l'application.
-Il est bien sur indispensable d'activer l'environement virtuel de l'application (cf. :ref:`deployment-virtualenv`) avant de lancer ce script.
+Django et ses modules d'extensions propose de nombreuses commandes d'administration. Le but est ici d'en lister les plus utiles pour l'administration de l'application.
+L`accès à ces commandes se fait par le script ``manage.py`` situé dans le répertoire ``src`` de l'application.
+Il est bien sur indispensable d'activer l'environnement virtuel de l'application (cf. :ref:`deployment-virtualenv`) avant de lancer ce script.
Le reste des commandes est documenté soit à l'adresse suivante : https://docs.djangoproject.com/en/1.5/ref/django-admin/, soit directement en invoquant la commande avec l'option ``--help`` i.e.::
cd src
@@ -21,7 +21,7 @@
python manage.py collectstatic
La première permet la mise à jour du schéma de la base de donnée et de lancer les éventuelles migration de données.
-La deuxième sert à mettre à jour les resources statiques.
+La deuxième sert à mettre à jour les ressources statiques.
Commande d'administration
@@ -62,15 +62,15 @@
-h, --help show this help message and exit
-Cette commande importe des notices en format rdf speecifique au projet dans l'application. Elle prend comme argument une liste de chemin vers les fichiers à importer.
+Cette commande importe des notices en format rdf spécifique au projet dans l'application. Elle prend comme argument une liste de chemin vers les fichiers à importer.
Les options suivantes sont disponibles:
* ``-b BATCH_SIZE`` : contrôle la taille des lots lors de l'import.
- Augmenter la taille des lots peut améliorer les performances lors de l'import mais augmente la consomation mémoire.
- (valeur par défaut: 50)
+ Augmenter la taille des lots peut améliorer les performances lors de l'import mais augmente la consommation mémoire.
+ (Valeur par défaut: 50)
* ``-p`` : ne tente pas d'effacer les notices lors de l'import.
- L'import d'une notice existante (même identifiant) proviquera une erreur et l'arrêt de l'import
+ L'import d'une notice existante (même identifiant) provoquera une erreur et l'arrêt de l'import
* ``-i`` : met à jour l'index des notices lors de l'import.
@@ -87,7 +87,7 @@
Donc en cas d'erreur d'import il est possible que certaine notice ait été indexée mais ne se retrouve pas finalement en base.
Il est à noté que dans ce cas, ces notices apparaîtrons dans la page de liste des notices.
- #. Pour des imports massif, il est souvent plus interessant de desactiver l'indexation à la volée et de lancer si c'est possible une mise à jour de l'index (cf. `update_index`_) et sinon sa reconstruction. (cf. `rebuild_index`_)
+ #. Pour des imports massif, il est souvent plus intéressant de désactiver l'indexation à la volée et de lancer si c'est possible une mise à jour de l'index (cf. `update_index`_) et sinon sa reconstruction. (cf. `rebuild_index`_)
.. _admin-dump-record:
@@ -130,15 +130,15 @@
Les options suivantes sont disponibles:
- * ``-b BATCH`` : tailles des lots de notices par requête de base de données. La valeur de ce paramêtre dépend des performances et capacité du serveur de base de données et de la machine d'export.
- * ``-l LIMIT`` : nombre maximum de notices à exporter. -1 (le défaut) exporte toute les notices.
+ * ``-b BATCH`` : tailles des lots de notices par requête de base de données. La valeur de ce paramètre dépend des performances et capacité du serveur de base de données et de la machine d'export.
+ * ``-l LIMIT`` : nombre maximum de notices à exporter. -1 (le défaut) exporte toutes les notices.
* ``-s SKIP`` : nombre de notice à ignorer avant de commencer l'export. O par défaut. Rappel: Lors de l'export les notices sont classées par leur identifiant (tri syntaxique ascendant).
Avec l'option ``-l``, cette option permet l'export des notices en lots.
* ``-j``, ``-z`` : permet la compression à la volée des données. La compression se fait au fur et à mesure de l'export.
Les points suivants sont à noter:
- #. Toute erreur interompt immédiatement l'export.
+ #. Toute erreur interrompt immédiatement l'export.
#. En cas d'erreur, l'export est immédiatement interrompu et le fichier produit ne sera pas valide.
En particulier, dans le cas où une option de compression a été activé, l'archive partielle crée peut s'avérer illisible.
@@ -189,7 +189,7 @@
--version show program's version number and exit
-h, --help show this help message and exit
-Commande utilisée pour reconstruire l'index Elasticsearch. L'age d'une notice est calculé à partir de sa date de mise à jour.
+Commande utilisée pour reconstruire l'index Elasticsearch. L’âge d'une notice est calculé à partir de sa date de mise à jour.
Cette date est la date d'import de la notice si elle n'a pas été mise à jour dans l'application, et sa date de création si elle a été créée dans l'application.
Cette commande est fournie par le module Django ``Haystack``. Sa documentation se trouve à l'adresse suivante : http://django-haystack.readthedocs.org/en/v2.1.0/management_commands.html
@@ -237,19 +237,19 @@
--version show program's version number and exit
-h, --help show this help message and exit
-Commande utilisée pour mettre à jour l'index Elasticsearch. L'age d'une notice est calculé à partir de sa date de mise à jour.
+Commande utilisée pour mettre à jour l'index Elasticsearch. L’âge d'une notice est calculé à partir de sa date de mise à jour.
Cette date est la date d'import de la notice si elle n'a pas été mise à jour dans l'application, et sa date de création si elle a été créée dans l'application.
Cette commande est fournie par le module Django ``Haystack``. Sa documentation se trouve à l'adresse suivante : http://django-haystack.readthedocs.org/en/v2.1.0/management_commands.html
-console d'administration
+Console d'administration
========================
Le back-office offre une console d'administration donnant accès en particulier à la gestion des utilisateurs.
On y accède par le lien ``admin`` dans l'en-tête des pages si on est connecté en tant qu'administrateur ou bien en allant directement à l'adresse ``<racine du site>/p4l/admin/``.
-gestion des utilisateurs
+Gestion des utilisateurs
------------------------
L'administration des utilisateurs se fait à l'adresse suivante : ``<racine du site>/p4l/admin/p4l/user/``.
@@ -264,8 +264,8 @@
Le champ ``Permission de l'utilisateur`` doit donc comporter toutes les entrées de la forme ``p4l | <object> | <permission>``.
-Pour faciliter la gestion de ces permissions, le plus simple est de créer un groupe ``utilisateurs``. On affectera à ce groupe toutes les permissions sur les objects de l'application ``p4l``.
-il suffira ensuite de mettre les utilisateurs dans ce groupe (champ ``Groupes`` dans l'interface d'édition des utilisateurs). L'utilisateur héritera alors des parmissions du groupe.
+Pour faciliter la gestion de ces permissions, le plus simple est de créer un groupe ``utilisateurs``. On affectera à ce groupe toutes les permissions sur les objets de l'application ``p4l``.
+il suffira ensuite de mettre les utilisateurs dans ce groupe (champ ``Groupes`` dans l'interface d'édition des utilisateurs). L'utilisateur héritera alors des permissions du groupe.
Lancement d'un script
@@ -279,8 +279,8 @@
Cependant les trois suivants seront les plus utiles:
* `args`: soit une séquence d'arguments de programme, soit une chaine de caractères
- * `cwd`: le chemin du reepertoire de travail. Par défaut : ``None``
- * `env`: dictionnire donnant les variables d'evironement positinnées durant l'éxeecution du script.
+ * `cwd`: le chemin du répertoire de travail. Par défaut : ``None``
+ * `env`: dictionnire donnant les variables d'environnement positionnées durant l'exécution du script.
Il est recommandé que ``args`` soit une liste d'arguments et non une simple chaîne de caractères.
@@ -297,15 +297,15 @@
Plusieurs points sont à noter:
- * L'utilisation de cette fonctionnalité est à priori réservé pour une application installé sous Unix. (cela peut fonctionner sous Windows, mais cela n'a pas été testé)
+ * L'utilisation de cette fonctionnalité est à priori réservé pour une application installé sous Unix. (Cela peut fonctionner sous Windows, mais cela n'a pas été testé)
* La fermeture de la fenêtre du navigateur ne stoppe pas la commande
* En particulier si la session de l'utilisateur expire ou bien que la fenêtre du browser est fermée, il n'y a plus possibilité de stopper le processus à partir d'un browser.
- Le processus devra être interompu par les moyens habituels directement sur le serveur
- * La commande est lancée dans le contexte du serveur web. Elle est donc executé par l'utilisateur du serveur web et hérite de ces droits d'accès.
+ Le processus devra être interrompu par les moyens habituels directement sur le serveur
+ * La commande est lancée dans le contexte du serveur web. Elle est donc exécuté par l'utilisateur du serveur web et hérite de ces droits d'accès.
* Tout démarrage du serveur web stoppe la commande.
- * La commande partage les ressources du serveurs web. Attention donc à ne pas lancer des commandes trop gourmandes en ressources, cela peut avoir des conséquences sur la stabilité du serveur web et sa disponibilité.
+ * La commande partage les ressources du serveur web. Attention donc à ne pas lancer des commandes trop gourmandes en ressources, cela peut avoir des conséquences sur la stabilité du serveur web et sa disponibilité.
* L'affichage de la sortie de la commande dans le browser se fait ligne par ligne.
Si la sortie de la commande ne comporte pas de caractère de retour à la ligne (``"\n"``) rien ne s'affichera avant la fin de la commande.
* Les sorties erreur et standard sont affichée ensemble sans différentiation.
-
\ No newline at end of file
+
--- a/doc/architecture.rst Mon Dec 02 17:48:02 2013 +0100
+++ b/doc/architecture.rst Mon Dec 02 18:17:21 2013 +0100
@@ -1,4 +1,3 @@
-
************
Architecture
************
@@ -9,19 +8,19 @@
L'application Back-Office Plan4Learning utilise les technologies suivantes:
*Django* - https://www.djangoproject.com/
- C'est un framework web basé sur Python. de nombreux modules sont disponibles pour étendre ses fonctionnalités.
- En particulier, nous utilisons les modules suivant:
+ C'est un framework web basé sur Python. De nombreux modules sont disponibles pour étendre ses fonctionnalités.
+ En particulier, nous utilisons les modules suivants :
* *South* - http://south.aeracode.org/. Ce module permet de gérer les migration de bases de données (schéma + données).
On peut alors facilement appliquer les changements du modèle de donnée sur un système en production.
- * *Django REST Framework* - http://django-rest-framework.org/ : Permet de facilement de facilement mettre en oeuvre une API de type REST.
+ * *Django REST Framework* - http://django-rest-framework.org/ : Permet de facilement de facilement mettre en œuvre une API de type REST.
* *haystack* - http://haystacksearch.org/ : Facilite l'utilisation dans Django des moteurs d'indexation full-text comme Lucene ou elasticsearch
*Postgresql* - http://www.postgresql.org/
Base de donnée relationnelle. Nous l'utilisons en fait par l'intermédiaire de la couche ORM de Django
*Sesame* - http://www.openrdf.org/
- C'est en fait un framework de gestion RDF. Nous l'utilison ici comme triple store RDF et endpoint SPARQL
+ C'est en fait un framework de gestion RDF. Nous l'utilisons ici comme triple store RDF et endpoint SPARQL
*Elasticsearch* - http://www.elasticsearch.org/
Moteur d'indexation full-text basé sur Lucene. Nous l'utilisons par l'intermédiaire du module Django Haystack.
@@ -30,6 +29,6 @@
Framework javascript. Nous l'utilisons en particulier dans la page d'édition des notices afin de gérer les interactions complexes entre la notice et ses sous-objets.
*Bootstrap* - http://getbootstrap.com/
- Framework CSS. Il a été utilisee sur toutes les pages de l'application.
+ Framework CSS. Il a été utilisé sur toutes les pages de l'application.
-
\ No newline at end of file
+
--- a/doc/deploiement.rst Mon Dec 02 17:48:02 2013 +0100
+++ b/doc/deploiement.rst Mon Dec 02 18:17:21 2013 +0100
@@ -5,15 +5,15 @@
La documentation de déploiement suivante est sur la base d'une Debian 7.0 (Wheezy).
-options de déploiement
+Options de déploiement
======================
-De nombreuses options de déploiement existe. Les plus populaires sont décrite sur le site Django à l'adresse suivante : https://docs.djangoproject.com/en/1.5/howto/deployment/.
+De nombreuses options de déploiement existent. Les plus populaires sont décrite sur le site Django à l'adresse suivante : https://docs.djangoproject.com/en/1.5/howto/deployment/.
Nous décrivons ici l'installation de l'option apache + modwsgi : https://docs.djangoproject.com/en/1.5/howto/deployment/wsgi/modwsgi/
-installation des prérequis
+Installation des prérequis
==========================
Liste des prérequis
@@ -26,7 +26,7 @@
- sesame
Le reste des dépendances est fourni dans les sources.
-Toute les commandes ci dessous doivent se faire entant que ``root``, typiquement en prefixant toute les commandes avec ``sudo``.
+Toute les commandes ci dessous doivent se faire entant que ``root``, typiquement en préfixant toute les commandes avec ``sudo``.
Python 2.7
@@ -44,7 +44,7 @@
Apache et mod-wsgi
------------------
-On utilise les versions distribuée avec la debian 7.
+On utilise les versions distribuées avec la debian 7.
::
apt-get install apache2
@@ -74,7 +74,7 @@
Build tools
-----------
-La création de l'environement virtuel nécessite l'installation des outils de base de compilation. ::
+La création de l'environnement virtuel nécessite l'installation des outils de base de compilation. ::
apt-get install build-essential
@@ -87,27 +87,27 @@
Une partie de l'application accède au serveur Sesame directement en javascript depuis le navigateur de l'utilisateur.
Si le serveur Sesame est sur un autre domaine que l'application Back-Office (même si seulement le numéro de port change),
-il est nécessaire qu'il supporte les en-têtes CORS (c.f. http://en.wikipedia.org/wiki/Cross-origin_resource_sharing) en autorisant le domaine de l'application Back-Office.
+il est nécessaire qu'il supporte les en-têtes CORS (cf. http://en.wikipedia.org/wiki/Cross-origin_resource_sharing) en autorisant le domaine de l'application Back-Office.
Etapes de déploiement
=====================
-L'ensemble des commandes suivantes ne nécessite pas d'être exécutées comme utilisateur prilivégié.
+L'ensemble des commandes suivantes ne nécessite pas d'être exécutées comme utilisateur privilégié.
Organisation des sources / commandes Django
-------------------------------------------
-Les fichiers du projets peuvent être organisés en 4 groupes correspondant à des sous-répertoires
- - ``src`` : contient l'ensemble du code, template et resources statiques
- - ``virtualenv`` : script de création de l'environement virtuel et dépendances python
- - ``web`` : répertoire de publication des resources statiques
+Les fichiers du projet peuvent être organisés en 4 groupes correspondant à des sous-répertoires
+ - ``src`` : contient l'ensemble du code, template et ressources statiques
+ - ``virtualenv`` : script de création de l'environnement virtuel et dépendances python
+ - ``web`` : répertoire de publication des ressources statiques
- ``run`` : répertoire contenant les logs de l'application
-Django fournit un utilitaire en ligne de commande permettant l'execution de tâche d'administration. La documentation se trouve à l'adresse suivante : https://docs.djangoproject.com/en/1.5/ref/django-admin/ .
+Django fournit un utilitaire en ligne de commande permettant l'exécution de tâche d'administration. La documentation se trouve à l'adresse suivante : https://docs.djangoproject.com/en/1.5/ref/django-admin/ .
-Les resources statiques sont tous les fichiers additionnels qui constituent un site web : images, javascript, css,... .
+Les ressources statiques sont tous les fichiers additionnels qui constituent un site web : images, javascript, css,... .
.. _deployment-virtualenv:
@@ -115,21 +115,21 @@
Virtualenv
----------
-L'environement d'execution python est isolé de l'environement du système par l'utilisation d'un environement virtuel ou ``virtualenv``.
+L'environnement d'exécution python est isolé de l'environnement du système par l'utilisation d'un environnement virtuel ou ``virtualenv``.
Une documentation d'utilisation se trouve à l'adresse suivante : http://www.virtualenv.org/en/latest/ .
-Il faut en particulier noter la procédure d'activation de l'environement virtuel. Dans la suite, les commandes d'administration django devront être lancées après cette activation.
+Il faut en particulier noter la procédure d'activation de l'environnement virtuel. Dans la suite, les commandes d'administration django devront être lancées après cette activation.
-Un script permettant la création de l'environement virtuel et de l'installation de toutes les dépendances "python" est fourni dans le répertoire ``virtualenv``.
+Un script permettant la création de l'environnement virtuel et de l'installation de toutes les dépendances "python" est fourni dans le répertoire ``virtualenv``.
.. code-block :: sh
cd virtualenv/web/
python create_python_env.py
- python project-boot.py <chemin de l'environement virtuel>
+ python project-boot.py <chemin de l'environnement virtuel>
-Au cours de l'exploitation du serveur et en particulier lors des mise à jour du système d'exploitation, il faut être attentif aux mise à jour de la distribution python ayant servie à la création de l'environement virtuel.
-Si la version de python est mise à jour, l'environement virtuel devra lui aussi être mis à jour.
+Au cours de l'exploitation du serveur et en particulier lors des mise à jour du système d'exploitation, il faut être attentif aux mise à jour de la distribution python ayant servie à la création de l'environnement virtuel.
+Si la version de python est mise à jour, l'environnement virtuel devra lui aussi être mis à jour.
Configuration
-------------
@@ -158,33 +158,33 @@
Tout autre méthode est correcte. Attention cependant d'utiliser un encoding "utf-8".
-Le schema de la base est créé avec la commande django suivante (penser à préalablement activer l'environement virtuel)::
+Le schéma de la base est créé avec la commande Django suivante (penser à préalablement activer l'environnement virtuel)::
python manage.py syncdb --migrate
-Enfin on crée un "super" utilisateur pouvant accéder à l'admininistration du site.::
+Enfin on crée un "super" utilisateur pouvant accéder à l'administration du site.::
python manage.py createsuperuser
-Déploiement des resources statiques
------------------------------------
+Déploiement des ressources statiques
+------------------------------------
-Le déploiement des resources statiques du site se font à l'aide de la commande suivante:
+Le déploiement des ressources statiques du site se fait à l'aide de la commande suivante:
::
python manage.py collecststatic
-configuration web
+Configuration web
-----------------
La configuration web (apache) est documentée à l'adresse suivante : https://docs.djangoproject.com/en/1.5/howto/deployment/wsgi/modwsgi/ .
-Comme cette configuration dépend de l'environement propre au serveur, nous n'en détaillerons pas les étapes.
+Comme cette configuration dépend de l'environnement propre au serveur, nous n'en détaillerons pas les étapes.
Cependant, voici une liste des points notables:
- Bien faire la séparation entre la partie dynamique servie par modwsgi, et la partie statique servie par apache.
-- le système utilise un environement virtuel. Pensez bien à renseigner le chemin du répertoire ``site-packages`` dans la directive ``WSGIPythonPath``
+- le système utilise un environnement virtuel. Pensez bien à renseigner le chemin du répertoire ``site-packages`` dans la directive ``WSGIPythonPath``
- L'utilisation de ``mod_wsgi`` en mode démon (``daemon mode``) est fortement recommandée.
-
\ No newline at end of file
+
--- a/doc/description_interface.rst Mon Dec 02 17:48:02 2013 +0100
+++ b/doc/description_interface.rst Mon Dec 02 18:17:21 2013 +0100
@@ -7,14 +7,14 @@
Ces pages utilisent le framework css Bootstrap (http://getbootstrap.com/).
-Connection
-==========
+Connexion
+=========
.. image:: _static/p4l_connect.png
:width: 600pt
Toutes les pages de l'application sont protégées par un système de login/mot de passe.
-Ce dialogue de connection s'affiche lorsque l'utilisateur essaye d'accéder à une des pages de l'application et qu'il n'est pas connecté.
+Ce dialogue de connexion s'affiche lorsque l'utilisateur essaye d'accéder à une des pages de l'application et qu'il n'est pas connecté.
@@ -24,7 +24,7 @@
.. image:: _static/p4l_list.png
:width: 600pt
-Cet écram donne la liste des notices et permet la recherche.
+Cet écran donne la liste des notices et permet la recherche.
La recherche se fait sur l'identifiant d'une notice, le(s) titre(s) d'une notice et les auteurs (personnes ou institutions).
Les notices sont affichées dans l'ordre de leur identifiant (tri lexicographique ascendant) lorsque qu'aucune recherche n'est faite. Elles sont triées par tri de pertinence lorsqu'une recherche a été effectuée.
@@ -40,8 +40,8 @@
* titres (dans toutes les langues)
* auteurs (personnes et entités)
-Le champ de recherche permet l'utilisation d'un mini language de requête décrit à l'adresse suivante : http://pythonhosted.org/Whoosh/querylang.html
-Les points à noter à ce ce sujet sont :
+Le champ de recherche permet l'utilisation d'un mini langage de requête décrit à l'adresse suivante : http://pythonhosted.org/Whoosh/querylang.html
+Les points à noter à ce sujet sont :
* La recherche ne tient pas compte des accents
* L'opérateur par défaut est le ``OR``.
@@ -91,7 +91,7 @@
.. image:: _static/p4l_detail.png
:width: 600pt
-Cet écran donne accès à l'affichage du détail d'une notice. Deux boutons permettent soit de passer à l'écran d'édition de la notice, soit de pouvoir l'éfacer.
+Cet écran donne accès à l'affichage du détail d'une notice. Deux boutons permettent soit de passer à l'écran d'édition de la notice, soit de pouvoir l'effacer.
Un dialogue de confirmation de l'effacement sera affiché préalablement à l'utilisateur.
Par contre, tout effacement d'une notice est définitif.
@@ -106,13 +106,14 @@
Cet écran permet l'édition d'une notice (nouvelle ou bien existante).
Un bouton d'annulation permet d'interrompre l'édition d'une fiche à tout moment.
-Les modifications d'une fiche (ou bien sa création) ne seront sauvegardées seulement après avoir appuyer sur le boouton de sauvegarde.
+Les modifications d'une fiche (ou bien sa création) ne seront sauvegardées seulement après avoir appuyer sur le bouton de sauvegarde.
-Toute navigation hors de cet écran que ce soit en cliquant sur l'un des lien ou un des boutons de l'interface ou que ce soit en utilisant les fonctionalité du navigateur annulera sans prévenir l'édition en cours.
-Tout les changements non sauvegardés seront perdus.
+Toute navigation hors de cet écran que ce soit en cliquant sur l'un des lien ou un des boutons de l'interface ou que ce soit en utilisant les fonctionnalités du navigateur annulera sans prévenir l'édition en cours.
+Tous les changements non sauvegardés seront perdus.
Tous les champs sont éditables, a part les champs "identifiant" et "URI" qui sont en lecture seule.
-Deux boutons sont disponibles pour accéder au détail de la notice ou bien à son effacement. Dans ce dernier cas un dialogue de confirmation sera affiché anant l'effacement définitif de la notice.
+Deux boutons sont disponibles pour accéder au détail de la notice ou bien à son effacement. Dans ce dernier cas un dialogue de confirmation sera affiché avant l'effacement définitif de la notice.
-
+
+
--- a/doc/evolution.rst Mon Dec 02 17:48:02 2013 +0100
+++ b/doc/evolution.rst Mon Dec 02 18:17:21 2013 +0100
@@ -16,23 +16,23 @@
Ce mécanisme est basé sur l'utilitaire `gettext <http://www.gnu.org/software/gettext/manual/gettext.html#Concepts>`_.
-En particulier, dans l'arborescence des sources de l'application, les fichiers ``src/p4l/locale/*/LC_MESSAGES/django.[po,mo]`` sont les fichiers de resources de langues.
-Les fichier éditable sont les fichiesr ``.po``.
+En particulier, dans l'arborescence des sources de l'application, les fichiers ``src/p4l/locale/*/LC_MESSAGES/django.[po,mo]`` sont les fichiers de ressources de langues.
+Les fichier éditable sont les fichiers ``.po``.
-Deux commandes d'administration sont fournies par Django pour gérer les fichiers de resources de traduction:
+Deux commandes d'administration sont fournies par Django pour gérer les fichiers de ressources de traduction:
* ``makemessages`` : https://docs.djangoproject.com/en/1.5/ref/django-admin/#django-admin-makemessages.
C'est la commande permettant la création et la mis ā jour des fichiers ``.po``.
Cette commande extrait des fichier sources de l'application les chaîne de caractères à traduire et les places dans les fichier ``.po``.
- Typiquement, on ne lancera cette commande que si de nouvelle chaînes à trduire sont ajoutées dans l'application.
+ Typiquement, on ne lancera cette commande que si de nouvelles chaînes à traduire sont ajoutées dans l'application.
- * ``compilemessages`` : Compile les fichiers ``.po`` contitués par la commande précédente afin que les traduction soit prise en compte.
- cette commande produit les fichier ``.mo``.
+ * ``compilemessages`` : Compile les fichiers ``.po`` constitués par la commande précédente afin que les traduction soit prise en compte.
+ Cette commande produit les fichier ``.mo``.
-Ces commandes peuvent être lancées de plusieurs façon. Le plus simple est de les lancer depuis le répertoire ``src/p4l`` et avec l'utilitaire ``django-admin.py``.
+Ces commandes peuvent être lancées de plusieurs façons. Le plus simple est de les lancer depuis le répertoire ``src/p4l`` et avec l'utilitaire ``django-admin.py``.
Ce dernier est installé lors de l'installation de Django.
-Dans le cas de l'utilisation d'un environement virtuel, il se trouve dans le répertoire ``bin``, et de fait dans le "PATH" lorsque l'environement virtuel est activé.
+Dans le cas de l'utilisation d'un environnement virtuel, il se trouve dans le répertoire ``bin``, et de fait dans le "PATH" lorsque l'environnement virtuel est activé.
La suite des commandes pour
.. code-block:: bash
@@ -43,7 +43,7 @@
$ django-admin.py compilemessages
-modification des champs
+Modification des champs
=======================
La modification de la liste des champs traitée par le back-office nécessite des changements a plusieurs niveaux.
@@ -53,7 +53,7 @@
* :ref:`Évolution du schéma <evol-schema>` de la base de données
* :ref:`Modification du parser <evol-parser>` pour l'import.
* :ref:`Modification du sérialiseur <evol-serializer>` pour l'export
- + modification de la constante ``p4l.mapping.constants.GRAPH_NAMESPACES``
+ + Modification de la constante ``p4l.mapping.constants.GRAPH_NAMESPACES``
* :ref:`Modification du serialiseur rest <evol-rest-serializer>`.
*
* modification de l'écran d'affichage du :ref:`détail <evol-detail>` d'une notice.
@@ -61,7 +61,7 @@
La description de ces modifications se base sur la condition que le type de champ ajouté est le même qu'un champ déjà existant.
La création d'un nouveau type de champ est hors du scope de cette documentation,
-mais l'examen attentif des points suivants pourront être un point de dépard pour le développement.
+Mais l'examen attentif des points suivants pourront être un point de départ pour le développement.
.. _evol-config:
@@ -78,16 +78,16 @@
``SPARQL_REF_QUERIES``
^^^^^^^^^^^^^^^^^^^^^^
-les valeurs de ce dictionnaire sont elle même un dictionnaire qui contient les requêtes SPARQL d'exploration des reeférentiels.
+les valeurs de ce dictionnaire sont elle même un dictionnaire qui contient les requêtes SPARQL d'exploration des référentiels.
les clés suivantes sont à renseigner:
* ``url`` : url du endpoint pour ce référentiel. On n'y mettra ``SPARQL_QUERY_ENDPOINT`` la plupart du temps.
* ``filter`` : requête filtrant les entrées du référentiel selon une partie de terme.
- Cette requète est utiliser pour faire de l'autocomplétion.
+ Cette requète est utilisé pour faire de l'auto complétion.
* ``root`` : Requête qui donne les racines des référentiels en arbre et l'ensemble des termes pour les autres
- * ``childs`` : Requ6ete donnant les enfants d'un noeud particulier pour les référentiel "arbre".
+ * ``childs`` : Requête donnant les enfants d'un nœud particulier pour les référentiel "arbre".
Cette clé n'a pas besoin d'être renseigné pour les autres.
- * ``child-count`` : Nombre denfant pour 1 noeud d'un référentiel arbre. N'a pas besoin d'être renseignee pour les autres.
+ * ``child-count`` : Nombre d’enfants pour 1 nœud d'un référentiel arbre. N'a pas besoin d'être renseignée pour les autres.
``RDF_SCHEMES``
@@ -98,7 +98,7 @@
.. _evol-schema:
-Modification du schema de la base de donnée
+Modification du schéma de la base de donnée
-------------------------------------------
Modification du modèle Django
@@ -108,7 +108,7 @@
La documentation Django sur les modèle se trouve à l'url suivante https://docs.djangoproject.com/en/1.5/topics/db/models/
le modèle du projet se trouve dans ``src/p4l/models`` et en particulier la définition d'une notice (objet ``Record``) dans ``src/p4l/models/data.py``.
-ce fichier contient toute les définitions des champs actuellement utilisés et pourra servir de base d'exemple pour les évolutions envisagées.
+Ce fichier contient toute les définitions des champs actuellement utilisés et pourra servir de base d'exemple pour les évolutions envisagées.
Attention, contrairement à la documentation Django, il ne faut pas appliquer pas la commande ``syncdb`` pour mettre à jour le schema de la base de donnée.
@@ -116,7 +116,7 @@
Utilisation de South
^^^^^^^^^^^^^^^^^^^^
-Pour assurer la gestion des migration de modèle de donnée sur des base en production nous utilison le module Django South : http://south.aeracode.org/.
+Pour assurer la gestion des migration de modèle de donnée sur des base en production nous utilisons le module Django South : http://south.aeracode.org/.
L'utilisation de ce module passe par la création de migrations.
@@ -139,21 +139,21 @@
Le parser est définit dans le fichier ``src/p4l/mapping/parsers.py``, plus particulièrement dans la classe ``RecordParser``.
La définition des champs et des sous-objets se fait dans la méthode ``build_record``.
-Le parsing des données du graphe se fait en fait à l'aide de deux méthodes principales défines sur la classe ``RecordParser``:
+Le parsing des données du graphe se fait en fait à l'aide de deux méthodes principales définies sur la classe ``RecordParser``:
- * ``extract_single_value_form_graph`` : permet d'extraire une valeur simple du graphe. elle est utilisée pour les champs simples monovalués.
+ * ``extract_single_value_form_graph`` : permet d'extraire une valeur simple du graphe. Elle est utilisée pour les champs simples monovalués.
* ``extract_multiple_values_from_graph`` : Gère l'ajout d'objet à un gestionnaire d'objets liés ("related object manager" : https://docs.djangoproject.com/en/1.5/ref/models/relations/).
- Les données nécessaire pour la création des objets sont extraites du graphe.
+ Les données nécessaires pour la création des objets sont extraites du graphe.
Points à noter:
- #. les champs simples doivent être positionnés avant la sauvegarde de la notice (appel à la méthode save du modèle ``Record``).
+ #. Les champs simples doivent être positionnés avant la sauvegarde de la notice (appel à la méthode save du modèle ``Record``).
Par contre les champs complexes (sous objets, champs multivalués,...) doivent être traités après l'appel à ``.save()``
#. Lorsqu'une notice est mise à jour, l'objet ``Record`` et ces dépendances sont effacés et recréés
#. Sauf pour les champs gérés par un référentiel, ll y a une relation d'aggregation entre l'objet ``Record`` et ses sous objets.
Dans le cas des champs complexes avec référentiel, c'est une relation multiple (many to many).
- Dans ce cas lors de l'effacement d'un object ``Record``, seul les entrées dans les tables de liason sont effacées. Les entrée dans les tables de référentiel se sont pas affectées.
+ Dans ce cas lors de l'effacement d'un object ``Record``, seul les entrées dans les tables de liaison sont effacées. Les entrées dans les tables de référentiel ne sont pas affectées.
#. Sur les champs avec référentiel, il n'y a pas de validation. Les entrées dans les tables de référentiels sont crées à la demande, sans validation par rapport au repository Sésame.
#. L'ensemble de la création (ou de l'effacement) d'un objet ``Record`` et de ces dépendances est fait dans une transaction.
@@ -163,10 +163,10 @@
Modification du serialiseur pour l'export
-----------------------------------------
-l'export des notices au format rdf se fait avec la commande ``dump_record`` (cf :ref:`admin-dump-record`).
+L’export des notices au format rdf se fait avec la commande ``dump_record`` (cf :ref:`admin-dump-record`).
Chaque objet ``Record`` concerné par l'export est transformé en graphe rdf par un serialiseur. Le graphe rdf est ensuite sérialisé en xml.
-Le serializer est défini dans le fichier ``src/p4l/mapping/__init__.py`` et fait appel à des resources se trouvant dans ``src/p4l/mapping/serializers.py``.
+Le serializer est défini dans le fichier ``src/p4l/mapping/__init__.py`` et fait appel à des ressources se trouvant dans ``src/p4l/mapping/serializers.py``.
Les interfaces définies dans ce modules sont inspirées de celle proposée par le module ``Rest framework`` que nous utilisons par ailleurs (cf. :ref:`evol-rest-serializer`).
En particulier on pourra lire la documentation des ``serializer``: http://django-rest-framework.org/api-guide/serializers.html .
@@ -185,14 +185,14 @@
La documentation sur les ``serializer`` du Rest Framework est à l'adresses suivante : http://django-rest-framework.org/tutorial/1-serialization.html.
La documentation de l'api des serializer se trouve aux url suivantes : http://django-rest-framework.org/api-guide/serializers.html, http://django-rest-framework.org/api-guide/fields.html, http://django-rest-framework.org/api-guide/relations.html.
-Nous utilisons les mécanismes standarts de sérialisation du ``REST Framework``. Nous avons juste adaptee les points suivants:
+Nous utilisons les mécanismes standards de sérialisation du ``REST Framework``. Nous avons juste adapté les points suivants:
- * Pour les champs contrôlés par un référentiel, le mécanisme standart du ``REST Framework`` est d'accepter les valeurs que si elle sont déjà présente dans la base.
- Nous avons changé ce comportement pour accepter toute les valeurs et de créer les nouvelles à la demande. Ceci a été fait pour simplifier la gestion des référentiels et la centraliser en amont du back office.
+ * Pour les champs contrôlés par un référentiel, le mécanisme standard du ``REST Framework`` est d'accepter les valeurs que si elle sont déjà présente dans la base.
+ Nous avons changé ce comportement pour accepter toutes les valeurs et de créer les nouvelles à la demande. Ceci a été fait pour simplifier la gestion des référentiels et la centraliser en amont du back office.
Ceci est implémenté dans la classe ``p4l.api.serializers.ThesaurusSerializer``.
* Pour les champs multiples et les sous-objets, l'ID de l'objet en base n'est pas sérialisée. Ceci se trouve dans la classe ``p4l.api.serializers.P4lModelSerializer``.
* Lors d'un update, les sous-objets sont effacés puis recréés. cela a pour conséquence qu'un update partiel n'est pas possible. A chaque requête de mise à jour, l'ensemble de l'objet ``Record`` et de tous ses sous-objets doit être envoyé à l'API REST d'update.
- * Une modification du seerializer REST n'est nécessaire que si le nouveau champ est contrôlé par un référentiel (bien sur si ce nouveau champs est d'un type déjà supporté par l'application).
+ * Une modification du seerializer REST n'est nécessaire que si le nouveau champ est contrôlé par un référentiel (bien sur si ce nouveau champ est d'un type déjà supporté par l'application).
.. _evol-ref-labels:
@@ -201,12 +201,12 @@
-------------------------------------------------------------------------------
L'application ne gère pas les labels des valeurs des champs contrôlés par référentiel.
-Pour l'affichage dews notices il est donc nécessaire de préalablement requêter tous ces labels.
+Pour l'affichage des notices il est donc nécessaire de préalablement requêter tous ces labels.
-Ce requêtage se fait dans la méthode ``p4l.views.fill_label_for_model`` (dans le fichier ``src/p4l/views.py``).
+La requête se fait dans la méthode ``p4l.views.fill_label_for_model`` (dans le fichier ``src/p4l/views.py``).
Cette méthode retourne un dictionnaire où les clefs sont les uri des termes, et les valeurs les labels correspondants dans la langue demandées.
-Bien sur aucune modification est nécessaire si le champ ajouté ou modifié n'introduit pas un nouveau référentiel.
+Bien sur aucune modification n’est nécessaire si le champ ajouté ou modifié n'introduit pas un nouveau référentiel.
.. _evol-detail:
@@ -214,7 +214,7 @@
Modification de l'écran de détail
---------------------------------
-L'écran de détail d'une notice (c.f. :ref:`interface-detail`) utilise le couple classique vue/template Django.
+L'écran de détail d'une notice (cf. :ref:`interface-detail`) utilise le couple classique vue/template Django.
La documentation Django sur les vues est à l'url suivante : https://docs.djangoproject.com/en/1.5/topics/class-based-views/.
La documentation Django sur les template est ici : https://docs.djangoproject.com/en/1.5/topics/templates/.
@@ -231,30 +231,30 @@
---------------------------------
Comme pour l'écran de détail, l'écran d'édition d'une notice (c.f. :ref:`interface-edit`) utilise un couple vue/template Django. (c.f. :ref:`evol-detail` pour les url de documentation Django)
-Par contre les fonctionnalités de cette page sont nettement plus complexes dans leur mise en oeuvre.
+Par contre les fonctionnalités de cette page sont nettement plus complexes dans leur mise en œuvre.
La vue d'édition d'une notice est générée par la classe suivante : ``p4l.views.RecordEditView`` (dans le fichier ``src/p4l/views.py``).
Le template d'affichage du détail est le suivant : ``src/templates/p4l/record_update_form.html``.
Par ailleurs la vue d'édition est en fait une véritable application web ("webapp") basée sur la librairie Angularjs (http://angularjs.org/).
Elle est implémentée dans le fichier ``src/p4l/static/p4l/js/p4l.js``.
-La page fait aussi appel à des resources (des templates) dans le reepertoire ``src/p4l/static/p4l/template``.
+La page fait aussi appel à des ressources (des templates) dans le répertoire ``src/p4l/static/p4l/template``.
Normalement, seul les fichiers template Django ``src/templates/p4l/record_update_form.html`` ou bien angular ``src/p4l/static/p4l/templates`` auront besoin d'être modifiés pour ajouter ou modifier un champs d'un type déjà existant.
-Lors du chargement de la page d'édition, les données de la notice sont chargée à partir de la couche d'API REST sous forme d'objets sérialisés en JSON.
+Lors du chargement de la page d'édition, les données de la notice sont chargées à partir de la couche d'API REST sous forme d'objets sérialisés en JSON.
Ces données viennent remplir le "modèle" de l'appli web.
-Ce modèle est ensuite exploité dans une série de directives Angularjs (c.f. http://docs.angularjs.org/guide/directive) qui permettent l'éditions des différents champs et sous-objets de la notice.
+Ce modèle est ensuite exploité dans une série de directives Angularjs (c.f. http://docs.angularjs.org/guide/directive) qui permettent l’édition des différents champs et sous-objets de la notice.
Lors de la sauvegarde, ce modèle est sérialisé en JSON et soumis par requête http à la couche d'API REST de l'application.
Le formulaire d'édition utilise 4 types d'éléments pour gérer les différents champs et sous-objets de l'objet notice.
- * Pour les champs simples: des contôles html (``input``, ``textarea``...) liés au modèle dans un formulaire Angularjs (http://docs.angularjs.org/guide/forms)
+ * Pour les champs simples: des contrôles html (``input``, ``textarea``...) liés au modèle dans un formulaire Angularjs (http://docs.angularjs.org/guide/forms)
* Pour les champs simples liés à un référentiel : la directive :ref:`simple-sem-uri <evol-edition-simple-sem-uri>`.
* Pour les champs complexes liés à un référentiel : la directive :ref:`add-sem-uri <evol-edition-add-sem-uri>`.
* Pour les champs complexes autres (sous-objets) : la directive :ref:`object-list <evol-edition-object-list>`.
Les contrôles html et l'usage qu'Angularjs en fait sont documentés dans la référence d'API : http://docs.angularjs.org/api/.
-Le reste des directives est documenté ci-après et on pourra se basé sur les champs existant pour aveoir des exemple d'utilisation.
+Le reste des directives est documenté ci-après et on pourra se baser sur les champs existant pour avoir des exemple d'utilisation.
.. _evol-edition-simple-sem-uri:
@@ -272,7 +272,7 @@
^^^^^^^^^^^^^^^^^^^^^^^^^
* ``list`` : le champ du modèle lié à cette directive, ce doit être une liste (champ multivalué).
- * ``listname`` : Une des clefs du paramètre de configuration ``SPARQL_REF_QUERIES`` (c.f. :ref:`evol-config-SPARQL-REF-QUERIES`)
+ * ``listname`` : Une des clefs du paramètre de configuration ``SPARQL_REF_QUERIES`` (cf. :ref:`evol-config-SPARQL-REF-QUERIES`)
* ``placeholder`` : texte d'aide du champs de saisie pour le référentiel.
@@ -291,7 +291,7 @@
L'unité est une colonne définie par le système de grille Bootstrap : http://getbootstrap.com/css/#grid.
* ``label-fields`` : Label des colonnes pour le mode table. Ces labels sont traduits. L'ordre des colonnes est le même que pour ``object-fields``.
-Les templates définis par les paramêtres ``form-template`` et ``disp-template`` se trouvent dans le répertoire ``src/p4l/static/p4l/templates``.
+Les templates définis par les paramètres ``form-template`` et ``disp-template`` se trouvent dans le répertoire ``src/p4l/static/p4l/templates``.
Ce sont des templates Angularjs (c.f. http://docs.angularjs.org/guide/dev_guide.templates).
Pour les template ``form-template``, l'objet édité est dans la variable ``editedObj``.
Pour les template ``disp-template``, l'objet édité est dans la variable ``obj``.
@@ -299,3 +299,4 @@
Attention, ce sont des ressources statiques pour l'application.
Si ils sont modifiés, la commande ``collectstatic`` doit être lancée afin qu'ils soient correctement déployés et pris en compte par Angular.
+