Salut,

J'ai l'impression que tu as pris mon post comme un reproche mais ce n'est pas le cas.
Pour te donner plus d'explication sur mon "questionnement", je posais la question pour essayer de trouver quelqu'un qui puisse m'expliquer, et me convaincre au besoin, quel est le principal avantage à préférer des vérifications par un script côté serveur plus que par un script côté client. Personnellement, cette méthode n'a pour moi pas d'avantage du fait de l'obligation d'un tranfert du client vers le serveur pour que le serveur vérifie les données (soit-dit en passant, le serveur fait des traitements à la pelle alors que l'ordinateur du client dispose de toutes ses ressources pour faire ce genre de manipulations, me semble-t'il). L'autre point négatif, mais cela ne s'applique pas forcément dans ton cas mais plus sur un formulaire de saisie plus complet, cela implique qu'en cas d'erreur, il faut penser à remettre dans les champs ce qui a été saisi, d'où des tests et des ressources utilisées en supplément du traitement à proprement parler, la tendance étant de plus en plus aux RIA.
Concernant ta remarque sur les CMS (spip, joomla, ...), je pense ne pas trop me tromper en disant que le métalangage qu'il utilise n'est qu'une interprétation différente des instruction du moteur de script utilisé, mais qui de toute façon, de part l'utilisation de PHP ou de .NET pour le moteur de translation, génèrent un langage compréhensible par les navigateurs, donc du (x)html, css et javascript. Les effets dynamiques de menus déroulants et autres effets sont du DHTML, donc du javascript. Du coup, si blocage du javascript il y a, cela entraîne des dysfonctionnements au niveau du site. En plus, de plus en plus de CMS intègrent des bibliothèque AJAX et javascript (graybox, lightbox, Google ToolKit ...).
Enfin, concernant les capacités des navigateurs à bloquer les pubs et autres éléments désagréables, ils ne bloquent pas toutes les instructions Javascript, ils ne bloquent que celles susceptibles de provoquer l'ouverture ou l'affichage d'une pub dans une nouvelle fenêtre (ou un nouvel onglet). Pour preuve, actuellement, peu de sites sur lesquels apparaît une div contenant de la pub sont traités par ces systèmes de blocage, car l'affichage ne se fait pas par un window.open ou un target="_blank".
En tout cas, concernant la mise à jour de ta source, bon travail, elle est intéressante. Je vais m'y pencher un peu et te donner mon avis dessus.

Sur ce, bon courage et peut-être à bientôt

Salut,

Ok, la source semble correcte, juste une chose, au lieu de verif_presence1 == NULL, pourquoi ne pas utiliser (is_null(verif_presence1) ?
Ensuite, dans ta reuquête, j'aurai plutôt fais ça : WHERE UPPER(mail) = UPPER('$email') pour être sûr de ne pas être "corrompu" pour des erreurs de casse.

Mais je ne viens pas pour commenter le code en lui-même mais plutôt la logique.
Est-ce quelqu'un pourrait m'expliquer pourquoi la plupart des développeurs (professionnels ou non) font ce genre de vérification en PHP ?
Personnellement, je me trompe peut-être, comme on dit personne n'est parfait, la vérification des adresses mails, je fais ça en Javascript dans un script .js pour éviter d'avoir à faire un premier envoi du formulaire pour tester. Je parts du principe qu'il vaut mieux limiter les I/O entre les clients et le serveur. L'avantage d'utiliser Javascript pour des chose comme cela est que ça permet de ne pas transmettre le formulaire si il y a erreur. Et pour tester le dns ou savoir si l'adresse existe déjà dans la base, autant mettre un petit appel XmlHttpRequest et le tour est joué en limitant les transferts d'informations. Comme cela, le script PHP ne se charge que d'inscrire dans la base.
Vous me direz : Oui, mais si ton visiteur a désactivé Javascript, il l'a dans l'os. Ok, mais dans ce cas, il n'a rien à faire sur Internet. Donnez moi des sites sur lesquels il n'y a aucun code Javascript qui s'exécute ? Allez, je penche pour 5% des sites, autant dire aucun .... Et rien n'empêche, pour être sûr, de traiter ces vérifications des deux côtés (mais là c'est de la parano...).
Enfin, si quelqu'un peut m'expliquer, j'aimerai apprendre et comprendre.

Merci

Salut,

Oui en effet, désolé pour les notations courtes, j'ai tout corrigé avant que tu me le signales mais je n'ai pas eu le temps de faire un update.

Concernant la permutation, qu'est-ce qui te choque ? Elle me permet de permuter de Objets pour les trier. Au passage, je n'ai trouvé aucune fonction PHP permettant de trier des objets en fonction d'une proporiété. Si tu en connais une, cela m'intéresse.
Perso, c'est comme ca que j'ai appris à trier (tri simple, avant tri fusion et dycho) quand j'ai appris le C, C++.

Merci de cos commentaires.

Evangun : Oui désolé, j'ai pas fait attention :)

Sniogleerf : Normalement il faut que tu définisses un répertoire de base à mettre dans la constante ROOT. Soit tu le mets en dur dedans, soit tu passe par le tableau associatif par rapport aux noms d'utilisateurs déclaré dans le include associé. Si tu as fait un copier-coller du code ci-dessus, le plus simple est de le mettre en dur, sinon récupère le ZIP tu as tout dedans.

Merci pour vos commentaires, c'est ma première source en PHP alors tout est bon à prendre pour apprendre parfaitement.

Salut,

En effet la définition de clés uniques et primaires constitue le meilleur moyen d'éviter les doublons. Mais s'il faut épurer une base, je pense que le plus simple(dispo dès mysql4) serait de créer une table temporaire comportant les enregistrements uniques de la table à épurer pour ensuite vider la table d'origine et réinjecter les enregistrements.

En gros, ca donnerai qqchose comme ca :
<?
$conn_db =mysql_connect('localhost','root','');
$db = mysql_select_db("MyDB");
//Création de la table temporaire
$strsql = "CREATE TABLE tabletemp SELECT DISTINCT * FROM table1";
mysql_query( $strsql, $conn_db);
//Vidage de la table d'origine
mysql_query("DELETE FROM table1", $conn_db);
//Réinjection des enregistrements
$strsql = "INSERT INTO table1 SELECT * from tabletemp";
mysql_query($strsql, $conn_db);
?>

Il faut juste remplacer le * de la première requete par les champs que l'on veut conserver comme uniques.

Bon courage

Salut,
En effet, il y a quelques truc à changer, ainsi qu'une petite erreur de traduction, il ne fallait pas traduire : "5 valeurs numériques en flottant", mais "5 valeurs numériques de type float". :-))