[F] Balises incorrectes et backslashes - Page 1

Ce sujet est issu d'une discussion ayant dérivé sur deux thèmes distincts. Pour vous rendre sur le sujet d'origine, suivez ce lien.

---

Yoshi Noir (./1793) :
Je sais pas comment tu te débrouilles pour échapper les caractères, mais je rencontre à nouveau le bug de l'antislash qui s'ajoute devant le crochet ouvrant d'une balise quand on édite un post et c'est positivement casse-couilles quand on veut corriger la mise en forme à la main -('')-

./1792 : corrigé, merci.

./1793 : oui, je n'ai pas encore trouvé de solution satisfaisante pour ce problème là, et c'est surtout lié à la façon dont sont sauvegardés les posts en BDD. Pour faire simple, quand on édite un message tout ce qui ressemble à une balise mais n'a pas pu être pris en compte (parce qu'il manquait la balise fermante correspondante par exemple) se retrouve échappé. On peut en parler dans un topic dédié si certains veulent essayer de trouver une meilleure façon de faire, comme ça risque d'être assez technique mieux vaut éviter de remplir celui-ci.

Je pense qu'il ne faudrait pas échapper ce qui n'a pas d'effet. Si j'édite un message dans le même langage que celui que j'ai utilisé pour l'écrire, alors je devrais retrouver ce que j'ai écrit (moins ce qui ne change rien, comme des échappements doubles et retours à la ligne à la fin...).

Sinon, rien à voir, pourquoi des fois, on ne peut pas mettre une vidéo YouTube incluse dans un message en plein écran ?

C'est moins évident à implémenter qu'à décrire, à cause de certaines balises qui compliquent tout. Par exemple quand on met un [pre] dans un texte il doit empêcher l'activation de toutes les autres balises jusqu'à ce qu'il soit fermé. À cause de ce genre d'exceptions, la règle n'est pas aussi simple que "une balise a un effet si on a une balise ouvrante et la balise fermante qui lui correspond", aujourd'hui c'est implémenté avec un état dans le parseur, ce qui je trouve assez naze mais je n'ai pas de meilleure solution.

Quand un message est "déparsé", la logique inverse qui correspondrait exactement à ce que fait le parseur est tellement compliquée que je n'ai même pas essayé de l'implémenter (sachant que celle du parseur ne me plait pas, je n'ai pas envie d'y passer trop de temps). Du coup c'est assez naïf : si dans le texte littéral on trouve quelque chose qui pourrait être considéré comme une balise, sachant qu'on vient de la trouver dans un texte littéral c'est qu'elle a été ignorée au moment du parsing pour une raison ou pour une autre, donc dans le doute on l'échappe. Peut-être que c'est inutile car même sans échappement elle n'aurait pas pu être pris en compte, mais cette information est complexe à obtenir.

À mon avis, si j'ai une solution plus simple pour écrire le parseur sans avoir besoin d'un état, alors ça deviendra également facile d'écrire le code qui "déparse" en faisant exactement l'opération inverse.

