smileys mais comment - Page 1

coucou tout le monde j'ai un pitit probleme en fait j'ai fait mon systeme de news et j'aimerais y mettre des smileys .
une gestion de smilies meme banale pourriez vous me mettre sur le bon chemin???
merci d'avance salut...

Voila ce que j'avais fait (j'explique le principe, pas le code hein ) :
- A chaque image de smiley, tu associes un emoticon textuel (les trucs classiques quoi : : ), ; ), : ], etc...)
- Tu mémorises ces associations dans une base de données
- Le monsieur rentre sa news en utilisant les emoticons textuels.
- Au moment d'enregistrer la news, tu y va a coup de preg_replace, et tu remplace chaque occurence d'un emoticon par son image qui va bien.
- A mon avis, tu le mémorise plutot comme ça, ça limitera les requetes SQL. Sinon, il est toujours possible de ne pas remplacer les emoticons, mais a chaque affichage de la news, il faudra effectuer le remplacement, c'est plutot lourd niveau requetes.

Voila, c'est simple, et ça marche plutot bien

A mon avis, tu devrais plutot définir à l'avance les smileys que tu comptes utiliser, et leur correspondance. Par exemple tu mets tout ça dans deux gros tableaux :

$smilieCode = array(':)',':(',':D'...);
$smilieImage = array('smile.gif','sad.gif','biggrin.gif'...);

Puis ensuite un simple str_replace au moment d'afficher (pas besoin de preg, il n'y a aucune expression régulière ici, pourquoi ralentir inutilement ?). Les smileys seront statiques mais ça t'économise des grosses requètes, de toutes façons on ne les change pas tous les jours. Aussi, tu ne devrais pas les parser à l'enregistrement mais bien à l'affichage, contrairement à ce que dit guilc, sinon impossible d'éditer les news (ça va faire apparaitre les <img src=...> à l'édition, qui ne passeront plus après le 2eme repost puisque < et > seront interdis).

Mouais merci je vois le blem d'un cote un peu plus clair maintenant me reste juste a trouver les bases du codage merci encore je vais essayer de bosser la dessus sinon tu me reveras lol

Pour l'édition, tu peux toujours revenir au smileys, il suffit de faire l'opération inverse de remplacement avec une base de donénes, justement, ça se fait facilement. Et le preg_replace n'est pas si lent que ça, il est meme plutot rapide (je ne parle pas d'ereg_replace)

Perso, je trouve que la définition statique manque un peu de souplesse.
M'enfin, après, ça dépend de ton utilisation

Disons que pour moi debutant dans ce domaine "smileys" prefere me baser sur la facon la plus simple pour le moment et apres l'ameliorer alors j'ai deja deux solutions a moi de voir laquelle est la meilleure ou c'est parti pour un beau debat bonne soiree tout le monde et merci encore...

guilc :
Pour l'édition, tu peux toujours revenir au smileys, il suffit de faire l'opération inverse de remplacement avec une base de donénes, justement, ça se fait facilement.

Pas tellement plus facilement avec une base de donnée, non, mais surtout tu risques d'avoir des problèmes au cas ou l'utilisateur entre à la main une url de smiley (qui se retrouve changée en code au moment de l'édition).

Et le preg_replace n'est pas si lent que ça, il est meme plutot rapide (je ne parle pas d'ereg_replace)

Certes, mais quel interet à utiliser des expressions régulières là où il n'y en a pas besoin, par rapport à un simple remplacement de chaines ?

Alors lequel adopter ?

je suis assez chaud pour une base de donnee car je commence a bien la maitrisser maisreste ancore a savoir laquelle est la meilleur pour un debutant...

enfin a vous de ^me le dire tout se que je cherche c'est des conseils car je n'y arrive pas vraiment .

merci a tout les deux @peluche.

-

re coucou ah.. yes pk pas moi j'ai trouve autre chose et j'aimerais votre avis si c'est possible je ne l'es pas tester mais juste regarde en gros...


Function FilterText($ReplyText){
$ReplyText = htmlspecialchars($ReplyText);
$ReplyText = nl2br($ReplyText);
$ReplyText = str_replace(" ;b ","<img src=images/01.gif border=0>",$ReplyText);
$ReplyText = str_replace(" ;I ","<img src=images/21.gif border=0>",$ReplyText);
$ReplyText = str_replace(" ;s ","<img src=images/22.gif border=0>",$ReplyText);
$ReplyText = eregi_replace("([[:alnum:]]+)://([^[:space:]]*)([[:alnum:]#?/&=])","<A HREF=\"\1://\2\3\" TARGET=\"_blank\">\1://\2\3</A>",$ReplyText);
$ReplyText = eregi_replace("(([a-z0-9_]|\-|\.)+@([^[:space:]]*)([[:alnum:]-])\.([^[:space:]]*)([[:alnum:]-]))","<a href=\"mailto:\1\">\1</a>",$ReplyText);
return $ReplyText;
}

je pense qu'elle est bien mais je n'es aucune experience la decus alors je vous laisse en juger.
=>Salut tout le monde et merci encore.

C'est le même principe, mais tu peux remplacer tous ces appels à str_replace par un seul, puisque str_replace accepte des tableaux en argument.

coucou yes pourquoi pas mais mmt que j'ai le principe du code je ne sais pas vaiment ou l'integrer dans ma page, faut respecter un ordre d'insertion ou on peutle mettre n'importe ou ???
merci de m'aider @peluche les gars.

