Bonjour à tous, Je suis confronté à un sérieux mal de crâne concernant le modèle de Pollen 1.3. Bien trop complexe pour être exploitable et maintenable (comme les services métiers). Je pense qu'il serait préférable, et moins couteux en temps de tout refaire le module business de l'application en supprimant au passage les DTO. Il faudra dans un deuxième temps adapté/amélioré l'UI pour coller au nouveau modèle, ce qui ne devrait pas être compliqué car ce dernier est mieux adapté aux besoins. Donc, la v1.3 ne verra jamais le jour, je pense directement partir sur un nouveau modèle donc une v2.0. Ceci dit, les modèles risquent d'être incompatible et donc un script de migration bien trop complexe à mettre en œuvre. Le mieux serait d'utiliser le moteur d'import/export XML pour passer du modèle 1.2 actuel au 2.0. Cordialement, Florian Desbois Code Lutin Ci-joint une première ébauche du modèle de la v2.0. Petite description du modèle : ------------------------------ Rappel : UId = identifiant unique permettant de voter ou d'identifier un sondage. - Côté sondage (Poll) rien ne change, les attributs restent les mêmes ainsi que le lien vers les choix, les commentaires, les résultats et les règles de notifications (PreventRule). - Côté vote et personne (PollAccount), il y a pas mal de changement. Un PollAccount devient soit une liste, soit une personne. PollAccount *********** Le PollAccount représente un votant (ou groupe de votants) pour un sondage donné. Un PollAccount ne sera JAMAIS lié à plusieurs sondages. Le PollAccount est utilisé dans deux contextes différents : Liste de favoris d'un utilisateur enregistré ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - L'utilisateur est lié à un ou plusieurs PollAccount listes (list = true). Chaque liste représente une liste de favoris contenant des pollAccount (l'UId de chacun d'eux ne sera défini que dans le cadre du sondage). La création d'un sondage avec une liste de favoris copiera cette dernière pour la lier au sondage et générer les UId nécessaires aux votes. relation UserAccount -> * PollAccount - L'utilisateur est lié à plusieurs PollAccount personnes (list = false) qui correspondent à des instances de lui même pour chaque sondage participé ou créé. relation PollAccount -> 1 UserAccount Compte de vote pour un sondage (restreint ou non) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Cas sondage Libre : Le sondage est lié à plusieurs PollAccount personnes (list = false), chaque PollAccount correspond à un votant et son vote. Le sondage ne contiendra que des gens qui ont réellement votés (dateVote != null) - Cas sondage Restreint : Le sondage est lié à plusieurs PollAccount personnes (list = false) bien définis. Chaque personne aura déjà voté ou non. Seul le créateur du sondage pourra rajouter ou modifier l'ensemble des PollAccount liés au sondage. - Cas sondage Par groupe : Le sondage est lié à plusieurs PollAccount listes (list = true) contenant chacune un ensemble de PollAccount personnes. Il sera ainsi possible de sauver le résultat des votes par groupe. Créateur du sondage ******************* Le créateur du sondage est lui même un PollAccount particulier (admin = true). Idée : Il pourrait être intéressant pour un sondage restreint d'avoir l'option dans l'UI: "m'inclure automatiquement à la liste de votants". Si cette case est coché, le créateur devra voter, sinon il ne sera pas nécessaire de l'inclure dans le dépouillement. Sinon gérer le test sur les emails dans la liste et celui du créateur pour l'inclure au vote en tant que votant. Prévoir un nouvel attribut dans PollAccount ? Cas de l'anonymat ***************** - Les propriétés de PollAccount : email, name et userAccount sont mises à null + booléen anonymous passé à true -> impossible de retrouver la personne qui a voté. - La seule garantie d'unicité du vote est l'UId du PollAccount. Il est donc préférable de l'afficher à l'utilisateur au moment de son vote anonyme pour qu'il puisse le modifier. Pour un sondage restreint/par groupes il possédera déjà l'UId depuis le mail qu'il aura reçu. Résultats ********* - Le moteur de dépouillement (voteCounting) sera gardé tel quel. Le nouveau business communiquera avec lui avec la couche DTO/bean du module voteCounting. - Les résultats continus seront désormais enregistrables dans le modèle.
Le mardi 23 mars 2010 à 12:12 +0100, Florian Desbois a écrit :
Bonjour à tous,
Je suis confronté à un sérieux mal de crâne concernant le modèle de Pollen 1.3. Bien trop complexe pour être exploitable et maintenable (comme les services métiers).
Ci-joint l'ancien modèle 1.2 dans toute sa complexité.
Le mardi 23 mars 2010 à 12:12 +0100, Florian Desbois a écrit :
Bonjour à tous,
Je suis confronté à un sérieux mal de crâne concernant le modèle de Pollen 1.3. Bien trop complexe pour être exploitable et maintenable (comme les services métiers).
Ci-joint l'ancien modèle 1.2 dans toute sa complexité (avec la pièce jointe cette fois ci)
Le 23/03/2010 12:12, Florian Desbois a écrit :
Donc, la v1.3 ne verra jamais le jour, je pense directement partir sur un nouveau modèle donc une v2.0. Ceci dit, les modèles risquent d'être incompatible et donc un script de migration bien trop complexe à mettre en œuvre. Le mieux serait d'utiliser le moteur d'import/export XML pour passer du modèle 1.2 actuel au 2.0.
Ça me va. En faisant bien attention à conserver toutes les données. (ou bien documenter cette incompatibilité).
Ci-joint une première ébauche du modèle de la v2.0.
J'ai lu rapidement, mais tu as l'air d'avoir pensé à tout. -- Éric <chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
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' ? 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 ? Je n'arrive pas a voir a quoi correspond le lien 'person' sur PollAccount 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 De la meme facon pour le vote condorcet il serait bien d'avoir les resultats des combats participant par participant (demande d'ouvaton) 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 ? (comment gere tu les images dans ton modele ? description contient l'uri de l'image ?) 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 :)) 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. 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) 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 :) -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
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...)
On Tue, 23 Mar 2010 17:36:20 +0100 Florian Desbois <fdesbois@codelutin.com> wrote:
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:
...
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.
Je ne suis pas forcement fan, il faudrait qu'on en discute de vive voix pour me convaincre :) -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
participants (3)
-
Benjamin POUSSIN -
Eric Chatellier -
Florian Desbois