On 09/19/2012 10:21 AM, Tony Chemit wrote:
il faut remettre en cause le système actuel :(.
Encore ? mais décidément, on dirait que tout est à refaire :-/
Pour moi l'idée serait - arrêter l'écriture d'un fichier xml sur le serveur (en plus y'a pas vraiment d'intérête d'avoir un autre type de storage que la bd)...
Oui, voir plus bas.
- créer une table évènement sur sondage et y enregistrer à chaque modification sur un sondage l'action réalisée
Je sais pas si je vais être clair, mais voici mon point de vue. Si on fait ça, il me semble que la bonne approche serait que cette partie du modèle soit le modèle lui-même (pour éviter de dupliquer l'info). C'est à dire que pour un poll, on stocke les actions de voter, les actions de commenter, les actions d'ajouter un choix comme autant d'entités. Exactement comme le patron de conception commande. C'est comme dans un logiciel de compta. On ne stocke pas pour un compte le montant en € qu'il y a dessus (Lima exclus ;-)). Par contre on attache à ce compte un ensemble d'opération, qui en les rejouant toute depuis la création du compte donne le montant actuel se trouvant sur le compte. Doit y avoir des inconvénients à cette approche mais j'en vois pas. Vu qu'elle est plus structurante que le modèle actuel.
- on génère à la volée un flux rss quand un utilisateur le demande et on y met uniquement ce dont il a le droit de voir.
Les formats "RSS" sont, selon moi, dépréciés. Le format Atom me paraît être plus d'avenir. Je pense aussi qu'il ne faut pas stocker ces fichiers sur le serveur car ils doivent être générées. Il faut les percevoir comme une « vue » obtenue par un rendu, comme une page Web. c'est juste que c'est du Atom, pas du HTML. D'ailleurs, si on exploite Shiro. Une piste pour générer ce flux Atom serait, plutôt que d'utiliser une lib spécialisée Atom/RSS, de simplement écrire une JSP, suffit de baliser en Atom plutôt qu'en HTML. L'avantage de cette approche est que cela nous permettrait d'utiliser la taglib Shiro, et donc de génerer un flux qui ne contient que les informations que l'utilisateur a le droit de voir. Ce serait peut être plus clair qu'avec du code Shiro + du code d'une lib Atom entrelacé en Java. -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28