Bonjour,

Je pense que beaucoup d'entre vous connaissent la fonction nl2br, qui permet d'insérer la balise '<br />' devant toutes les nouvelles lignes. Beaucoup de personnes recommandent d'utiliser cette fonction uniquement à l'affichage. Et d'ailleurs, cela parait tout à fait logique, et cela explique également pourquoi il n'existe pas de fonction br2nl.

Cependant, je me trouve face à une impasse : imaginez un formulaire bbcode, dans un panel d'administration, permettant d'insérer du html (je ne parle pas d'une coloration syntaxique, mais bel et bien de html : les balises sont interprétées). Voici un exemple :

Par exemple, nous entrons ceci dans le formulaire :

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Phasellus eu arcu. Nulla diam velit, convallis in, elementum sed, varius varius, lorem.

Quisque ut purus et <strong>lorem</strong> mollis venenatis.<br />
Qroin luctus dignissim sapien. 
Sed luctus porta eros.

Aliquam purus velit, pharetra vitae, porttitor quis, ornare ut, libero. Quisque convallis, dolor a varius elementum, dolor leo suscipit nisl, in mollis nisl ipsum et lacus.

Et cela afficherait :

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Phasellus eu arcu. Nulla diam velit, convallis in, elementum sed, varius varius, lorem.

Quisque ut purus et lorem mollis venenatis.
Qroin luctus dignissim sapien. Sed luctus porta eros.

Aliquam purus velit, pharetra vitae, porttitor quis, ornare ut, libero. Quisque convallis, dolor a varius elementum, dolor leo suscipit nisl, in mollis nisl ipsum et lacus.

Pour des raisons de performance, le plus judicieux est de parser le formulaire à l'enregistrement. Cependant, ça impose d'utiliser nl2br à l'enregistrement, et non à l'affichage. Autrement dit, on est véritablement partagé entre performance et logiques de programmation.


Même si je reconnais que la question n'est pas de la plus haute importance, votre point de vue m'intéresse.

Je ne comprend pas pourquoi le fait de stocker du HTML t'oblige à utiliser l2br() à l'enregistrement

Tu peux bien stocker du HTML, et passer la chaîne dans nl2br() à l'affichage

Il y a un aspect à prendre en compte aussi, c'est si le texte peut être édité, et si c'est souvent ou pas. Car éditer un texte avec des sauts de ligne c'est plus facile qu'avec des <br />

Si tu utilises nl2br à l'affichage sans prendre vraiment de précaution, le code du formulaire :

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Phasellus eu arcu. Nulla diam velit, convallis in, elementum sed, varius varius, lorem.

Quisque ut purus et <strong>lorem</strong> mollis venenatis.<br />
Qroin luctus dignissim sapien.
Sed luctus porta eros.

Aliquam purus velit, pharetra vitae, porttitor quis, ornare ut, libero. Quisque convallis, dolor a varius elementum, dolor leo suscipit nisl, in mollis nisl ipsum et lacus.

va se transformer en :

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Phasellus eu arcu. Nulla diam velit, convallis in, elementum sed, varius varius, lorem.<br />
<br />

<br />
Quisque ut purus et <strong>lorem</strong> mollis venenatis.<br /><br />
Qroin luctus dignissim sapien.<br />
Sed luctus porta eros.<br />

<br />
<br />
Aliquam purus velit, pharetra vitae, porttitor quis, ornare ut, libero. Quisque convallis, dolor a varius elementum, dolor leo suscipit nisl, in mollis nisl ipsum et lacus.

Autrement dit, le nl2br s'appliquera également au code compris entre

 et 

. Or ça ne doit pas être le cas.

Dans cet exemple simple, oui, un parser capable de faire ça est tellement rapide qu'il est envisageable de le faire à l'affichage. Mais imaginons maintenant un parser beaucoup plus complexe, avec par exemple des citations, des colorations syntaxiques dans une 10ene de language, etc... Rapidement, ça peut devenir assez lourd.

Il y a un aspect à prendre en compte aussi, c'est si le texte peut être édité, et si c'est souvent ou pas. Car éditer un texte avec des sauts de ligne c'est plus facile qu'avec des <br />

Exactement

Les transformations doivent être effectuées à l'affichage. À la rigueur tu peux mettre le résultat de la transformation en cache, mais le problème reste le même.

Donc pas de question à se poser, pour des questions de performances tu perdrais à la fois en logique ET en utilisabilité pour tes visiteurs. Autant éviter

Je suis totalement d'accord sur le principe.



Cependant, si tu prends en compte quelques chiffres :
- un article est créé une seule fois
- On va dire qu'il est modifié 10 fois (ce qui est déjà enorme).
- Sur un site générant un petit trafic, il est affiché 1000 fois.

Donc, en parsant à l'affichage, je dois parser mon article 1000 fois.

En le parsant à la création, je dois le parser une seule fois. Le problème reste les modifs, qui m'obligent à le déparser pour ensuite le re-parser.

Donc à mon avis, le gain en performance n'est pas négligeable. Surtout que si tu prends ensuite le cas d'un forum, avec 30 réponses à parser par page !

D'où l'intérêt de la mise en cache.

Sur un forum par exemple, il est impossible de mettre en cache tous les topics.

Bien sûr que si, en quoi ça ne serait pas possible ?

C'est possible.
Mais ça fait un tas d'information en double quand même !

Regarde ici :

Nos membres ont posté un total de 113833 messages

Il faudrait créer, en plus de la base de données, 113833 fichiers texte pour stoquer chaque message en cache ?