lors d'un formulaire via une méthode post on doit vérifier que les variables du formulaire on bien été posté et stocker le résultat dans une variable.
je me demandais si c'était obligatoire car si on fait un formulaire avec beaucoup de post cela devient lourd.
De vérifier que $_REQUEST['cequetuveux'] existe et est correct, oui cela me semble indispensable (tu peux faire la même chose avec $_POST si tu préfères). Mais le mettre dans une autre variable, ce n'est pas forcément obligatoire, dans le cas où tu ne prévois pas de valeur par défaut et que la sanction d'un paramètre manquant est toujours la sortie immédiate du script.
Donc, tu peux très bien avoir : if (!isset($_REQUEST['foobar'])) die('Paramètre manquant'); if ($_REQUEST['foobar'] < 250) die('Paramètre trop petit'); if ($_REQUEST['foobar'] > 500) die('Paramètre trop grand'); ... etc. ... Puis : $calcul = 3 * $_REQUEST['foobar'] + 27; ... etc. ...
Mais tu peux avoir besoin de : $foobar = 300; /* valeur par défaut */ if (isset($_REQUEST['foobar'])) { if (($_REQUEST['foobar'] >= 250) && ($_REQUEST['foobar'] <= 500)) { $foobar = $_REQUEST['foobar']; } } ... etc. ... Puis : $calcul = 3 * $foobar + 27; ... etc. ...
lors d'un formulaire via une méthode post on doit vérifier que les
variables du formulaire on bien été posté et stocker le résultat dans une
variable.
je me demandais si c'était obligatoire car si on fait un formulaire avec
beaucoup de post cela devient lourd.
De vérifier que $_REQUEST['cequetuveux'] existe et est correct, oui
cela me semble indispensable (tu peux faire la même chose avec $_POST
si tu préfères). Mais le mettre dans une autre variable, ce n'est pas
forcément obligatoire, dans le cas où tu ne prévois pas de valeur par
défaut et que la sanction d'un paramètre manquant est toujours la sortie
immédiate du script.
Donc, tu peux très bien avoir :
if (!isset($_REQUEST['foobar'])) die('Paramètre manquant');
if ($_REQUEST['foobar'] < 250) die('Paramètre trop petit');
if ($_REQUEST['foobar'] > 500) die('Paramètre trop grand');
... etc. ...
Puis :
$calcul = 3 * $_REQUEST['foobar'] + 27;
... etc. ...
Mais tu peux avoir besoin de :
$foobar = 300; /* valeur par défaut */
if (isset($_REQUEST['foobar'])) {
if (($_REQUEST['foobar'] >= 250) && ($_REQUEST['foobar'] <= 500)) {
$foobar = $_REQUEST['foobar'];
}
}
... etc. ...
Puis :
$calcul = 3 * $foobar + 27;
... etc. ...
lors d'un formulaire via une méthode post on doit vérifier que les variables du formulaire on bien été posté et stocker le résultat dans une variable.
je me demandais si c'était obligatoire car si on fait un formulaire avec beaucoup de post cela devient lourd.
De vérifier que $_REQUEST['cequetuveux'] existe et est correct, oui cela me semble indispensable (tu peux faire la même chose avec $_POST si tu préfères). Mais le mettre dans une autre variable, ce n'est pas forcément obligatoire, dans le cas où tu ne prévois pas de valeur par défaut et que la sanction d'un paramètre manquant est toujours la sortie immédiate du script.
Donc, tu peux très bien avoir : if (!isset($_REQUEST['foobar'])) die('Paramètre manquant'); if ($_REQUEST['foobar'] < 250) die('Paramètre trop petit'); if ($_REQUEST['foobar'] > 500) die('Paramètre trop grand'); ... etc. ... Puis : $calcul = 3 * $_REQUEST['foobar'] + 27; ... etc. ...
Mais tu peux avoir besoin de : $foobar = 300; /* valeur par défaut */ if (isset($_REQUEST['foobar'])) { if (($_REQUEST['foobar'] >= 250) && ($_REQUEST['foobar'] <= 500)) { $foobar = $_REQUEST['foobar']; } } ... etc. ... Puis : $calcul = 3 * $foobar + 27; ... etc. ...
Mickael Wolff
je me demandais si c'était obligatoire car si on fait un formulaire avec beaucoup de post cela devient lourd.
Bien venue dans le monde de la programmation ;) Bien évidemment, tu peux automatiser les traitements. Personnellement, j'utilise un fichier XML qui décrit le formulaire, comme ça je fabriques le formulaire à l'aide de cet XML, et la vérification se fait automatiquement à partir de cette description.
Mais peut-être que d'autres ont des méthodes moins lourdes que d'utiliser un DOMDocument juste pour ça ;)
je me demandais si c'était obligatoire car si on fait un formulaire avec
beaucoup de post cela devient lourd.
Bien venue dans le monde de la programmation ;) Bien évidemment, tu
peux automatiser les traitements. Personnellement, j'utilise un fichier
XML qui décrit le formulaire, comme ça je fabriques le formulaire à
l'aide de cet XML, et la vérification se fait automatiquement à partir
de cette description.
Mais peut-être que d'autres ont des méthodes moins lourdes que
d'utiliser un DOMDocument juste pour ça ;)
je me demandais si c'était obligatoire car si on fait un formulaire avec beaucoup de post cela devient lourd.
Bien venue dans le monde de la programmation ;) Bien évidemment, tu peux automatiser les traitements. Personnellement, j'utilise un fichier XML qui décrit le formulaire, comme ça je fabriques le formulaire à l'aide de cet XML, et la vérification se fait automatiquement à partir de cette description.
Mais peut-être que d'autres ont des méthodes moins lourdes que d'utiliser un DOMDocument juste pour ça ;)
je me demandais si c'était obligatoire car si on fait un formulaire avec beaucoup de post cela devient lourd.
Bien venue dans le monde de la programmation ;) Bien évidemment, tu peux automatiser les traitements. Personnellement, j'utilise un fichier XML qui décrit le formulaire, comme ça je fabriques le formulaire à l'aide de cet XML, et la vérification se fait automatiquement à partir de cette description.
Mais peut-être que d'autres ont des méthodes moins lourdes que d'utiliser un DOMDocument juste pour ça ;)
++
j'en suis pas encore là!!!!
j'utilise isset pour les scripts de sessions, mais dans le cadre d'un formulaire normal a quoi ça sert réellement de tester si la variable existe.
finalement le seul controle indispensable d'un formulaire c'est de vérifier qu'il soit pas envoyé vide et de verifier que les élements saisie soit cohérant avec ce qui est demandé.
Mickael Wolff wrote:
je me demandais si c'était obligatoire car si on fait un formulaire avec
beaucoup de post cela devient lourd.
Bien venue dans le monde de la programmation ;) Bien évidemment, tu
peux automatiser les traitements. Personnellement, j'utilise un fichier
XML qui décrit le formulaire, comme ça je fabriques le formulaire à
l'aide de cet XML, et la vérification se fait automatiquement à partir
de cette description.
Mais peut-être que d'autres ont des méthodes moins lourdes que
d'utiliser un DOMDocument juste pour ça ;)
++
j'en suis pas encore là!!!!
j'utilise isset pour les scripts de sessions, mais dans le cadre d'un
formulaire normal a quoi ça sert réellement de tester si la variable
existe.
finalement le seul controle indispensable d'un formulaire c'est de vérifier
qu'il soit pas envoyé vide et de verifier que les élements saisie soit
cohérant avec ce qui est demandé.
je me demandais si c'était obligatoire car si on fait un formulaire avec beaucoup de post cela devient lourd.
Bien venue dans le monde de la programmation ;) Bien évidemment, tu peux automatiser les traitements. Personnellement, j'utilise un fichier XML qui décrit le formulaire, comme ça je fabriques le formulaire à l'aide de cet XML, et la vérification se fait automatiquement à partir de cette description.
Mais peut-être que d'autres ont des méthodes moins lourdes que d'utiliser un DOMDocument juste pour ça ;)
++
j'en suis pas encore là!!!!
j'utilise isset pour les scripts de sessions, mais dans le cadre d'un formulaire normal a quoi ça sert réellement de tester si la variable existe.
finalement le seul controle indispensable d'un formulaire c'est de vérifier qu'il soit pas envoyé vide et de verifier que les élements saisie soit cohérant avec ce qui est demandé.
Mickael Wolff
finalement le seul controle indispensable d'un formulaire c'est de vérifier qu'il soit pas envoyé vide et de verifier que les élements saisie soit cohérant avec ce qui est demandé.
Avant de savoir s'il est vide, il faut savoir s'il existe, et s'il est nécessaire de traiter l'absence, voir de générer une erreur. Parce que si tu tente d'accéder à un élément d'un tableau qui n'existe pas, tu dois avoir un Warning (sur ta machine de développement).
Ça évite aussi d'user d'une expression régulière alors qu'il n'y a pas besoin ;)
finalement le seul controle indispensable d'un formulaire c'est de vérifier
qu'il soit pas envoyé vide et de verifier que les élements saisie soit
cohérant avec ce qui est demandé.
Avant de savoir s'il est vide, il faut savoir s'il existe, et s'il est
nécessaire de traiter l'absence, voir de générer une erreur. Parce que
si tu tente d'accéder à un élément d'un tableau qui n'existe pas, tu
dois avoir un Warning (sur ta machine de développement).
Ça évite aussi d'user d'une expression régulière alors qu'il n'y a pas
besoin ;)
finalement le seul controle indispensable d'un formulaire c'est de vérifier qu'il soit pas envoyé vide et de verifier que les élements saisie soit cohérant avec ce qui est demandé.
Avant de savoir s'il est vide, il faut savoir s'il existe, et s'il est nécessaire de traiter l'absence, voir de générer une erreur. Parce que si tu tente d'accéder à un élément d'un tableau qui n'existe pas, tu dois avoir un Warning (sur ta machine de développement).
Ça évite aussi d'user d'une expression régulière alors qu'il n'y a pas besoin ;)
j'utilise isset pour les scripts de sessions, mais dans le cadre d'un formulaire normal a quoi ça sert réellement de tester si la variable existe.
A vérifier qu'elle a été positionnée, et éventuellement que sa valeur est correcte. Valider les entrées utilisateurs est une part non-négligeable et *indispensable* de l'implémentation d'un programme. Si tu laisses entrer n'importe quoi, tu vas au devant de sérieux ennuis.
finalement le seul controle indispensable d'un formulaire c'est de vérifier qu'il soit pas envoyé vide et de verifier que les élements saisie soit cohérant avec ce qui est demandé.
Et que ce ne soit pas une tentative d'attaque de ton système, accessoirement... Maintenant, quelque chose m'échappe : comment veux-tu vérifier que le formulaire n'est pas posté vide et que les éléments saisis sont cohérents avec ce qui est demandé *sans* vérifier que les "variables" du formulaires ont bien été renseignées ???
(snip)
j'utilise isset pour les scripts de sessions, mais dans le cadre d'un
formulaire normal a quoi ça sert réellement de tester si la variable
existe.
A vérifier qu'elle a été positionnée, et éventuellement que sa valeur
est correcte. Valider les entrées utilisateurs est une part
non-négligeable et *indispensable* de l'implémentation d'un programme.
Si tu laisses entrer n'importe quoi, tu vas au devant de sérieux ennuis.
finalement le seul controle indispensable d'un formulaire c'est de vérifier
qu'il soit pas envoyé vide et de verifier que les élements saisie soit
cohérant avec ce qui est demandé.
Et que ce ne soit pas une tentative d'attaque de ton système,
accessoirement... Maintenant, quelque chose m'échappe : comment veux-tu
vérifier que le formulaire n'est pas posté vide et que les éléments
saisis sont cohérents avec ce qui est demandé *sans* vérifier que les
"variables" du formulaires ont bien été renseignées ???
j'utilise isset pour les scripts de sessions, mais dans le cadre d'un formulaire normal a quoi ça sert réellement de tester si la variable existe.
A vérifier qu'elle a été positionnée, et éventuellement que sa valeur est correcte. Valider les entrées utilisateurs est une part non-négligeable et *indispensable* de l'implémentation d'un programme. Si tu laisses entrer n'importe quoi, tu vas au devant de sérieux ennuis.
finalement le seul controle indispensable d'un formulaire c'est de vérifier qu'il soit pas envoyé vide et de verifier que les élements saisie soit cohérant avec ce qui est demandé.
Et que ce ne soit pas une tentative d'attaque de ton système, accessoirement... Maintenant, quelque chose m'échappe : comment veux-tu vérifier que le formulaire n'est pas posté vide et que les éléments saisis sont cohérents avec ce qui est demandé *sans* vérifier que les "variables" du formulaires ont bien été renseignées ???
Mihamina (R12y) Rakotomandimby
Bruno Desthuilliers wrote:
Et que ce ne soit pas une tentative d'attaque de ton système, accessoirement... Maintenant, quelque chose m'échappe : comment veux-tu vérifier que le formulaire n'est pas posté vide et que les éléments saisis sont cohérents avec ce qui est demandé *sans* vérifier que les "variables" du formulaires ont bien été renseignées ???
Quand on a une page "multi formulaire" mal foutue, c'est à dire ou l'on a plusieurs groupes de champs mais seul un groupe porte des données utiles, alors il veut pouvoir ne considérer que les champs du groupe en question. C'est un exemple d'usage qui m'est venu comme ça, on the fly. Mais pour ça il faut que le formulaire soit mal foutu.
Bruno Desthuilliers wrote:
Et que ce ne soit pas une tentative d'attaque de ton système,
accessoirement... Maintenant, quelque chose m'échappe : comment veux-tu
vérifier que le formulaire n'est pas posté vide et que les éléments
saisis sont cohérents avec ce qui est demandé *sans* vérifier que les
"variables" du formulaires ont bien été renseignées ???
Quand on a une page "multi formulaire" mal foutue, c'est à dire ou l'on
a plusieurs groupes de champs mais seul un groupe porte des données
utiles, alors il veut pouvoir ne considérer que les champs du groupe en
question.
C'est un exemple d'usage qui m'est venu comme ça, on the fly.
Mais pour ça il faut que le formulaire soit mal foutu.
Et que ce ne soit pas une tentative d'attaque de ton système, accessoirement... Maintenant, quelque chose m'échappe : comment veux-tu vérifier que le formulaire n'est pas posté vide et que les éléments saisis sont cohérents avec ce qui est demandé *sans* vérifier que les "variables" du formulaires ont bien été renseignées ???
Quand on a une page "multi formulaire" mal foutue, c'est à dire ou l'on a plusieurs groupes de champs mais seul un groupe porte des données utiles, alors il veut pouvoir ne considérer que les champs du groupe en question. C'est un exemple d'usage qui m'est venu comme ça, on the fly. Mais pour ça il faut que le formulaire soit mal foutu.
Olivier Masson
Avant de savoir s'il est vide, il faut savoir s'il existe, et s'il est nécessaire de traiter l'absence, voir de générer une erreur. Parce que si tu tente d'accéder à un élément d'un tableau qui n'existe pas, tu dois avoir un Warning (sur ta machine de développement).
Est-ce vraiment gênant de supprimer la vérif isset ? Si lors de la vérif des valeurs on utilise @, quel est le soucis ? Personnellement (ce qui est donc tout sauf un gage de qualité :)), j'utilise foreach ou array_map soit sur toutes les valeurs, soit sur un tableau qui contient toutes les valeurs que je souhaite vérifier.
Avant de savoir s'il est vide, il faut savoir s'il existe, et s'il est
nécessaire de traiter l'absence, voir de générer une erreur. Parce que
si tu tente d'accéder à un élément d'un tableau qui n'existe pas, tu
dois avoir un Warning (sur ta machine de développement).
Est-ce vraiment gênant de supprimer la vérif isset ?
Si lors de la vérif des valeurs on utilise @, quel est le soucis ?
Personnellement (ce qui est donc tout sauf un gage de qualité :)),
j'utilise foreach ou array_map soit sur toutes les valeurs, soit sur un
tableau qui contient toutes les valeurs que je souhaite vérifier.
Avant de savoir s'il est vide, il faut savoir s'il existe, et s'il est nécessaire de traiter l'absence, voir de générer une erreur. Parce que si tu tente d'accéder à un élément d'un tableau qui n'existe pas, tu dois avoir un Warning (sur ta machine de développement).
Est-ce vraiment gênant de supprimer la vérif isset ? Si lors de la vérif des valeurs on utilise @, quel est le soucis ? Personnellement (ce qui est donc tout sauf un gage de qualité :)), j'utilise foreach ou array_map soit sur toutes les valeurs, soit sur un tableau qui contient toutes les valeurs que je souhaite vérifier.
Mickael Wolff
Est-ce vraiment gênant de supprimer la vérif isset ?
Ça dépend de ta psychorigidité ^^; Mais personnellement, je n'utilises jamais isset, mais array_key_exists. Ça vient du fait que je ne comprends pas pourquoi isset($toto['tata']) ne lève pas une exception si la clé tata n'existe pas.
Si lors de la vérif des valeurs on utilise @, quel est le soucis ?
Je n'aime pas ignorer les erreurs, warnings ou notices. C'est le meilleurs moyen de tourner en rond pendant des heures autour d'un problème résolvable en 30 s. Mais chacun ces passions ;)
Personnellement (ce qui est donc tout sauf un gage de qualité :)), j'utilise foreach ou array_map soit sur toutes les valeurs, soit sur un tableau qui contient toutes les valeurs que je souhaite vérifier.
Comme toujours, ça dépend comment tu gères derrière.
Est-ce vraiment gênant de supprimer la vérif isset ?
Ça dépend de ta psychorigidité ^^; Mais personnellement, je n'utilises
jamais isset, mais array_key_exists. Ça vient du fait que je ne
comprends pas pourquoi isset($toto['tata']) ne lève pas une exception si
la clé tata n'existe pas.
Si lors de la vérif des valeurs on utilise @, quel est le soucis ?
Je n'aime pas ignorer les erreurs, warnings ou notices. C'est le
meilleurs moyen de tourner en rond pendant des heures autour d'un
problème résolvable en 30 s. Mais chacun ces passions ;)
Personnellement (ce qui est donc tout sauf un gage de qualité :)),
j'utilise foreach ou array_map soit sur toutes les valeurs, soit sur un
tableau qui contient toutes les valeurs que je souhaite vérifier.
Comme toujours, ça dépend comment tu gères derrière.
Est-ce vraiment gênant de supprimer la vérif isset ?
Ça dépend de ta psychorigidité ^^; Mais personnellement, je n'utilises jamais isset, mais array_key_exists. Ça vient du fait que je ne comprends pas pourquoi isset($toto['tata']) ne lève pas une exception si la clé tata n'existe pas.
Si lors de la vérif des valeurs on utilise @, quel est le soucis ?
Je n'aime pas ignorer les erreurs, warnings ou notices. C'est le meilleurs moyen de tourner en rond pendant des heures autour d'un problème résolvable en 30 s. Mais chacun ces passions ;)
Personnellement (ce qui est donc tout sauf un gage de qualité :)), j'utilise foreach ou array_map soit sur toutes les valeurs, soit sur un tableau qui contient toutes les valeurs que je souhaite vérifier.
Comme toujours, ça dépend comment tu gères derrière.
Si lors de la vérif des valeurs on utilise @, quel est le soucis ?
Je n'aime pas ignorer les erreurs, warnings ou notices. C'est le meilleurs moyen de tourner en rond pendant des heures autour d'un problème résolvable en 30 s. Mais chacun ces passions ;)
Chez certains hébergeurs, à partir d'un certain nombre d'erreurs ou warning masqués par @, il y a blocage du ou des scripts litigieux. C'est ce qui se passe chez Free. -- Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi Technologie aéronautique : http://aviatechno.free.fr (http://ottello.net) Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr
Si lors de la vérif des valeurs on utilise @, quel est le soucis ?
Je n'aime pas ignorer les erreurs, warnings ou notices. C'est le
meilleurs moyen de tourner en rond pendant des heures autour d'un
problème résolvable en 30 s. Mais chacun ces passions ;)
Chez certains hébergeurs, à partir d'un certain nombre d'erreurs ou
warning masqués par @, il y a blocage du ou des scripts litigieux.
C'est ce qui se passe chez Free.
--
Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi
Technologie aéronautique : http://aviatechno.free.fr (http://ottello.net)
Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr
Si lors de la vérif des valeurs on utilise @, quel est le soucis ?
Je n'aime pas ignorer les erreurs, warnings ou notices. C'est le meilleurs moyen de tourner en rond pendant des heures autour d'un problème résolvable en 30 s. Mais chacun ces passions ;)
Chez certains hébergeurs, à partir d'un certain nombre d'erreurs ou warning masqués par @, il y a blocage du ou des scripts litigieux. C'est ce qui se passe chez Free. -- Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi Technologie aéronautique : http://aviatechno.free.fr (http://ottello.net) Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr
Olivier Masson
Chez certains hébergeurs, à partir d'un certain nombre d'erreurs ou warning masqués par @, il y a blocage du ou des scripts litigieux. C'est ce qui se passe chez Free.
C'est-à-dire ? Ce n'est pas le blocage qui m'intéresse (j'utilise peu le @ et pas free) mais la façon dont c'est détecté : ils parsent les scripts ou c'est php qui peut renvoyer en silent les erreurs ignorées par le @ ?
Chez certains hébergeurs, à partir d'un certain nombre d'erreurs ou
warning masqués par @, il y a blocage du ou des scripts litigieux.
C'est ce qui se passe chez Free.
C'est-à-dire ? Ce n'est pas le blocage qui m'intéresse (j'utilise peu le
@ et pas free) mais la façon dont c'est détecté : ils parsent les
scripts ou c'est php qui peut renvoyer en silent les erreurs ignorées
par le @ ?
Chez certains hébergeurs, à partir d'un certain nombre d'erreurs ou warning masqués par @, il y a blocage du ou des scripts litigieux. C'est ce qui se passe chez Free.
C'est-à-dire ? Ce n'est pas le blocage qui m'intéresse (j'utilise peu le @ et pas free) mais la façon dont c'est détecté : ils parsent les scripts ou c'est php qui peut renvoyer en silent les erreurs ignorées par le @ ?
