WikiTeki /  Modifications de « Projet/GUIA/InterventionOusmane »

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:

• 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)

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)

• Sync avec Sebastien Lanteigne et valdation du modèles (cardinaux des relations et besoins exprimés non pris en compte) (déférée! Attente de Sebastien)
• Compléter le modèle avec les classes connexes (organismes, groupes, abonnement, etc) (FAIT)
• Définir les interfaces des outils principaux (CLI) avec des wrappers bidons sur les métiers
• 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???).
• Définir les états les plus demandés.
• Fournir Interfaces (dés)installation de greffons
• Fournir les Imports/Export par lot.

• 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

• Quelques statistiques utiles

• Les magiciens (wizards) des CSS pour une autre tête du site admin

• Geler l'ajout de nouvelles fonctionnalités
• Tests, corrections de bogues, et cycles de publication alpha, beta, rc, etc.

D'autres tâches ?

Commentaires