Vu que Marcant m'a signalé un petit bug dans la messagerie, j'en ai profité pour corriger les 2-3 choses dont il était question :

- Le bug de la messagerie concernait les liens "trop longs". C'est corrigé. Notez au passage que j'ai supprimé la coloration des messages des différents intervenants dans la discussion. C'était superflu, un peu perturbant (les couleurs ne sont pas conservées d'une conversation à l'autre) et avec peu d'intérêt.

- Les billets n'auront plus une bordure sur la page d'accueil s'ils sont en tête de liste (ou en fin de liste, ça dépend si on considère que c'est une bordure haute ou une bordure basse). Autrement formulé : il n'y aura pas de ligne grisâtre de séparation entre un billet et "autre chose qu'un billet".

- Comme Tchou l'a suggéré, le "teasing" du billet (tel qu'affiché dans les listes ou sur l'accueil) est maintenant affiché en tête de thread si la discussion est liée à un billet. Par ex, dans le topic 2048, ça permet de cliquer sur le lien du jeu sans page intermédiaire.

- Le flux RSS des discussions liste maintenant les derniers messages. Le titre de l'objet est le titre de la discussion. Le markup est aussi nettoyé (simplement remplacé par du vide, ça fait bizarre dans le cadre d'une quote, par contre...).

Je me demande si une page listant les derniers messages postés dans les discussions ne seraient pas intéressantes. J'ai parfois un peu de mal à retrouver une discussion dans laquelle j'ai lu un message récemment.

[Edité : je teste l'affichage de tous les intervenants à une discussion (sur la page d'accueil) au lieu de la limite artificielle à 5.... Des retours ?]

Une petite chose tant qu'on y est, concernant la messagerie, c'est pas possible d'avoir un mail lorsqu'on reçoit un nouveau message ? Ça serait bien pratique

GuybrushIl me semblait que les lecteurs RSS se basaient sur la date ? Cette date est mise à jour afin de refléter la date du dernier message, n'est-ce pas suffisant ? Si ce n'est pas le cas, comment le lecteur RSS fait-il pour reconnaître les différents éléments ? Sur base du titre, je suppose.... ? Ce serait un choix bien curieux....

Mon cerveau a trop fumé hier. Ils se basent sur les GUID et dans ce cas ils sont différents.

MaloukUne petite chose tant qu'on y est, concernant la messagerie, c'est pas possible d'avoir un mail lorsqu'on reçoit un nouveau message ? Ça serait bien pratique

J'ai envie de répondre "non", parce que j'ai volontairement zappé la feature (pour le forum aussi) lors de la v4. Cela aurait pu se mettre sous forme d'option d'une conversation en cours, mais vu le nouveau mécanisme de conversations, on serait probablement spammé d'avertissement. On aurait pu ne signaler que les nouvelles conversations, mais ça perd son intérêt. On pourrait par contre faire une sorte de récapitulatif à intervalles réguliers, par exemple une fois par jour ou une fois par semaine, un e-mail signalant qu'il y a des messages non-lus... Mais dans ce cas, j'aimerai profiter du système pour récapituler aussi d'autres aspects du site (nouveaux messages sur le forum, nouveaux billets, ... ?)

RoidelapluieMon cerveau a trop fumé hier. Ils se basent sur les GUID et dans ce cas ils sont différents.

Donc il m'aurait suffit de changer le GUID de chaque objet par un hash du message, par exemple, au lieu du titre du thread... Bon bah... tant pis Au moins, c'est fait "autrement"...

Guybrush

RoidelapluieMon cerveau a trop fumé hier. Ils se basent sur les GUID et dans ce cas ils sont différents.

Donc il m'aurait suffit de changer le GUID de chaque objet par un hash du message, par exemple, au lieu du titre du thread... Bon bah... tant pis Au moins, c'est fait "autrement"...

Aaah ce n'était pas le même hier :)

Au moins on ne rate pas de messages avec le flux rss maintenant ;)

Si c'est bon comme c'est, ça me va

A tout hasard, est-ce que vous pensez que c'est utile de proposer d'autres types de flux, genre Atom ? J'ai jamais utilisé ce truc, je sais juste que le framework prévu dans Django permet de facilement passer du RSS à Atom (ou de le compléter). Je n'ai même aucune idée de ce que ça change du point de vue de l'utilisateur

Alors, je venais sortir un truc concernant Django, ça me fait une transition parfaite.

J'écrivais un billet, j'appuie sur la div smiley pour faire mon choix (dans la date ... le smiley), et là, la div se charge, mais les images mettent un temps fou à arriver ... typiquement le même temps fou avant que la connection se fasse dans les cas de relançage du script python que l'on expérimente parfois. D'où ma question : est-ce que Django gère son propre serveur http (tu as fait comme ça ?), et si oui, pourquoi ne pas gérer ta donnée statique autrement (via un autre serveur qui n'analyse pas pour vérifier si smiley_deconne.gif n'est pas du python ... ou apparemment tu peux configurer django dans apache, et balancer tout fichier statique sans passer par le mod python), pour pas surcharger le pauvre pépère ?

Rappel : j'ai jamais fait de django plus loin qu'un hello world ! :)

Django propose, pour le développement, un petit serveur intégré bien pratique. Quand on déploie, on peut encore l'utiliser (en contournant les limitations qui poussent à éviter de l'utiliser en production). Je crois qu'il doit aussi être possible d'utiliser Django (même en mod_cgi) pour servir du contenu statique.

Sur Lexpage, tout ce qui est accessible via /static/ est catché par un .htaccess qui redirige vers la vraie arborescence, qui est elle-même servie par Apache (sans aucune interprétation, aucune - ce qui me permet de stocker vos avatars directement là-dedans sans prendre de risque de sécurité). Django ne s'occupe que du reste : ce qui n'est ni redirigé par .htaccess, ni existant dans l'arborescence (par exemple, la v3 ou mes autres "petits sites"). Il n'y a donc pas de délai supplémentaire pour servir du contenu statique. Si c'est lent, c'est OVH

Transformer les smileys en CSS Sprites ?

S'il y avait des milliers d'images à afficher, oui, pourquoi pas, même si je trouve l'intérêt limité vu les performances qu'on a actuellement (que ça soit pour le transfert, le cache ou l'affichage). Je sais que ça diminue les communications et certains traitement "bas niveau", mais d'un autre coté, actuellement tout se passe via la même connexion TCP, il y a relativement peu d'images, il n'y a pas de problème de performances liés à cet aspect là, et surtout, ça évite d'avoir à ajouter du traitement coté client (ayons une petite pensée pour les mobiles qui n'ont pas 1.5 ghz sous le capot ).

Pour les smileys, l'affichage actuel est quand même limite "suédée", avec chaque image qui arrive les unes après les autres.

Cf. mon lien sur Glue en page 3, pour faire des sprites en 1 ligne de commande. Ca te génère une image à partir d'un répertoire d'image et le css correspondant, qui contient dans son nom le nom de l'image originelle. Difficile de faire plus simple.