Brainstorming : un truc me titille sur les MP dans les forums !

[Zecat]

En prenant une feuille blanche et en ecrivant en titre MP puis en commençant a coucher quelques idées ... je tombe sur un truc ou mes neurones dérappent ... z'essplique :

- On peut poser comme postulat que créer un MP revient à créer dans un forum special que l'on va nommer MP un topic avec comme seuls lecteurs/editeurs le posteur et le destinataire (simplifions en disant LE destinataire). A partir de ce moment seuls ces deux membres ont accès a ce topic pour y poster des reponses ... Et donc il n'y a bien sur pas redondance (les deux ne faisant qu'accèder à la même information, même si elle leur est présentée comme appartement à leur messagerie privée individuelle). Le reste étant de la broutille consistant a flaguer qui a lu ou pas lu etc ...

- La ou je decroche, c'est quand je vois que le nb de messages privés (ou plus precisement le nombre de reponse privées) est la plupart du temps limité et que l'on doit regulièrement purger les plus vieux messages (c'est le cas de wri). En effet, si on prend un MP1 donné, enchangé entre pseudo A et pseudo B ... et que pseudo A à sa boite de MP pleine ... il va dire "je supprime ces 10 derniers messages reçus" ... ok très bien ... Mais dans le même temps cette suppression n'a pas à avoir d'impact sur l'état de la MP du pseudo B, on est bien d'accord ... et donc il continuera a voir ces 10 messages ...

Donc j'en conclue que les MP dans les forums sont codés en mode "je duplique l'info en autant de destinataires du MP" ou alors que la fonction "je supprime 10 reponses" ne supprime en fait rien a part de l'accès en affichage ? Ou autre hypothèse, les messages ne disparaissent réellement de la bdd que lorsque pseudo A et Pseudo B l'ont supprimé ? Un truc m'échappe ...

Si certains qui connaissent les entrailles des gros forums ont une explications sur ce qui apparait comme un trucs pas clair (en tout cas pour moi).

 

[finstreet]

me souviens plus trop de comment c'est fait chez moi. Ca date. Mais je crois que j'ai fait un truc du style

- Message
- Statut Expéditeur
- Statut Receveur

 

[Marie-Aude]

Je pense que les messages sont traités différement en base, notamment à cause de la fonction d'adressage

Cela dit, en général, la limite de la boite de réception est un "nombre de message" qui peut être contourné en créant des dossiers. Donc ça sent plutôt sa limitation de taille de champs sérialisé permettant de stocker les index des messages

 

[Zecat]

ESt ce que ca vous parait une aberration si je considère la mise en place tout simplement de "topics privés" (donc du coup 90 % du taf est déjà fait et pas besoin de nouvelles tables).

Scénario :

- En interne j'ai un forum nommé "MP" accessible par personne bien sur (total invisble).

- Un pseudo A poste un MP (donc a destination de pseudo B) (interface similaire a celle qu'on connait) : ca crée le topic numero 12345 dans la table topic (avec MP comme forum de rattachement) et ca crée le post numero 45678 dans la table des posts avec 12345 comme topic de rattachement. Le topic a un champs rempli de plus par rapport a un topic normal : le destinataire. Donc j'ai dans le topic les infos pseudo A et pseudo B.

- Le pseudo B est informé qu'il a recu un MP (pas de bleme on a l'info) et le post 45678 lui est présenté dans sa MP (interface similaire à ce qu'on connait). Il poste une reponse ... il ne fait en fait que répondre à un topic comme il le ferait dans les forum publics ...

etc etc etc

Du coup on tombe bien sur la notion de topic privé tout simplement ...

La MP de chaque membre n'étant que la liste des topics dans lesquels il est posteur/destinaire ... Ca me parait tellement (trop) simple que j'ai peur de me planter quelque part dan sle raisonnement ... Parce que si y a pas de loup, ma MP ets elle pliée en une après midi

 

[finstreet]

c merdouilleux car ce n'est pas la même chose, ca n'a pas le même objectif et ca n'a pas les mêmes fonctionnalités

 

[Zecat]

Pas les mêmes fonctionnalités ?

Un titre
Un message
des outils de citations, bbcode , smiley

je vois pas la différence ...

Tout le reste n'est qu'un question de presentation des infos (via topic dans le forum et directement les post dans MP) mais sinon techniquement je vosi pas ou est la différence ...

D'alleurs, en regardant de plus près et constatant que l'on peut editer un MP tant que pas lu par le destinataire, j'en viens a penser que cette lecture ne fait que poser un flag "plus editable par emmetteur" et que donc c'est ainsi que procèdent les grands forum ...

Mais la quelqu'un qui connait le code de PhPBB ou FluxBB sur le bout des doigts pourrait confirmer ou infirmer ...

En plus je vois un interet majeur a cette approche (fut elle hérétique ... Hum le nombre de trucs hérétiques que j'ai pu faire dan sma vie et qui finalement le sont devenus un peu moins ... ) : la facilité pour présenter une discussion en MP sous forme de son topic complet et pas tous MP de toutes origines mélangés ... Fonctionnalité qui ne semble pas possible dans wri mais j'ai peut etre pas vu le lien qui permettrait d'isoler tout un fil de discussion en MP ...

 

[finstreet]

les alertes, l'édition ou la non édition, la suppression ou non

Sinon sur un phpBB, c'est bien différent vu que c'est géré par deux tables différentes

 

[Zecat]

les alertes, l'edition etc ... ce n'est que de l'interface d'habillage autour mais sur le fond ...

 

[finstreet]

ben sur le fond, ce n'est pas la même chose. Le truc essentiel sur un forum, c'est bien les topics non ? Si tu t'amuses à augmenter la taille de ta table topic avec des messages privées, ca va vite devenir un truc énorme qui va tout te ralentir

 

[Zecat]

Bon je viens d'aller voir en detail la MP de phpBB (wri) et le constat est simple :

La boite de reception : liste des post (sous entendu dans le forum MP) dont destinataire est MOI classé par timestamp décroissant. et qu'il y en ait 100 ou 10000 on s'en tappe, c'est le systeme de pagination qui gere le truc.

La boite d'envoi : liste des poste dont emmeteur est MOI et pas encore flagués commes lus par DESTINATIRE.

Les messages envoyés : idem mais flagués

BOUTON NOUVEAU : creation d'un nouveau topic et du premier post

BOUTON REPONDRE : ajout d'un nouveau post dans le topic correspont

PS : j ai dit une bêtise dans topic d'avant ... il y a bien la revue dans les MP permettant de suivre tout le fil du topic (simplement présenté ordre timestamp decroissant).

Bref je vais le jouer comme cela ... ca me parait tellement plus cohérent que d'ajouter une nouvelle table pour les MP ... et pusi ca ouvre des portes : comme par exemple permettre en MP de demander une présentation de type MP ou une présentation de type Forum !

 

[Zecat]

Bon on va attendre d'autres avis et éclairages demain ... de toutefaçon la c'est dodo donc ca va pas coder cette nuit :wink:

Edit : En regardant de plus prêt l'affichage de la "revue" dans les MP on voit que c'est une div deployable et que donc des quon affiche un MP on a sous la main la totalité du fil. Ca accréditerait l'hypothèse que pour les MP les forums font l'impasse du decoupage TOPIC -> POST au profit d'une seule table avec un champs contenant tous les messages d'un fil (posant comme postulats - pas faux - a) qu'un fil ne fera jamais 3000 messages comme ca peut etre le cas dans les topics ... et b) qu'il n'y a pas a gérer le risque de multiples accès concurents en ecriture au sein d'un fil comme c'est le cas au sein d'un topic ... justifiant la table post pour eliminer cette source de conflit d'accès ...).

Hum ... je vais re brainstormer demain :roll:

 

[Zecat]

Bon ben finalement je vais opter pour un compromis :

Vu que ma table topic c'est déjà une structure 5 champs :

numero de topic (auto increment)
numero de forum
datas (texte) : ou je fourre ce que je veux
posteurs (texte)
timestamp

il va me suffir de stocker les "post MP"dans mon champs 'topic datas' tout simplement et comme les posts c'est dejà aussi un seul et unique champ "datas" ca va juste être un deroutage vers le champs du topic au lien du fichier post et un empilement avec un séparateur pour le future explode qui ira bien :wink:

Donc au final :
- je garde l'idée du forum invisible/virtuel "MP"
- Je n'ajoute pas de nouvelle table :wink: (radin le chat ... enfin flemmard surtout :!: )

 

[Dolph]

Comme le dis Fin', l'important et de ne pas pénaliser la table qui sert à tous, en l'occurence, celle des topics.
Il est donc préférable, même si tu gères les mp comme un fil de discussion fermé, d'ailleurs l'idée est bonne, de crée une table dédiée.

 

[Zecat]

Ok manifestement le fait d'alourdir les tables topics/post semble une préocupation et comme vous maitrisez Mysql mieux que moi, je vais me ranger à vos avis ... en simplement clonant pour les MP les deux tables topics et post avec deux nouvelles tables : topics_MP et post_MP ... Comme cela je peux utiliser toutes mes routines génériques simplement en positionnant une variable de contexte ...

Exemple avec la routine forum_topic_get_datas.php

<?php
$sql_base_table="forum_topics";

$sql_champ="numero";
$sql_numero=intval($topic_numero);
$sql_query = "SELECT * FROM ".$sql_base_table." WHERE ".$sql_champ." = ".$sql_numero." ";
$sql_result_query = mysql_query($sql_query) or die("Query failed");
$datas="";
if($sql_row = mysql_fetch_array($sql_result_query)) { $data =  $sql_row['datas']; }
$sql_tab_topic=array();
$sql_tab_topic=explode("|", $datas);
?>

et derrière j'ai une routine : forum_topic_data_to_variables qui charge les 15 ou 20 lignes du tableau dans des variables nommées plus faciles à manipuler. La même logique dans l'autre sens (forum_topic_variables_to_datas et forum_topic_put_datas ...). L'accès aux infos d'un topic se resume donc à :

1 - charger le numero de topic
2 - include forum_topic_get_datas.php
3 - include forum_topic_data_to_variables (*)

(*) Les deux sont séparés parce que bien souvent ne n'ai pas besoin d'avoir les variables mais juste un accès à une valeur dans le tableau. En fait même le explode est séparé mais je l'ai mis la pour la compréhension du topic ici (en effet souvent meme pas besoin d'un explode par exemple pour tester une info avec un simple strpos dans $datas ...

Et donc il me suffira de modifier le code ainsi :

<?php
$sql_base_table="forum_topics".$forum_contexte; // <<<<<<<<<<<<<<<<<< flemmard total !

$sql_champ="numero";
$sql_numero=intval($topic_numero);
$sql_query = "SELECT * FROM ".$sql_base_table." WHERE ".$sql_champ." = ".$sql_numero." ";
$sql_result_query = mysql_query($sql_query) or die("Query failed");
$datas="";
if($sql_row = mysql_fetch_array($sql_result_query)) { $data =  $sql_row['datas']; }
$sql_tab_topic=array();
$sql_tab_topic=explode("|", $datas);
?>

et la chaine de traitement devenant :

0- $forum_contexte="mp"; // $forum_contexte vide si forum ... et rempli si mp
1 - charger le numero de topic
2 - include forum_topic_get_datas.php
3 - include forum_topic_data_to_variables (*)

Du coup objectif atteint :

- rien a réécrire
- identité absolu de traitement topic forum et MP (même routines utilisées)
- non alourdissement des tables topics et post du forum

ca me va, c'est un compromis supportable :wink:

 

[Zecat]

Question a deux balles : dans PhpMyAdmin est ce qu'il existe une fonction permettant de dupliquer la structure d'une table en indiquant un nouveau nom ou est ce qu'il faut se fader la resaisie des champs ? (je vais passer pour une grosse flemmasse :mrgreen: )

Edit : j'ai trouvé ... dans Operations ... :wink: La au moins je suis sur du clonage (pas de risque de "fote" de frappe)

 

[UsagiYojimbo]

Tu fais un export de la structure de ta table, tu reprends le code de génération de ta table en faisant les changements qui t'intéressent et tu recolle le bout de SQL ainsi modifié dans la console de PHPMyadmin.

 

[Zecat]

Tu fais un export de la structure de ta table, tu reprends le code de génération de ta table en faisant les changements qui t'intéressent et tu recolle le bout de SQL ainsi modifié dans la console de PHPMyadmin.

Nan nan dans Operation tu indiques juste le nouveau nom et tu dupliques (avec ou sans transfert des datas et avec ou sans conservation de l'autoincrement). 2 s. par table ! ca a automatiquement executé :

CREATE TABLE `xxxxxxxx`.`forumpostsmp` (
`numero` mediumint( 9 ) NOT NULL AUTO_INCREMENT ,
`numtopic` mediumint( 9 ) NOT NULL ,
`datas` text NOT NULL ,
`datasrech` text NOT NULL ,
KEY `numero` ( `numero` ) 
) ENGINE = MYISAM DEFAULT CHARSET = latin1;

 

[UsagiYojimbo]

En fait je n'utilise plus PHPMyadmin depuis des lustres

 

[Dolph]

Tu utilises quoi ?

 

[UsagiYojimbo]

HeidiSQL il y a encore quelques mois, maintenant exclusivement la version community de SQLYog. Ne serait-ce que pour les soucis du à des imports de fichiers trop lourds, c'est le top.

 

[Zecat]

Et voila ... premiers effets immediats de cette stratégie ...

Un nouveau forum est apparu dans les forum prives (tout en bas) : "Messages privés" et du coup avant même d'avoir codé les MP en tant que tel, chaque membre accède a son espace privé comme a un forum classique et il dispose des fonctions speciales si il est le créateur d'une discussion privé (vérrouiller, epingler ...) :wink:

Montre en main 15 mn (il a juste fallu ajouter "Destinataires : toto, titi, tata" ) ! Comme dirait segolène, je cultive la "faignantude" :mrgreen:

 

[Leonick]

Ne serait-ce que pour les soucis du à des imports de fichiers trop lourds, c'est le top.

les imports de gros fichiers se font largement plus vite en ligne de commande (via putty, par exemple)

 

[Dharius]

J'aime bien moi ton idée Zecat d'utiliser la même base de donnée et prog...
Je me dis mêm que j'aurais pu y penser avant.

Sinon pour la problématique de départ ajoute 2 champs genre
-is_supprimer_by_expediteur
-is_supprimer_by_destinataire

Tu met simplement à "1" le champs si par exemple le destinataire veut supprimer le message. Tu fais la requête pour que seuls les messages à "0" apparaissent. ET tu peux éventuellement pour pas alourdir la base inutilement supprimer définitivement le fil si les 2 sont à "1"...

 

[Zecat]

J'aime bien moi ton idée Zecat d'utiliser la même base de donnée et prog...
Je me dis mêm que j'aurais pu y penser avant.

Sinon pour la problématique de départ ajoute 2 champs genre
-is_supprimer_by_expediteur
-is_supprimer_by_destinataire

:mrgreen:

mdr c'est exactement ce que j'ai fais !

 

[Zecat]

Effet de bord interessant dont je viens de m'apercevoir en le mettant en place : comme les MP sont en fait des post dans des topics (simplement déroutés vers une autre table), ils disposent de toute sle sfonctionalités des topics/post (epingler, verrouiller et aussi les reco et le signalement - utile pour signaler en un clic un mp spammy).

Bon la le signalement ne concernera que l'admin par définition puisque les modos n'ont aucun accès aux MP des membres bien évidemment ... Bref vu le temps gagné et ce genre de trucs, je me félicite déjà de cette stratégie ... et plus généralement de l'approche "ecrire son propre forum" qui offre une souplesse de choix sans commune mesure avec l'adoption d'un standard du marché ...

 

[finstreet]

J'aime bien moi ton idée Zecat d'utiliser la même base de donnée et prog...
Je me dis mêm que j'aurais pu y penser avant.

Sinon pour la problématique de départ ajoute 2 champs genre
-is_supprimer_by_expediteur
-is_supprimer_by_destinataire

:mrgreen:

mdr c'est exactement ce que j'ai fais !

Oui enfin ca je l'ai dis y'a 10 posts Statut Expéditeur c'est pas pour écrire dedans s'il est joyeux ou triste C'estp our écrire si l'expéditeur a archivé, supprimé, lu , etc

 

[Zecat]

Bon ben on est tous d'accord alors :lol:

 

[Julia41]

Ton idée n'est pas trop bête, mais pour moi ça doit être "plus simple".
En SQL ça doit être juste : sender / receiver / message
(après tu rajoutes "date" et "read/unread").

Là au niveau de celle d'un site que je gère, je suis en train de tenter une "conversation" (style la nouvelle mailbox de facebook) mais du coup je dois empêcher la suppression/édition.

Bref, en tout cas ton idée n'est pas trop bête, mais bon, je pense qu'un truc dédié est un peu plus propre/sérieux et demandera très certainement par la suite moins de temps de gestion car ce sera du code à toi et plus simple (pleins de trucs ne servent pas dans un "topic" pour une mailbox).

 

[Zecat]

heu julia ... c'est QUE du code à moi :mrgreen:

cf https://www.webrankinfo.com/forum/coder-son-forum-utiliser-forum-standard-p ... 42315.html

(pleins de trucs ne servent pas dans un "topic" pour une mailbox).

Heu lesquels ?

Et ce qui sert pas il suffit de le masqer si $contexte == "mp" ... tout en l'ayant a dispo immédiate si un jour finalement il sert ... :wink:

 

[Julia41]

ça c'est la faute à ton avatar et ton "phprank 1"
A mon niveau c'est surtout que ça va te faire un fichier encore plus gros (ton fichier qui affiche le forum) pour au final une fonction qui n'a rien à voir.
Bon, après bien sûr ça reste jouable, mais bon, je trouve que c'est une mauvaise habitude d'avoir un seul et unique fichier qui fait tout (ça c'est perso bien sûr).

 

[Zecat]

Si tu lis bien, j'ai déporté les MP dans deux tables clones de topic et post (stricts clones mais tables séparées) et donc pas d'alourdissement des tables inutilement tout en utilisant strictement le meme code a toutes les etapes (lecture record et ecriture). Juste une changement de nom de table selon valeur d'une variable priocésant le contexte (mp ou forum) ...

Mais en interne pour moi un MP c'est un topic et les reponse se sont des posts ... Ensuite ca sera total transparent pour le user qui lui va voir la meme interface que celle de phpBB ... plus la possibilité de visualiser ses MPP sous forme d'un forum privé forme topic > post ... :wink: (d'ailleur cette seconde partie est déja visible sur le site en developpement ... - le dernier forum privé tout en bas :wink: )

 

[Julia41]

Oui, je ne parlais pas des tables, mais bien du fichiers du forum (fichier php donc).
Bon, ça reste jouable, c'est juste que "j'aime pas" (bon, j'ai pas donné trop d'argument hein ).

 

[Zecat]

je pige pas trop ce que tu veux dire. regarde j'ai mis en rouge ce que ca a ajouté à une dizaine de scrip php. Exemple le script topic_get_datas :

------------------------------------------------------------------
$sql_base_table="forum_topics".$contexte ;
$sql_champ="numero";
$sql_numero=intval($topic_numero);
$sql_query = "SELECT * FROM ".$sql_base_table." WHERE ".$sql_champ." = ".$sql_numero." ";
$sql_result_query = mysql_query($sql_query) or die("Query failed");

$datas="";
if($sql_row = mysql_fetch_array($sql_result_query)) { $datas = $sql_row['datas']; }

$sql_tab_topic=array();
$sql_tab_topic=explode("|", $data);
-----------------------------------------------------------------------------

Coté alourdissement des fichier php, je peux pas faire moins ... selon que $contexte contient "mp" ou est vide on va lire la table forum_topics ou la table forum_topicsmp. Ensuite le format a l'intérieur du champs datas est identique à la virgule près dans une table et l'autre ...