L'intervention d'OusmaneWilane : 100h de développement sur différents sujets

Voir le code sur http://trac.sn.auf.org/guia/

Vue générale

Lapplication est bâtie autour de quatres composantes principales:

Gestion des extensions (plugins)

En gros nous avons le cœur de l'application (main - également application Django) avec un répertoire pour les greffons (main/plugins).

Chaque greffon dispose d'un sous-répertoire contenant un « constructeur » __init__.py pour l'initialisation de la classe métier principale.

La classe principale du greffon est liée à la classe utilisateur par un lien foreign key Django et est censée invoquer la classe extra_utilisateur pour la persistance des données (variable/valeur) en invoquant la méthode save() de celle-ci et en inhibant la sienne. Ensuite la classe définit sa logique métier qu'elle connaît mieux que personne dans son usine (usine.py justement).

Les greffons dans leurs fabriques reçoivent les notifications de modifications d'objets leurs pemettant de réagir et d'ajuster leurs tourneur mécanique. Les types d'évenement qu'ils peuvent reçevoir sont où ceux intégrés directement à Django (pre_save, post_save, etc -- avec à chaque fois le nom de l'objet qui a émit le signal) où des signaux personalisés qui peuvent être liés à des méthodes des objets. L'émission de signaux reste dans le seul sens (coeur => greffons) et chaque greffon utilise un mécanisme adapté de mise à jour asynchrones de ses données pour éviter que le coeur plante à cause des problèmes des greffons.

Les Greffons sont autonomes en termes de gestion de leurs données internes, la seule contrainte qu'on leurs impose c'est la cohérence des interfaces qu'ils fournissent au modèle de base, autrement dis ils sont libre d'organiser leurs objets comme ils veulent. Ils peuvent stocker leurs données de configuration générale dans la base principale de l'API tant qu'ils sont les seuls à y accéder.

Accès ligne de commande (CLI)

Les outils lignes de commande accèdent directement au modèle proposé par Django et déclenchent les même signaux pour la notification des greffons et chaque greffon prend ses respinsabilités.

Nous fournissons toute les commandes add{user,group}, passwd les plus proches possibles des classiques fournissant les propriétés intéressantes ajoutées au modèle de données que vous avez retenu. Ces commandes sont écrites de sortes qu'elles puissent être invoquées comme commande ou comme modules à importer dans d'autres applications Python (Pas de soucis à se faire pour la propagation des signaux).

Quelques fenêtres AJAX (05/02/2007)

Abonnement_AJAX_ACT.png Abonnements_AJAX.png

ETAT AU 25/11/2006

Un modèle de greffon qui fonctionne en gros avec un annuaire de plugin (activer/ désactiver le plugin main/plugins/init.py). En gros c'est juste un modèle dans plusieurs fichiers (plugins). L'interface Admin possède les mêmes objet. Le truc c'est qu'actuellement les greffons possèdent leurs propre table et font une mise-à-jour explicite de la table extra_utilisateur dans leurs méthodes save(), ce qui permet de trouver une autre façon d'implémenter tout ça de façon transparente une fois qu'on a une API qui tourne.

attachment:Acceuil-251106.png attachment:AjouterAbonnement-251106.png attachment:AjouterOrganisme-251106.png attachment:AjouterUtilisateur-251106.png

A Faire pour une v0.1

D'autres tâches ?

Commentaires

Pour le PUSH/PULL, pour ma part je dirais qu'on a surtout besoin du PULL (extraction des données vers la configuration système locale). Le PUSH (insertion de données) est utile dans une moindre mesure, car je considère qu'on ne devrait intervenir sur les données que depuis l'interface web, ou au pire depuis la ligne de commande. Mon point de vue est bien entendu ouvert à discussion. -- JeanChristopheAndré

Projet/GUIA/InterventionOusmane (dernière édition le 2008-02-21 22:09:47 par localhost)