[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Epnadmin-fr] EPNadmin 0.8 :: Gestion du temps (Calendar)
From: |
Marc C |
Subject: |
[Epnadmin-fr] EPNadmin 0.8 :: Gestion du temps (Calendar) |
Date: |
Mon, 25 Oct 2004 16:39:16 +0100 |
User-agent: |
KMail/1.7 |
Bonjour
J'essaye de définir la direction à prendre pour le développement de la gestion
du temps au sein d'EPNadmin. J'ai observé l'application du point de vue du
temps, en voici le résumé :
Les parties de l'application concernées par la gestion du temps :
- accès individuel [usager + poste + créneau horaire ]
- session [initiation + animateur + salle ou postes + créneau horaire]
- prêt [ liste d'équipements + date début prévu et réel, fin prévu et réel ]
- ouverture salle [ salle + créneau horaire d'ouverture ]
- activité animateur [animateur + activité + créneau horaire ]
- avancement projet [ projet + avancement + salle/postes + créneau horaire]
L'implémentation actuelle consiste en une table dediée à la planification de
chacune de ses tâches (room_calendar, session, facilitator_calendar).
Afin de faire évoluer l'application que pensez vous d'avoir :
a. une table commune Calendar
(solution proposée dans mon mail précédent "Calendar/Planning")
Une table centrale dans laquelle on ajoute des événements en spécifiant :
identifiant unique, date heure de debut, durée et type de l'événement.
Des tables liant le calendrier et les types d'événement, par exemple :
. la table session ne comporterait plus les informations de temps mais
seulement l'identifiant unique de l'événement planifier.
. une table acces_individuel sera créer comportant l'identifiant usager, celui
du poste utilisé et celui de l'événement.
Avantages :
- une table contenant tous les événements, identifié par type
- une interface (utilisateur et développeur) générique pour la planification
des événements
Inconvénient :
- les types d'événements doivent être bien définie, par exemple pour le prêt
d'équipement il devrait y avoir 4 types d'événement : pret_debut_prevu,
pret_debut_reel, pret_fin_prevu et pret_fin_reel.
b. une table dediée à chaque partie
Nous gardons la structure SQL existante et continuons de l'appliquer pour
chaque module ajouté, mais ces tables devront avoir la même structure afin de
pouvoir utiliser des outils identiques( formulaire pour les utilisateurs et
fonctions pour les développeurs).
Avantage :
- indépendance des modules pour la gestion du planning
Inconvénient :
- redondance des tables, n tables pour n modules
pgpwZTI5PbZ11.pgp
Description: PGP signature
- [Epnadmin-fr] EPNadmin 0.8 :: Gestion du temps (Calendar),
Marc C <=