Ce ne serait pas possible de garder le texte avant parsage pour l'afficher en cas d'édition ?
Il me semble que tu as enlevé ça pour pouvoir accepter plusieurs langages, mais la solution aurait peut-être été d'ajouter une indication du langage utilisé et de faire la conversion uniquement en cas d'édition dans un autre langage. On garderait en base de données la dernière version avant parsage dans le dernier langage utilisé. Comme ça, la conversion est moins critique, car un utilisateur éditera probablement son message dans le même langage que celui qu'il a utilisé pour l'édition précédente ou la rédaction originale. (Je pars du principe qu'on édite généralement son message pour corriger une erreur peu de temps après sa rédaction. Dans le cas où l'on revient sur un message plus ancien (ou le message de quelqu'un d'autre), il est peut-être plus acceptable d'avoir une syntaxe un peu plus lourde.)

Lorsqu'un langage évoluera, il faudra supprimer tous les textes avant parsage de ce langage pour avoir la nouvelle syntaxe lors d'une édition. Ça n'arrive pas très souvent, donc ça ne devrait pas tuer trop de monde.


Sinon, l'autre solution est d'améliorer le parseur

C'est surtout pour des raisons de performance que le texte est conservé après un premier traitement, pas tellement pour supporter plusieurs langages (le fait que cette fonctionnalité soit possible n'est qu'une conséquence). Une fois un post analysé, il est sauvegardé sous une forme qui contient d'une part le texte brut, d'autre part toutes les balises qui ont été repérées avec l'index où elles se situaient et leurs éventuels arguments.

D'un côté ça permet de gagner pas mal de temps à l'affichage puisqu'il n'y a plus besoin de parcourir le post (juste appliquer la liste des balises), d'un autre ça impose de devoir faire cette opération problématique de "déparsage" quand on veut éditer un post. Comme on édite beaucoup moins souvent des posts qu'on ne les affiche, ça reste rentable, mais le code actuel est assez foireux :/

Pourquoi ne pas stocker le texte original ? Si ça prend trop de place, ce serait possible de ne le garder que pour une durée limitée.

Stocker le texte original n'est pas possible à cause de la taille de la BDD en effet (ça ferait grosso modo x2 sur la taille de la base, vu que la table des posts fait 90% du total). Les stocker temporairement ça ne me semble pas top non plus, ça voudrait dire que l'édition deviendrait non prédictible, je trouve même que ça serait pire que la situation actuelle (où ça foire, mais au moins ça foire de façon attendue et reproductible).

Tu ne peux pas juste au moment de l'edition d'un port remplacer les \x par leur equivalent?
Je veux dire \ deviens \, \[ devient [ etc..

De toutes maniere le code qui va chercher savoir si un [xx] est une balise valide ou non va devoir tourner dans tous les cas, donc qu'il y ai une balise de plus ou de moins ca ne va pas changer grand chose.

Apres l'avantage du \[xx] c'est qu'on vois tout de suite ou l'on c'est plante dans une balise..

Je suis pas sûr de comprendre ton post, quand on édite des backslashes sont ajoutés devant le texte potentiellement problématique. Si je ne le fais pas et que l'utilisateur clique sur "Envoyer", ça va lui considérer des balises dans son message alors qu'il n'y en avait pas initialement et qu'il n'a rien touché.

Pour rappel, le but est que si un utilisateur édite un message et clique sur "Envoyer" sans rien modifier, le message continue à apparaître comme avant. Ce dont se plaint Yoshi Noir c'est que si on se gourre sur une balise (par exemple on ouvre un [u] mais on oublie de le fermer) et qu'on édite pour corriger son erreur (en ajoutant le [/u] manquant), la balise ouvrante se retrouve au passage échappée et qu'on a toutes les chances de ne pas s'en rendre compte avant d'envoyer. Ce qui se passe, c'est que comme cette balise [u] n'a pas été acceptée la première fois, elle est considérée comme du texte littéral. Pour être certain qu'elle continue à être traitée comme telle, elle est échappée quand on édite le message.

Le problème dans cette histoire c'est que même sans l'échapper elle n'aurait quand même pas été acceptée (puisqu'il lui manque son [/u]), donc ça n'était pas la peine de le faire (et c'est même pénible) mais cette information n'est pas triviale à obtenir étant donné le fonctionnement actuel.

Je crois qu'il va falloir que j'illustre un peu plus si vous voulez trouver une solution

Humpf ce que j'ai dit ne marche pas dans le seul cas ou le \x est volontaire..

C'est à dire la raison même de l'existence du \, non ?

ben la ou il y a soucis c'est quand tu met un \ devant un truc parce que la syntaxe est foireuse (genre un #xxx# qui n'existe pas ou un [u] sans son [/u])

Dans ces cas la uniquement, au moment de l’édition, les \ pourraient disparaitre, si c'est bien sur l'utilisateur qui met un \ bien sur il ne faut pas le faire disparaitre

Sauf qu'actuellement je n'ai aucune idée de si l'utilisateur a mis un \ ou pas, et je m'en fiche un peu du moment que je suis capable de reconstruire un message qui s'affiche exactement de la même façon. Du coup, je ne sauvegarde pas cette info, et je trouverais dommage d'avoir à le faire alors qu'on peut logiquement s'en passer.