Vérifier les champs obligatoires d'un formulaire

Soyez le premier à donner votre avis sur cette source.

Snippet vu 18 878 fois - Téléchargée 17 fois

Contenu du snippet

Ptite fonction toute simple qui n'apprendra rien aux coder confirmés mais qui reste pratique et que je n'ai pas croisé ici alors je post ;).

Source / Exemple :


<?php
	
	function check_empty_post($unauthorized_vars){
		$errors = array();//Tableau d'erreur vide
		foreach($unauthorized_vars as $value){
			if(empty($_POST[$value]) && $_POST[$value] != '0'){// si la valeur de poste est vide alors on l'ajoute aux erreurs
				$errors[] = $value;
			}
		}
		if(count($errors)){//si le tableau d'erreur n'est pas vide on retourne les erreurs sinon false
			return $errors;
		}else{
			return false;
		}
	}
	
//Exemple de tableau de champs obligatoire
	$unauthorized_vars = array(
		'login',
		'pass'
	);
	
//Exemple d'utilisation
	if($errors = check_empty_post($unauthorized_vars)){
		echo count($errors)." erreur(s).";
	}

?>

<?php //Pas super util mais je poste si quelqu'un a besoin
	
	function check_empty_post($unauthorized_vars,$error_string){
		$errors = array();
		foreach($unauthorized_vars as $value){
			if(empty($_POST[$value]) && $_POST[$value] != '0'){
				$errors[] = sprintf($error_string, $value);
			}
		}
		if(count($errors)){
			return $errors;
		}else{
			return false;
		}
	}
	
	$unauthorized_vars = array(
		'login',
		'pass'
	);
	$error_string = 'Le champs \'%s\' ne peut rester vide.<br />';
	
	if($errors = check_empty_post($unauthorized_vars, $error_string)){
		echo count($errors).' erreurs.<br />';
		foreach($errors as $value){
			echo $value;
		}
	}

?>

Conclusion :


Rien de révolutionnaire mais ça peut etre pratique.

A voir également

Ajouter un commentaire

Commentaires

Messages postés
592
Date d'inscription
samedi 19 janvier 2002
Statut
Membre
Dernière intervention
4 décembre 2008

(empty($_POST[$value]) && $_POST[$value] != '0')

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...
Messages postés
29
Date d'inscription
jeudi 26 juin 2003
Statut
Membre
Dernière intervention
10 mars 2009

Oui, mais là tu part du principe que j'attend forcément quelque chose de mes champs, qu'un tel soit email, un autre nombre, un autre url... mais dans le cas de champs obligatoire mais pas forcément spéciaux ça devient utile de tester si elle est remplie ou non et seulement ça.
Messages postés
39
Date d'inscription
jeudi 27 mai 2004
Statut
Membre
Dernière intervention
18 février 2008
2
... c'est bien ce que je disais ^^

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 !
Messages postés
29
Date d'inscription
jeudi 26 juin 2003
Statut
Membre
Dernière intervention
10 mars 2009

Tartuffe> Attention, il ne s'agissait pas ici d'un script pour s'assurer que les valeurs entrées correspondent à celles souhaitées (par ex. qu'un champs âge soit bien composé de chiffres uniquement) mais juste de savoir si elles sont remplies.
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.
Messages postés
39
Date d'inscription
jeudi 27 mai 2004
Statut
Membre
Dernière intervention
18 février 2008
2
LE problème de vérification des formulaires, c'est qu'il ne peut pas être automatisé avec seulement un test ISSET, car rapidement il est SET (d'autant si tu testes les valeurs retour et que tu ré-affiches dans les champs les valeurs envoyées, même les fausses avec un message d'erreur à l'utilisateur...).

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 ^^
Afficher les 16 commentaires

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.