J’ai enfin trouvé pourquoi j’avais, de temps en temps, des notifications doublées, ou plutôt persistantes alors qu’elles devraient avoir disparues une fois affichées une première fois.
C’est directement lié à la façon dont les sessions sont gérées avec PHP et parce que les appels de leurs fonctions de gestion peuvent être imbriqués de façon inattendue, surtout si on a des processus parallèles qui tournent (je pense en particulier à tout ce qui est servi via des requêtes Ajax). Je ne vais pas détailler ici ça ne sert à rien.
Par contre, côté système de notification : « C’est génial, faut tout refaire ! »
Ou pour dire ça autrement, on ne peut pas s’appuyer sur les variables de session pour stocker temporairement les notifications en vue de les afficher ensuite, c’est trop aléatoire.
Il faut donc coder ça autrement et j’envisage d’utiliser une nouvelle table dédiée pour faire ça, table qui ferait le lien entre la session déjà stockée en base de données et les notifications associées.
La structure prévue de la table dc_notices est la suivante[1] :
- notice_id : un identifiant unique
- ses_id : l’identifiant de la session à laquelle est rattachée la notification, à relier (n → 1) avec son semblable dans la table dc_session.
- type : type de notification (static[2], success, warning, error, message, …)
- ts : timestamp de la notification
- msg : contenu de la notification
- format : format du contenu (text par défaut, html, …)
- options : options spécifiques à la notification (avec/sans timestamp, …)
Le fonctionnement dans le reste de l’application ne changeant pas, il ne devrait pas y avoir de modifications à apporter en dehors de la façon de stocker/déstocker et de fournir les notifications en attente.
Une autre solution serait de reprendre le plugin notifyMe qui s’appuie sur les notifications possibles dans le navigateur, à condition que l’utilisateur les autorise et que Javascript soit actif. C’est peut-être trop réducteur d’un point de vue accessibilité.
Questions en suspens :
- Le type de notification static concerne l’ordre d’affichage, est-ce que ça ne devrait pas être plutôt dans les options de la notification ?
- Quid de la gestion de notice_id ? Incrémenté à l’infini ?
- Est-ce qu’il y a moyen de faire autrement ?
1 De Philippe -
C’est génial, faut tout refaire !
Pour t’aider un peu, je dirais dc_notice au singulier, comme on a dc_post, dc_comment, dc_user, etc.
Et pour notice_id, faut-il en garder beaucoup et combien de temps ? Tu pourrais “purger” la liste de temps en temps ?
2 De Franck -
Alors je note pour la forme au singulier, c’est plus cohérent en effet (même si on a
dc_permissions).Côté
notice_idla limite du côté de la base de données est 9223372036854775807 (soit 9,22 × 1018), je pense qu’on peut raisonnablement le laisser s’incrémenter tout seul :-p3 De Franck -
Ah sinon une fois une notification affichée, celle-ci est supprimée de la base, on ne garde pas ça.
Si c’est nécessaire il y a une autre table (
dc_log) qui permet de conserver trace des événements, j’ai d’ailleurs un plugin sur le feu qui permet de la gérer un peu plus finement…4 De RaphAstronome -
Ce serait aussi pas mal de supprimer de la base les notifs qui sont trop vieilles même si pas affichés. Cela permettrait d’éviter de ce retrouver avec des notifs jamais affichés qui s’accumulent pour une raison inconnue (principe de la fuite mémoire).
Sinon le nom de la table +1 pour le singulier.
Pour notice_id, pas de problème si usage de bigint.
5 De Franck -
RaphAstronome en effet, et je vais aussi m’occuper des sessions encore dans la base alors qu’elles ne devraient plus y figurer.
Ça devra faire l’objet de deux tâches de maintenance nouvelles.
Merci pour la suggestion !
Je note pour le reste (et oui c’est du
BIGINT).6 De Nicolas -
Cela me paraît bizarre de lier la table des notifications avec l’identifiant de session.
Je ne me rappelle pas précisément comment est codée la classe session dans dotclear mais l’identifiant de session peut changer. Dans certains cas ( longue session ou action critique,…) il est même conseillé de forcer ce changement.
Je comprends le besoin de lier cette table à ce qu’a vu l’utilisateur. Peut-être qu’on peut s’appuyer sur le même mécanisme que les forums pour afficher “les nouveaux messages depuis ma dernière visite”.
7 De Franck -
Bah les notifications sont déjà liées avec la session et enregistrées dans ses données, aucune raison de changer ce comportement surtout qu’on peut avoir plusieurs sessions concurrentes (plusieurs navigateurs ouverts) et ça permet de les différencier.