Ben, ton texte, il est tapé dans un formulaire, le type il appuye sur "poster" ou équivalent, et le formulaire te redirige vers une autre page qui va traiter les données.

Je suppose que dans ce traitement, tu insères sagement le texte dans une base de donnée. Ben tu fous cette fonction juste avant l'insertion.

Autre point important : il est parfois utile d'échapper certains caractères ... je parle notamment des < et >, des " et de caractères bizarres.
Ben il faut faire pareil, et remplacer par ce qui va bien (exemple : < devient &lt; ...), sauf si tu veux qu'on puisse faire joujou avec les balises html ... mais c'pas recommandable en général.

Vertyos :
A mon avis, tu devrais plutot définir à l'avance les smileys que tu comptes utiliser, et leur correspondance. Par exemple tu mets tout ça dans deux gros tableaux :

$smilieCode = array(':)',':(',':D'...);
$smilieImage = array('smile.gif','sad.gif','biggrin.gif'...);
Puis ensuite un simple str_replace au moment d'afficher (pas besoin de preg, il n'y a aucune expression régulière ici, pourquoi ralentir inutilement ?). Les smileys seront statiques mais ça t'économise des grosses requètes, de toutes façons on ne les change pas tous les jours. Aussi, tu ne devrais pas les parser à l'enregistrement mais bien à l'affichage, contrairement à ce que dit guilc, sinon impossible d'éditer les news (ça va faire apparaitre les <img src=...> à l'édition, qui ne passeront plus après le 2eme repost puisque < et > seront interdis).

Le plus econome en ressource c'est tout de même d'avoir deux champs post_edite et post_affiche.

gni :/
Ça prend une place monstrueuse ça, imagine ce que ça donnerait avec des gros forums comme yAronet.

Si il ne veut absolument pas perdre de temps à parser, il peut utiliser le principe d'IPB, c'est à dire une fonction "parse" qui convertis le message en code HTML pret à afficher, et la fonction inverse, "unparse" qui est utilisée lors de l'édition ou la citation du message.

Ben, ça dépend de la situation. La solution de moumou, que j'utilise sur mon blog, a l'avantage d'être meilleure quand on parle de vitesse d'affichage de la page. Pas de fonctions suplémentaires à appeler pour convertir des textes.

Après, il faut avoir de la place dans la base, c'est sûr. Et du coup, pour un gros site, la solution d'une fonction de conversion est évidemment (je pense) à privilégier.

Les deux ont leurs avantages/inconvénients, tout simplement

Bah c'est ce que j'ai dit, cf 1ere phrase hein

Mais pour completer, je dirais que très franchement, avoir une attente de 5ms (0,005 seconde, je sais pas si vous arrivez à voir ça mais moi nan ) de plus au moment d'éditer un message, j'appelle pas ça une "contrainte de vitesse". La vitesse d'affichage, quant elle, est exactement la même avec la solution de Moumou et celle du parsing/unparsing puisque précisement le but est de ne pas avoir à parser le message à chaque affichage mais une seule fois à l'envoi.
Pour moi son seul inconvenient, c'est qu'elle est nettement plus chiante à mettre en oeuvre, mais c'est un argument de feignasse ça, non ?

bah le parsing et l'unparsing ne sont surement pas bijectifs, c'est pas top ...

Heu théoriquement, et si c'est bien fait ils sont bijectifs... En regle generale, [qqchose][/qqchose] devient <qqchose></qqchose> qui est impossible à écrire dans un post puisque les < et > sont transformés en &gt; et &lt;, donc il ne devrait pas y avoir de conflit. Tu sais, si IPB utilise ce systeme, à mon avis il ne doit pas être si foireux que ça

En général. Mais comment différencier par exemple un [ url=http ://www.aaa.net]http ://www.aaa.net[/url] d'un [ url]http ://www.aaa.net[/url] ou encore d'un http ://www.aaa.net ?

Là tu cherches vraiment les exceptions

Pour le adresse, on peut penser que les utilisateurs ne sont pas stupides et n'iront pas faire ça, de toutes manière comme ça revient strictement au même que de faire http://adresse, si c'est transformé au déparsing, c'est pas bien grave

Ben justement, je l'ai vraiment pas cherché loin, cet exemple. Donc, si le code se complexifie un peu, il risque d'y avoir plus de problèmes du genre (et qui eux, changeront vraiment quelque chose au déparsing).

Heu... Parmis les balises communes j'ai du mal à voir ce qui est plus compliqué que [url] ? [table], peut-être, mais elle n'est que sur yAronet...

Si tu veux vraiment que ça marche dans les deux sens, tu peux leur mettre des attributs d'identification au parsing, genre id="blabla" ou qqchose dans ce genre, y'a toujours moyen de se débrouiller. Je ne pense vraiment pas que si le code "se complexifie un peu" ça risque de poser problème, tout ce qui se parse se déparse dans ce cas.

Et même, d'ailleurs, si j'explique un truc à un nioob, sur comment utiliser [url], ben je veux pas que mon post soit changé quand il éditera ...

cf deuxième remarque de mon post précedent

Oui mais ça prend plus de place dans la page.
• Moumou veut toujours le dernier mot

Oué ça j'ai bien vu que depuis quelques posts c'est du #mac# total

[edit] +vu, en effet.
#27 > Si tu veux, je suis pas là pour flooder, MOI

+vu (non tu ne m'auras pas, je serai le dernier )