Cooling-Masters
Connexion · INSCRIPTION · Site Recevoir à nouveau l'e-mail de validation


php mysql

Ajouter ou retirer ce sujet de vos favoris  ·  Suivre ce sujet  ·  Imprimer ce sujet
Pages : « Première ...  14  15  16  17  18  19 
Page précédente    Page suivante 
kipkool


Moine tibétin
Messages : 8571

lundi 03 décembre 2007 à 21:51:55     
Pas partout, ici c'est la zone et il fait froid
Google




     
Tyrou


★ Jet Lag Addict ★
Messages : 21926

lundi 03 décembre 2007 à 22:16:05     
froid / tropique
Rosco


Administrateur
Messages : 25926

lundi 03 décembre 2007 à 22:17:36     
QUOTE (PeGGaaSuSS @ lundi 03 décembre 2007 à 19:46:56) :

Pourquoi on peut pas quoter un quote ?

Pour éviter les kilomètres de quote imbriqués quand 10 guguss auront quoté un quote de quote de..... sans se soucier de la lisibilité (et ça prend de la place pour rien).
Comme les IMG dans les quotes qui sont retirées pour éviter d'avoir 15 fois la même image quotée, y a rien de + pénible (sur XS par ex, quand y en 2-3 qui quotent 10 fois les mêmes tofs de suite pour foutre un LOL -> )
xalis


Membre
Messages : 9791

mardi 08 janvier 2008 à 00:11:30     
bonsoir tous, voilà j'ai une question en PCRE

je viens de coder ça à l'arrache en quelques secondes :
CODE :


$buffer=preg_replace('#(.*?)\[URL\][^(http:\/\/)](.*?)\[\/URL\](.*?)#si','\\1<a href="http:\/\/\\2">\\2</a>\\3',$buffer);


le problème c'est que quand je passe à $buffer
CODE :

www.google.fr
, j'obtiens
CODE :

ww.google.fr
et dans le href j'ai bien
CODE :

http://ww.google.fr
mais avec le caractère manquant



Donc je voulais savoir d'où vient cette suppression de caractère ?

Message édité par benoît le mardi 08 janvier 2008 à 00:21:30
debugger


Membre
Messages : 2002

mardi 08 janvier 2008 à 01:23:49     
ton masque ne marcherait pas si ton texte contient plusieurs [url], et ne tolèrerait pas les espaces

à ta place je ferais ceci :
CODE :

$buffer='blabla [url]www.google.fr[/url] toto [url]  http://www.google.fr   [/url] titi';
$buffer=preg_replace('#\[url\]\s*(http://)?([^\[\s]*)\s*\[/url\]#si','<a href="http://\\2">\\2</a>',$buffer);
xalis


Membre
Messages : 9791

mardi 08 janvier 2008 à 01:49:30     
non t'inquiète pas, il y a plusieurs autres preg_replace pour palier à d'autres problèmes, ce masque là ne sert uniquement à palier au problème du www sans http devant

edit : merci pour ton aide

edit2 : aurais-tu un bon site ou livre à me conseiller pour m'améliorer en expressions régulières ?

Message édité par benoît le mardi 08 janvier 2008 à 01:50:28
debugger


Membre
Messages : 2002

mardi 08 janvier 2008 à 01:51:59     
oué mais ce nouveau masque est plus puissant, et règle on pb de caractère perdu ^^

edit : syntaxe des masques en php, la tartine de texte fait peur mais au final c'est "sympa" (là c'est subjectif )

Message édité par debugger le mardi 08 janvier 2008 à 01:56:17
Shinuza


Mais bof quoi
Messages : 4419

mercredi 09 janvier 2008 à 01:18:45     
QUOTE (debugger @ mardi 08 janvier 2008 à 00:23:49) :

ton masque ne marcherait pas si ton texte contient plusieurs [url], et ne tolèrerait pas les espaces

à ta place je ferais ceci :
CODE :

$buffer='blabla [url]www.google.fr[/url] toto [url]  http://www.google.fr   [/url] titi';
$buffer=preg_replace('#\[url\]\s*(http://)?([^\[\s]*)\s*\[/url\]#si','<a href="http://\\2">\\2</a>',$buffer);

Il vaut mieux éviter de cacher la génération d'une variable (en gros d'associer à une variable le résultat de l'évaluation d'une expression de cette meme variable).
Question de lisibilité.
(Oui c'est aussi tordu à lire qu'a écrire sous forme de code)
debugger


Membre
Messages : 2002

mercredi 09 janvier 2008 à 14:38:55     
ça c'est faux

c'est naturel (et logique) de faire ça quand on veut modifier la valeur d'une variable sans changer sa nature

ex : si on veut transformer du texte tout en majuscules, on va pas le mettre dans une nouvelle variable... toi si ? ben pas moi car justement je trouve plus lisible d'avoir 1 variable qui a subit N transformations que N variables qui ont subit 1 transformation, surtout si c'est le résultat qui m'intéresse et pas les étapes

une autre raison (même si avec les machines d'aujourd'hui on s'en fout) c'est que plus on crée de variables, plus ça consomme des ressources cpu / mémoire, je préfère de loin être pinailleur sur des préoccupations de ce type !
Shinuza


Mais bof quoi
Messages : 4419

mercredi 09 janvier 2008 à 17:36:14     
QUOTE (debugger @ mercredi 09 janvier 2008 à 13:38:55) :

ça c'est faux

c'est naturel (et logique) de faire ça quand on veut modifier la valeur d'une variable sans changer sa nature

ex : si on veut transformer du texte tout en majuscules, on va pas le mettre dans une nouvelle variable... toi si ? ben pas moi car justement je trouve plus lisible d'avoir 1 variable qui a subit N transformations que N variables qui ont subit 1 transformation, surtout si c'est le résultat qui m'intéresse et pas les étapes

une autre raison (même si avec les machines d'aujourd'hui on s'en fout) c'est que plus on crée de variables, plus ça consomme des ressources cpu / mémoire, je préfère de loin être pinailleur sur des préoccupations de ce type !

Je veux bien que ça le soit en php, tout simplement parce c'est un langage procédural, et que les types ne sont pas des objets (en plus d'avoir un parseur des plus intolérant), mais il est indéniable que cela nuit à la lisibilité (encore une fois l'effet est accentué étant donné que php n'a pas d'ordre de paramètres fixes).

(D'ailleurs, si le résultat est encapsulé dans une fonction/methode et retourné explicitement, un GC correctement ficellé se débarassera des réferences intermediaires.)

Mais c'est censé ressembler à ça, ensuite dans une classe couplé avec une fluent interface ( quoique, je suis même pas sur que ça soit possible en l'occurence ) on gagne en lisibilité et en clustering.

CODE :

function parseURLTags ($input) {
return preg_replace('#\[url\]\s*(http://)?([^\[\s]*)\s*\[/url\]#si','<a href="http://\\2">\\2</a>',$input);
}


Message édité par Shinuza le mercredi 09 janvier 2008 à 17:38:21
Google




     
Pages : « Première ...  14  15  16  17  18  19 
Page précédente    Page suivante