|
Taille: 4871
Commentaire: commentaire
|
← Version 24 à la date du 2008-02-21 22:09:47 ⇥
Taille: 6483
Commentaire: converted to 1.6 markup
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| ## page was renamed from Projet/GestionDesUtilisateursDesCampus/InterventionOusmane | |
| Ligne 3: | Ligne 4: |
| Si vous avez un accès RPV jusqu'à Dakar, voir le code sur http://trac.sn.auf/guia/ | Voir le code sur http://trac.sn.auf.org/guia/ |
| Ligne 5: | Ligne 6: |
| == Gestion des extensions (plugins) == | === Vue générale === L''application est bâtie autour de quatres composantes principales: * Données de base: Ce sont les données fonctionnelles comme définit dans l'analyse (utilisateur, groupe, abonnement, groupes, extra_*, etc) * Interface utilisateur: Il s'agit de l'interface de gestion des données de base * Greffons: Les application ajoutées non indispensables pour les traitements métiers associés aux données de base. * Signaux: Le canal de communication entre le coeur et les greffons === Gestion des extensions (plugins) === |
| Ligne 11: | Ligne 28: |
| 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. | 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). |
| Ligne 13: | Ligne 30: |
| == Accès ligne de commande (CLI) == | 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. |
| Ligne 15: | Ligne 32: |
| 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. | |
| Ligne 16: | Ligne 34: |
| === 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. |
|
| Ligne 17: | Ligne 37: |
| = Copier/coller d'un mail d'Ousmane (23 nov) = | 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). |
| Ligne 19: | Ligne 39: |
| === Top-Down === | === Quelques fenêtres AJAX (05/02/2007) === {{attachment:Abonnement_AJAX_ACT.png}} {{attachment:Abonnements_AJAX.png}} |
| Ligne 21: | Ligne 43: |
| Nous fournissons toute les commandes add{user,group} 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 invoquent directement l'API gracieusement offerte par Django pour: * Renseigner les données de base * Demander à chaque greffon s'il dispose d'une méthode homonyme (callable) auquel cas il est appelé pour faire son travail. * Les greffons font leurs boulot. === Bottom-up === La même chose que ce qu'on a dit hier: * Un modèle de base avec les données de base et la recherche et le chargement des plugins installés. * Un Rep Plugins avec pour chaque plugin un rep à sa disposition. * Les Plugins 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 tant qu'il fournissent un Plugin::add{User,Group}(). 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. === Le Point === Côté implémentation de tout ceci j'ai pas du tout avancer (en fait j'ai rien foutu depuis que je suis parti du bureau hier) et donc le point ou j'en suis c'est de trouver une façon élégante pour les plugins de s'intégrer dans l'API après coup. Je te dirais dans la journée comment j'avance. Dans tous les cas l'objectif actuellement c'est de faire une intégration fonctionnelle nous permettant de revenir après de façon transparente sur l'intégration des plugins (sans déranger les interfaces qu'on fournit admin et CLI principalement) === ETAT AU 23/11/2006 === |
=== ETAT AU 25/11/2006 === |
| Ligne 47: | Ligne 50: |
| attachment:Acceuil.png attachment:AjoutUtilisateur.png attachment:Utilisateurs.png |
[[attachment:Acceuil-251106.png|{{attachment:tmp.160.Acceuil-251106.jpg}}]] [[attachment:AjouterAbonnement-251106.png|{{attachment:tmp.160.AjouterAbonnement-251106.jpg}}]] [[attachment:AjouterOrganisme-251106.png|{{attachment:tmp.160.AjouterOrganisme-251106.jpg}}]] [[attachment:AjouterUtilisateur-251106.png|{{attachment:tmp.160.AjouterUtilisateur-251106.jpg}}]] |
| Ligne 57: | Ligne 61: |
| * Définir quelques métiers (Postfix, AUth) par un sys admin de renommé mondial comme Tini si ce n'est déjà fait. * Implémenter les métiers. * Permettre aux Greffons de synchroniser leurs données par rapport au schema de base (PUSH et PULL). |
* Définir quelques métiers (Postfix, Auth) par un sys admin de renommé mondial comme Tini si ce n'est déjà fait. * Mettre en oeuvre un système de notification permettant aux objets de s'enregistrer et de reçevoir les évenements qui les intéressent (voir le papier de Jim Fulton sur http://www.python.org/pycon/2005/papers/29/) * Implémenter les métiers (Utiliser l'appli et l'aide de JC pour la mise en oeuvre du greffon de Ges. des Doc.) * Définir une vue et un modèle pour la gestion des paramètres personnelles * Permettre aux Greffons de synchroniser leurs données par rapport au schéma de base (PUSH et PULL???). |
| Ligne 61: | Ligne 67: |
| * Fournir Interfaces (Dé)Installation de Plugins | * Fournir Interfaces (dés)installation de greffons |
| Ligne 63: | Ligne 69: |
| * Superbe idée de Jerôme: Gestion d'une file d'attente des événements (réplication). Les objets peuvent être marshalés/Picklés ensuite transférés pour être réveillés et injectés. <!> mhhh... use french only please... we work for the Francophonie, you know? ;-) -- JeanChristopheAndré -- D'accord Chef! :) OusmaneWilane | |
| Ligne 64: | Ligne 71: |
| * Les magiciens/wizards des css pour une autre tête du site admin * Gèler l'ajout de nouvelles fonctionnalités |
* Les magiciens (''wizards'') des CSS pour une autre tête du site admin * Geler l'ajout de nouvelles fonctionnalités |
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:
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 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.
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).
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.
Mettre en oeuvre un système de notification permettant aux objets de s'enregistrer et de reçevoir les évenements qui les intéressent (voir le papier de Jim Fulton sur http://www.python.org/pycon/2005/papers/29/) Superbe idée de Jerôme: Gestion d'une file d'attente des événements (réplication). Les objets peuvent être marshalés/Picklés ensuite transférés pour être réveillés et injectés. Les magiciens ( D'autres tâches ?
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é Gestion des extensions (plugins)
Accès ligne de commande (CLI)
Quelques fenêtres AJAX (05/02/2007)
ETAT AU 25/11/2006
A Faire pour une v0.1
wizards) des CSS pour une autre tête du site admin 
mhhh... use french only please... we work for the Francophonie, you know? 
-- JeanChristopheAndré -- D'accord Chef! 
OusmaneWilane Commentaires