Modifications entre les versions 3 et 4
Version 3 à la date du 2006-11-22 16:43:49
Taille: 900
Commentaire:
Version 4 à la date du 2006-11-23 09:36:31
Taille: 2751
Éditeur: ThomasNoël
Commentaire:
Texte supprimé. Texte ajouté.
Ligne 5: Ligne 5:
= Gestion des extensions (plugins) = == Gestion des extensions (plugins) ==
Ligne 13: Ligne 13:
= Accès ligne de commande (CLI) = == Accès ligne de commande (CLI) ==



= Copier/coller d'un mail d'Ousmane (23 nov) =

=== Top-Down ===

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)

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

Si vous avez un accès RPV jusqu'à Dakar, voir le code sur http://trac.sn.auf/guia/

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.

Accès ligne de commande (CLI)

Copier/coller d'un mail d'Ousmane (23 nov)

Top-Down

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)

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