Le mardi 23 mars 2010 à 16:46 +0100, Benjamin POUSSIN a écrit :
On Tue, 23 Mar 2010 12:12:55 +0100 Florian Desbois <fdesbois@codelutin.com> wrote:
Ci-joint une première ébauche du modèle de la v2.0.
Quelques petites remarques/questions:
Probleme dans le modele ? =========================
Pourquoi dans Poll 'ChoiceType' est un 'int' dans dans Choice 'ChoiceType' est un 'String' ?
Un oubli, le ChoiceType de Choice devrait etre un int. D'ailleurs sa présence dans Choice est discutable, les choix etant toujours fortement liés et manipulés via le Poll.
Tu as fait disparaitre l'objet PollType du modele et maintenant a priori c juste une champs 'int' dans Poll (c un exemple y'en a d'autre qui on ete modifier de la meme facon). Ca veut dire que dans le code tu as un enum (ou equivalent) ? plutot que d'avoir ca dans la base ?
Exactement
Je n'arrive pas a voir a quoi correspond le lien 'person' sur PollAccount
PollAccount peut représenter un groupe de personnes donc le lien sert dans ce cas.
Vote par groupe et double depouillement =======================================
J'ai du mal a voir comment sera stocker les votes par groupes :(. Par exemple un vote pour l'acceptation d'un membre dans LE se fait par un seul vote qui donne trois resultats: - un resultat direct par les voix de chaque votant - un resultat par entreprise votante - un resultat qui reprend les deux autres resultats comme donnees d'entrees
exemple: CL(estelle, yannick, jean, eric, tony) et EO(Pierre) et EE(Anne) Estelle: oui \ yannick: oui \ jean: oui => oui eric: non / tony: oui /
Pierre: non => non
Annee: non => non
1er depouillement (par personne): 4 oui, 3 non => oui 2eme depouillement (par entreprise): 1 oui, 2 non => non
Au final le postulant ne deviendra pas membre car le depouillement par entreprise ne donne pas un oui.
Et lors de l'affichage des resultats il serait bon d'avoir les 3 resultats: oui pour les personnes, non pour les entreprises et non final
La je pense qu'il faut que je réfléchisse sur la sauvegarde des résultats. Normalement on a tout dans l'entité Result, mais il n'y a pas de propriété permettant de dire si c le gagnant ou non. On aura le detail des groupes dans l'entité Vote lié au PollAccount correspondant au groupe.
De la meme facon pour le vote condorcet il serait bien d'avoir les resultats des combats participant par participant (demande d'ouvaton)
Idem faut réfléchir a comment sauver ces données depuis le moteur de dépouillement.
Ajout de futur type de depouillement et type de choix =====================================================
Comment penses-tu gerer tous les types de choix (futur) et les types de sondage (futur). Par exemple on a actuellement: String, date, image mais peut-etre y en aura-t-il d'autre ?
Enumerations
(comment gere tu les images dans ton modele ? description contient l'uri de l'image ?)
en fait seul le nom de l'image est sauvé dans le champ name. La gestion des fichiers images est fait dans un ServiceImage (pour le moment lié à Tapestry ce qui est pratique).
Passage a d'autres echelles ===========================
Il faut absolument penser tout de suite aux grandes echelles :). Par exemple est ce qu'un vote pour 200000 personnes ca passe si oui, toutes les options passes ? resultat continu, vote non anonyme, .... Je pense qu'il serait bien de faire des petits bench sur les temps de calcul des resultats en fonction du nombre de vote (pour qu'on est une idee en fonction du mode de depouillement) (et aussi des tests unitaires sur les types de depouillement :))
Vi faudrait bourriner un peu de tests le moteur de dépouillement.
Accent a pollen par une application externe ===========================================
Je ne sais pas si tu as parle avec Eric pour l'ecriture des services, mais peut-etre introduire comme dans Lima OpenEJB qui devrait permettre de repondre facillement a la question d'un utilisateur: comment utiliser pollen en tant que service.
J'ai créé un Transformer tres pratique qui me genere les squelettes des méthodes des services. Je pense que le passage à OpenEJB se passera sans trop de souci au vu de ce qu'a fait Eric.
Chiffrage en temps de dev et migration ======================================
Je ne connais pas le temps de remise a plat du modele (avec test et verification de bonne migration, mais peut-etre faut-il tout de meme conserver la branche actuelle et faire un peu de maintenance dessus)
Oui, la branche sera surement maintenu pendant le dev.
a moins que tu me dises que tu peux tout faire en 1 jours ;). Car n'oublies pas que tu as maintenant de l'obsmer a faire :)
Vi, je vais bien voir comment je gere les deux en meme temps. Il faudra revoir l'intégralité des demandes de pollen et faire le chiffrage de la v2.0 pour avoir une meilleure visibilité du temps à passer. Pour le moment je dirais que le modèle semble bon (a part la sauvegarde des résultats a peaufiner) et que le socle du business est pret (context, applicationConfig, generation squelette des services, plus de DTO). Je ne devrais plus avoir qu'a me concentrer sur le réel métier. Après le plus long sera de réécrire l'UI (uniformisation, gestion i18n, suppression des abérances d'accès base, prise de tetes tapestry :P...)