Concernant la gestion des flux rss
Hello, Pour pouvoir traiter de manière satisfaisante l'anomalie 805 [1], il faut remettre en cause le système actuel :(. 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)... - créer une table évènement sur sondage et y enregistrer à chaque modification sur un sondage l'action réalisée - 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. Reste juste à savoir ce qu'on fait pour les sondages existants lors de la migration, (pour moi on fait rien et on indique que le système de flux a été réinitialisée en version 1.5 pour amélioration...) A vos avis, tony. [1] http://chorem.org/issues/805 -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 19/09/2012 10:21, Tony Chemit a écrit :
Hello,
Pour pouvoir traiter de manière satisfaisante l'anomalie 805 [1], il faut remettre en cause le système actuel :(.
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)... - créer une table évènement sur sondage et y enregistrer à chaque modification sur un sondage l'action réalisée - 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.
Très bonne idée
Reste juste à savoir ce qu'on fait pour les sondages existants lors de la migration, (pour moi on fait rien et on indique que le système de flux a été réinitialisée en version 1.5 pour amélioration...)
A mon avis, c'est mieux de récupérer les vielles données, mais si on peut pas, ben on peut pas (on peut peut-être laisser l'ancien système pour les sondages commencés avant la migration, mais ça risque de créer une verrue dans le code). Jean
On Wed, 19 Sep 2012 10:41:11 +0200 Jean Couteau <couteau@codelutin.com> wrote:
Le 19/09/2012 10:21, Tony Chemit a écrit :
Hello,
Pour pouvoir traiter de manière satisfaisante l'anomalie 805 [1], il faut remettre en cause le système actuel :(.
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)... - créer une table évènement sur sondage et y enregistrer à chaque modification sur un sondage l'action réalisée - 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.
Très bonne idée
Reste juste à savoir ce qu'on fait pour les sondages existants lors de la migration, (pour moi on fait rien et on indique que le système de flux a été réinitialisée en version 1.5 pour amélioration...)
A mon avis, c'est mieux de récupérer les vielles données, mais si on peut pas, ben on peut pas (on peut peut-être laisser l'ancien système pour les sondages commencés avant la migration, mais ça risque de créer une verrue dans le code).
c'est pas que ça créée une verrue dans le code mais un gros trou de sécu car on dit que les votes sont non visibles mais au final on peut tout voir... Il faut voir ce qu'on peut reprendre des flux à moindre coût, sur les sondages sans restrictions on devrait pourvoir faire des trucs assez facilement, et on pourrait par example juste supprimer les flux des sondages restreints Je suis pastrop pour laisser cohabiter deux systèmes en même temps car sinon on se le trainer jusqu'à la nuit des temps...
Jean
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 19/09/2012 11:03, Tony Chemit a écrit :
Je suis pastrop pour laisser cohabiter deux systèmes en même temps car sinon on se le trainer jusqu'à la nuit des temps...
C'était ça l'idée de ma verrue... -- Jean Couteau - Code Lutin - www.codelutin.com 12 Avenue Jules Verne, 44230 Saint-Sébastien-Sur-Loire Tel : 02.40.50.29.28 - Port : 06.68.07.29.29
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
participants (3)
-
Brendan Le Ny -
Jean Couteau -
Tony Chemit