VÉRIFIER LES CHAMPS OBLIGATOIRES D'UN FORMULAIRE
codefalse
Messages postés
1123
Date d'inscription
mardi 8 janvier 2002
Statut
Modérateur
Dernière intervention
21 avril 2009
-
15 févr. 2008 à 15:35
cs_yoman64 Messages postés 592 Date d'inscription samedi 19 janvier 2002 Statut Membre Dernière intervention 4 décembre 2008 - 18 févr. 2008 à 22:02
cs_yoman64 Messages postés 592 Date d'inscription samedi 19 janvier 2002 Statut Membre Dernière intervention 4 décembre 2008 - 18 févr. 2008 à 22:02
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/45752-verifier-les-champs-obligatoires-d-un-formulaire
https://codes-sources.commentcamarche.net/source/45752-verifier-les-champs-obligatoires-d-un-formulaire
18 févr. 2008 à 22:02
Ici tu regarde si il y a quelque chose dans le POST, et ensuite si il est pas égale au string '0', pourquoi faire ?
En plus tu vérifie pas si isset, ça va vite générer des notices pour ceux qui développe strict (comme tous les devs devraient faire)
# if(empty($_POST[$value]) && $_POST[$value] != '0'){// si la valeur de poste est vide alors on l'ajoute aux erreurs
# $errors[] = $value;
# }
Remplacer par
# if(!isset($_POST[$value]) || trim($_POST[$value]) === ''){// si la valeur de poste est vide alors on l'ajoute aux erreurs
# $errors[] = $value;
# }
Me semble beaucoup plus juste...
Ce qui va vérifier si elle est setter, si c'est pas le cas on arrête la et on ajoute une erreur, sinon on voit si elle contient quelque chose, si c'est pas le cas on ajoute une erreur...
bref je vois pas trop l'utilité d'un tel code, mais bon tant qu'à le faire, aussi bien le faire correctement...
18 févr. 2008 à 14:07
18 févr. 2008 à 13:50
Ne cherche pas à savoir s'il est rempli ou non, cherche tout de suite à savoir s'il contient les valeurs attendues, ca t'évitera les pbs comme ca : "je teste si la var est empty puis si elle est différente de zéro car zéro".
Après plus de souci. Et pour "Ca évite de se retaper les if(empty()) de chaque champs...", rien ne t'empêche de faire un fonction de test, avec les param Min et Max, et hop !
18 févr. 2008 à 13:44
Ca a une utilités limités certes mais c'est une opération qui revient souvent. Ca évite de se retaper les if(empty()) de chaque champs quand on crée un nouveau script, là il suffit de remplir le tableau.
Yoman64> Je comprend pas tout, je teste si la var est empty puis si elle est différente de zéro car zéro est considéré comme empty alors que ça peut être une valeur valide (merci à codefalse et malalam). Donc un string vide n'est pas égal à un string '0' mais empty renverra true pour les deux alors il faut faire la différence.
Sinon j'ai beaucoup vu de script pour vérifier qu'un mail était un mail, qu'une date est bien une date... beaucoup sont bancales, beaucoup sont inadaptable, et je n'en ai pas vu dont le but est la vérification du remplissage.
18 févr. 2008 à 09:40
Le test doit être fait sur la valeur, qui elle est 'unique' pour chaque champ puisqu'elle doit être ET significative ET stockable (en BdD)...
C'est donc un ISSET + TESTS aux limites (a minima sur TRIM($_post['monchamp']) pour éviter les malins qui mettent des espaces...) qui eux restent propriétaire de l'application.
Explication par l'exemple :
- les enfants de malalan, c'est >-1 et <10 (de 0 à 9) (et 9 c'est vraiment beaucoup, mais aux limites, ca existe...)
- un titre, c'est inférieur au MAX de bdD, mais pour être significatif tu peux vouloir lui imposer un mini, donc c'est >5 et inférieur à 126 (max BdD =125)
- un choix de liste déroulant (0= sélectionnez), c'est >0 et <(X+1) (le dernier choix !).
- un texte libre (area) comme le titre, mais avec un signifiant plus important (>10...)
Bref, les vérif de formulaire ca me fait rire, car c'est forcément un truc perso qui colle à l'appli, donc aux spécif, donc au 'métier' pour laquelle (et lesquels) elle a (et ils ont) été réalisé.
CE N'EST PAS GENERALISABLE !
Maintenant tu peux appliquer 2 politiques :
- l'exploitant / chercheur : mieux vaut ne rien avoir en bdd qu'une info non-exploitable !
- commerciale : on prends tout et les exploitants se démerderont...
Les tests et les variables obligatoires pour enregistrement seront fait en conséquence, bref, selon l'appli, les spéc, la demande, le métier, la demande initiale qui fait que tu réalises un formulaire , koi ^^
17 févr. 2008 à 20:36
et comme dit plus haut vraiment étrange de comparer si !'0' .. O.o je vois mal comment un string vide peut être égale à un string '0' mais bon je me trompe peut être mais $_POST[''] '' est plus juste...
17 févr. 2008 à 16:18
if (isset($_POST['value']) && trim($_POST['value'])!='')
15 févr. 2008 à 20:47
15 févr. 2008 à 19:00
oki, je vois bien le probleme, alors comment le régler ?
un if(empty($_POST['value']) && $_POST['value'] != '0') devrait faire l'affaire nan ?
15 févr. 2008 à 18:51
Exemple : Combien avez-vous d'enfants (réponse obligatoire). Ton code va prétendre que je n'ai pas répondu si je mets que j'ai 0 enfant.
15 févr. 2008 à 18:50
"lol alors je changerai ça dans un souci de propreté ^^ mais ça marche ici :p"
Hmm..nous sommes sur des données de formulaire, donc des chaînes.
or empty('0') renverra true avec toute version de php >= 4
Alors à moins que tu bosses avec une version de PHP3...je vois mal comment ça peut renvoyer false chez toi?
Pour ta question, ce ne sera soit la deuxième, soit if(!empty($errors)) {}
15 févr. 2008 à 18:44
Retourne FALSE si var a une valeur non-vide et différente de zéro.
Ce qui suit est considéré comme étant vide :
"" (une chaîne vide)
0 (0 en tant qu'entier) <---------- :D
"0" (0 en tant que chaîne de caractères)
NULL
FALSE
array() (un tableau vide)
var $var; (une variable déclarée, mais sans valeur dans une classe)
15 févr. 2008 à 18:33
Alors question, vaut il mieux que je fasse un if(count(array)>0) ou alors que je saute la déclaration de l'array et que je fasse un if(isset(array)) ?
les deux marchent mais est-ce bien propre ?
15 févr. 2008 à 18:09
c'est la doc qui le dit :p
15 févr. 2008 à 16:45
15 févr. 2008 à 15:35