je suis en train de me plonger dans PHP et suis sur le point de
finaliser un projet modeste pour lequel je me suis aidé du livre « PHP
& MySQL, Développement de sites Web » de Larry Ullman.
Mon problème est que, si je parviens sans problème à tester la
validité d'un formulaire côté serveur si le script « s'appelle
lui-même », je ne pas comment procéder si le script en appelle un
autre lorsque l'utilisateur appuie sur le bouton de type « submit
». Pour résumer, voici la structure de mon code :
<?php
// script script_php_1.php
if (isset($_POST['submit'])) { // Si le formulaire a été soumis
$message = NULL;
if ($_POST['champ1'] pas OK){
$champ1 = FALSE;
$message .= "<p>Le champ 1 ne va pas</p>";
}
else {
$champ1 = escape_data($_POST['champ1']);
}
if ($_POST['champ2'] pas OK){
$champ2 = FALSE;
$message .= "<p>Le champ 2 ne va pas</p>";
}
else {
$champ2 = escape_data($_POST['champ2']);
}
if ($message==NULL) { // Tout est OK
$_SESSION['champ1'] = $champ1;
$_SESSION['champ2'] = $champ2;
}
else { // L'un des deux champs au moins ne va pas
echo "$message";
}
}
?>
tout va bien mais, dans le cas contraire (celui du script ci-dessus),
l'utilisateur arrive au script script_php_2.php avec des champs champs
champ1 et
champ2 éventuellement non valides, sans qu'il en ait été empêché.
J'ai eu beau chercher dans les forums (où il y a pléthore de fils au
sujet de la validation de formulaires) et les divers tutoriaux du Web,
je n'ai rien trouvé lorsque, donc, le formulaire appelle un autre
script.
je suis en train de me plonger dans PHP et suis sur le point de finaliser un projet modeste pour lequel je me suis aidé du livre « PHP & MySQL, Développement de sites Web » de Larry Ullman.
Mon problème est que, si je parviens sans problème à tester la validité d'un formulaire côté serveur si le script « s'appelle lui-même », je ne pas comment procéder si le script en appelle un autre lorsque l'utilisateur appuie sur le bouton de type « submit ».
En mettant la validation dans le script appelé, ça marcherait probablement mieux...
tout va bien mais, dans le cas contraire (celui du script ci-dessus), l'utilisateur arrive au script script_php_2.php
C'est normal, c'est toi qui l'y envoie.
avec des champs champs champ1 et champ2 éventuellement non valides, sans qu'il en ait été empêché.
J'ai eu beau chercher dans les forums (où il y a pléthore de fils au sujet de la validation de formulaires) et les divers tutoriaux du Web, je n'ai rien trouvé lorsque, donc, le formulaire appelle un autre script.
Ce n'est pas un problème de "même" ou "d'autre" script. Un formulaire est posté à l'adresse indiquée dans l'attribut "action" du formulaire, point barre. Que cette adresse corresponde ou non au script ayant généré le formulaire est sans la moindre incidence.
La solution consiste bien sûr à disjoindre le script effectuant la validation de celui affichant le formulaire [1] - libre au premier de faire un include du second, ou de prendre toute autre action appropriée (ce qui peut être par exemple fonction d'un champ - caché - du formulaire, si le même script de validation doit être utilisable dans plusieurs contextes).
[1] ce qui devrait être de toutes façons le cas si l'on s'applique à séparer les traitements de la présentation.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Denis Bitouze wrote:
Bonjour,
je suis en train de me plonger dans PHP et suis sur le point de
finaliser un projet modeste pour lequel je me suis aidé du livre « PHP
& MySQL, Développement de sites Web » de Larry Ullman.
Mon problème est que, si je parviens sans problème à tester la
validité d'un formulaire côté serveur si le script « s'appelle
lui-même », je ne pas comment procéder si le script en appelle un
autre lorsque l'utilisateur appuie sur le bouton de type « submit
».
En mettant la validation dans le script appelé, ça marcherait
probablement mieux...
tout va bien mais, dans le cas contraire (celui du script ci-dessus),
l'utilisateur arrive au script script_php_2.php
C'est normal, c'est toi qui l'y envoie.
avec des champs champs
champ1 et
champ2 éventuellement non valides, sans qu'il en ait été empêché.
J'ai eu beau chercher dans les forums (où il y a pléthore de fils au
sujet de la validation de formulaires) et les divers tutoriaux du Web,
je n'ai rien trouvé lorsque, donc, le formulaire appelle un autre
script.
Ce n'est pas un problème de "même" ou "d'autre" script. Un formulaire
est posté à l'adresse indiquée dans l'attribut "action" du formulaire,
point barre. Que cette adresse corresponde ou non au script ayant généré
le formulaire est sans la moindre incidence.
La solution consiste bien sûr à disjoindre le script effectuant la
validation de celui affichant le formulaire [1] - libre au premier de
faire un include du second, ou de prendre toute autre action appropriée
(ce qui peut être par exemple fonction d'un champ - caché - du
formulaire, si le même script de validation doit être utilisable dans
plusieurs contextes).
[1] ce qui devrait être de toutes façons le cas si l'on s'applique à
séparer les traitements de la présentation.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
je suis en train de me plonger dans PHP et suis sur le point de finaliser un projet modeste pour lequel je me suis aidé du livre « PHP & MySQL, Développement de sites Web » de Larry Ullman.
Mon problème est que, si je parviens sans problème à tester la validité d'un formulaire côté serveur si le script « s'appelle lui-même », je ne pas comment procéder si le script en appelle un autre lorsque l'utilisateur appuie sur le bouton de type « submit ».
En mettant la validation dans le script appelé, ça marcherait probablement mieux...
tout va bien mais, dans le cas contraire (celui du script ci-dessus), l'utilisateur arrive au script script_php_2.php
C'est normal, c'est toi qui l'y envoie.
avec des champs champs champ1 et champ2 éventuellement non valides, sans qu'il en ait été empêché.
J'ai eu beau chercher dans les forums (où il y a pléthore de fils au sujet de la validation de formulaires) et les divers tutoriaux du Web, je n'ai rien trouvé lorsque, donc, le formulaire appelle un autre script.
Ce n'est pas un problème de "même" ou "d'autre" script. Un formulaire est posté à l'adresse indiquée dans l'attribut "action" du formulaire, point barre. Que cette adresse corresponde ou non au script ayant généré le formulaire est sans la moindre incidence.
La solution consiste bien sûr à disjoindre le script effectuant la validation de celui affichant le formulaire [1] - libre au premier de faire un include du second, ou de prendre toute autre action appropriée (ce qui peut être par exemple fonction d'un champ - caché - du formulaire, si le même script de validation doit être utilisable dans plusieurs contextes).
[1] ce qui devrait être de toutes façons le cas si l'on s'applique à séparer les traitements de la présentation.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Denis Bitouze
Le 26 sep 2006 à 12h25
En mettant la validation dans le script appelé, ça marcherait probablement mieux...
Mon souci est de faire en sorte que, tant que le formulaire n'est pas validé, l'utilisateur « reste » sur la page qui affiche ce formulaire (avec, en plus, un message indiquant ce qui ne va pas) et que, une fois le formulaire validé, il soit envoyé sur le second script. Or, si « la validation [a lieu] dans le script appelé » (ce que j'appelle le second script si j'ai bien compris), c'est un peu tard pour afficher à nouveau le formulaire non validé, non ? Je précise que, sur la deuxième page sur laquelle arrive l'utilisateur une fois le (premier) formulaire validé, se trouve un second formulaire dont les champs dépendent de ce qui a été saisi sur le premier formulaire.
tout va bien mais, dans le cas contraire (celui du script ci-dessus), l'utilisateur arrive au script script_php_2.php
C'est normal, c'est toi qui l'y envoie.
Oui, ça, j'avais remarqué ;)
Je vais examiner en détail les pistes de disjonction du script effectuant la validation de celui affichant le formulaire (j'aime la séparation fond/forme ;)
Merci ! -- Denis
Le 26 sep 2006 à 12h25
En mettant la validation dans le script appelé, ça marcherait
probablement mieux...
Mon souci est de faire en sorte que, tant que le formulaire n'est pas
validé, l'utilisateur « reste » sur la page qui affiche ce formulaire
(avec, en plus, un message indiquant ce qui ne va pas) et que, une
fois le formulaire validé, il soit envoyé sur le second script. Or, si
« la validation [a lieu] dans le script appelé » (ce que j'appelle le
second script si j'ai bien compris), c'est un peu tard pour afficher à
nouveau le formulaire non validé, non ? Je précise que, sur la
deuxième page sur laquelle arrive l'utilisateur une fois le (premier)
formulaire validé, se trouve un second formulaire dont les champs
dépendent de ce qui a été saisi sur le premier formulaire.
tout va bien mais, dans le cas contraire (celui du script
ci-dessus), l'utilisateur arrive au script script_php_2.php
C'est normal, c'est toi qui l'y envoie.
Oui, ça, j'avais remarqué ;)
Je vais examiner en détail les pistes de disjonction du script
effectuant la
validation de celui affichant le formulaire (j'aime la séparation
fond/forme ;)
En mettant la validation dans le script appelé, ça marcherait probablement mieux...
Mon souci est de faire en sorte que, tant que le formulaire n'est pas validé, l'utilisateur « reste » sur la page qui affiche ce formulaire (avec, en plus, un message indiquant ce qui ne va pas) et que, une fois le formulaire validé, il soit envoyé sur le second script. Or, si « la validation [a lieu] dans le script appelé » (ce que j'appelle le second script si j'ai bien compris), c'est un peu tard pour afficher à nouveau le formulaire non validé, non ? Je précise que, sur la deuxième page sur laquelle arrive l'utilisateur une fois le (premier) formulaire validé, se trouve un second formulaire dont les champs dépendent de ce qui a été saisi sur le premier formulaire.
tout va bien mais, dans le cas contraire (celui du script ci-dessus), l'utilisateur arrive au script script_php_2.php
C'est normal, c'est toi qui l'y envoie.
Oui, ça, j'avais remarqué ;)
Je vais examiner en détail les pistes de disjonction du script effectuant la validation de celui affichant le formulaire (j'aime la séparation fond/forme ;)
Merci ! -- Denis
Bruno Desthuilliers
Denis Bitouze wrote:
Le 26 sep 2006 à 12h25
En mettant la validation dans le script appelé, ça marcherait probablement mieux...
Mon souci est de faire en sorte que, tant que le formulaire n'est pas validé, l'utilisateur « reste » sur la page qui affiche ce formulaire (avec, en plus, un message indiquant ce qui ne va pas) et que, une fois le formulaire validé, il soit envoyé sur le second script. Or, si « la validation [a lieu] dans le script appelé » (ce que j'appelle le second script si j'ai bien compris), c'est un peu tard pour afficher à nouveau le formulaire non validé, non ?
Bon, reprenons... Il n'est en rien nécessaire que ce soit le même *script* (ie: script != page) qui se charge de l'affichage et du traitement du formulaire. Le second (appellons le "traitement.php") peut très bien, selon que la saisie est ok ou pas, soit inclure un autre script (par exemple celui qui génère le formulaire), soit rediriger vers une autre page.
Je précise que, sur la deuxième page sur laquelle arrive l'utilisateur une fois le (premier) formulaire validé, se trouve un second formulaire dont les champs dépendent de ce qui a été saisi sur le premier formulaire.
Oui, c'est un "wizard". Raison de plus pour séparer la validation de la génération.
Une solution possible est d'avoir - un controleur principal pour tout le wizard, qui se charge, selon l'étape en cours, d'envoyer vers l'étape suivante - un jeu de scripts de génération de formulaire - un jeu de fonctions de validations.
Le controleur principal peut être très simple en fait:
<?php if (la_methode_http == "POST") { $etape = $_POST['etape']; if (!empty($etape)) { inclure("traitements/etape{$etape}.php"); // chaque fichier traitements/etapeXXX.php définit // une fonction ValiderEtape() qui fait la validation // et positionne les variables qui vont bien if (ValiderEtape()) { $etape +=1; } } } if (empty($etape)) { $etape = 1; } include("forms/etape{$etape}.php); ?>
Tu peux éventuellement améliorer le principe en faisant en sorte que ce soit le ValiderEtape qui détermine l'étape suivante en fonction des choix déjà effectués, voire construire une machine à état pour gérer le tout...
HTH
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Denis Bitouze wrote:
Le 26 sep 2006 à 12h25
En mettant la validation dans le script appelé, ça marcherait
probablement mieux...
Mon souci est de faire en sorte que, tant que le formulaire n'est pas
validé, l'utilisateur « reste » sur la page qui affiche ce formulaire
(avec, en plus, un message indiquant ce qui ne va pas) et que, une
fois le formulaire validé, il soit envoyé sur le second script. Or, si
« la validation [a lieu] dans le script appelé » (ce que j'appelle le
second script si j'ai bien compris), c'est un peu tard pour afficher à
nouveau le formulaire non validé, non ?
Bon, reprenons... Il n'est en rien nécessaire que ce soit le même
*script* (ie: script != page) qui se charge de l'affichage et du
traitement du formulaire. Le second (appellons le "traitement.php") peut
très bien, selon que la saisie est ok ou pas, soit inclure un autre
script (par exemple celui qui génère le formulaire), soit rediriger vers
une autre page.
Je précise que, sur la
deuxième page sur laquelle arrive l'utilisateur une fois le (premier)
formulaire validé, se trouve un second formulaire dont les champs
dépendent de ce qui a été saisi sur le premier formulaire.
Oui, c'est un "wizard". Raison de plus pour séparer la validation de la
génération.
Une solution possible est d'avoir
- un controleur principal pour tout le wizard, qui se charge, selon
l'étape en cours, d'envoyer vers l'étape suivante
- un jeu de scripts de génération de formulaire
- un jeu de fonctions de validations.
Le controleur principal peut être très simple en fait:
<?php
if (la_methode_http == "POST") {
$etape = $_POST['etape'];
if (!empty($etape)) {
inclure("traitements/etape{$etape}.php");
// chaque fichier traitements/etapeXXX.php définit
// une fonction ValiderEtape() qui fait la validation
// et positionne les variables qui vont bien
if (ValiderEtape()) {
$etape +=1;
}
}
}
if (empty($etape)) {
$etape = 1;
}
include("forms/etape{$etape}.php);
?>
Tu peux éventuellement améliorer le principe en faisant en sorte que ce
soit le ValiderEtape qui détermine l'étape suivante en fonction des
choix déjà effectués, voire construire une machine à état pour gérer le
tout...
HTH
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
En mettant la validation dans le script appelé, ça marcherait probablement mieux...
Mon souci est de faire en sorte que, tant que le formulaire n'est pas validé, l'utilisateur « reste » sur la page qui affiche ce formulaire (avec, en plus, un message indiquant ce qui ne va pas) et que, une fois le formulaire validé, il soit envoyé sur le second script. Or, si « la validation [a lieu] dans le script appelé » (ce que j'appelle le second script si j'ai bien compris), c'est un peu tard pour afficher à nouveau le formulaire non validé, non ?
Bon, reprenons... Il n'est en rien nécessaire que ce soit le même *script* (ie: script != page) qui se charge de l'affichage et du traitement du formulaire. Le second (appellons le "traitement.php") peut très bien, selon que la saisie est ok ou pas, soit inclure un autre script (par exemple celui qui génère le formulaire), soit rediriger vers une autre page.
Je précise que, sur la deuxième page sur laquelle arrive l'utilisateur une fois le (premier) formulaire validé, se trouve un second formulaire dont les champs dépendent de ce qui a été saisi sur le premier formulaire.
Oui, c'est un "wizard". Raison de plus pour séparer la validation de la génération.
Une solution possible est d'avoir - un controleur principal pour tout le wizard, qui se charge, selon l'étape en cours, d'envoyer vers l'étape suivante - un jeu de scripts de génération de formulaire - un jeu de fonctions de validations.
Le controleur principal peut être très simple en fait:
<?php if (la_methode_http == "POST") { $etape = $_POST['etape']; if (!empty($etape)) { inclure("traitements/etape{$etape}.php"); // chaque fichier traitements/etapeXXX.php définit // une fonction ValiderEtape() qui fait la validation // et positionne les variables qui vont bien if (ValiderEtape()) { $etape +=1; } } } if (empty($etape)) { $etape = 1; } include("forms/etape{$etape}.php); ?>
Tu peux éventuellement améliorer le principe en faisant en sorte que ce soit le ValiderEtape qui détermine l'étape suivante en fonction des choix déjà effectués, voire construire une machine à état pour gérer le tout...
HTH
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
David JOURAND
Le Tue, 26 Sep 2006 15:36:56 +0000, Denis Bitouze a écrit :
Mon souci est de faire en sorte que, tant que le formulaire n'est pas validé, l'utilisateur « reste » sur la page qui affiche ce formulaire (avec, en plus, un message indiquant ce qui ne va pas) et que, une fois le formulaire validé, il soit envoyé sur le second script. Or, si « la validation [a lieu] dans le script appelé » (ce que j'appelle le second script si j'ai bien compris), c'est un peu tard pour afficher à nouveau le formulaire non validé, non ? Je précise que, sur la deuxième page sur laquelle arrive l'utilisateur une fois le (premier) formulaire validé, se trouve un second formulaire dont les champs dépendent de ce qui a été saisi sur le premier formulaire.
index1.php :
if (formulaire1 pas bon) { include('form1.php'); } else { include('form2.php'); }
form1.php :
<form action='index1.php' method='post'>
form2.php :
<form action='index2.php' method='post'>
index2.php :
if (formulaire2 pas bon) { include('form2.php'); } else { include('done.php'); }
done.php :
Terminer !
Pour une solution plus élaborée : framework MVC.
-- David JOURAND - http://www.numabilis.com Supprimer "site." et ".invalid" de mon adresse mail pour me répondre.
Le Tue, 26 Sep 2006 15:36:56 +0000, Denis Bitouze a écrit :
Mon souci est de faire en sorte que, tant que le formulaire n'est pas
validé, l'utilisateur « reste » sur la page qui affiche ce formulaire
(avec, en plus, un message indiquant ce qui ne va pas) et que, une fois le
formulaire validé, il soit envoyé sur le second script. Or, si « la
validation [a lieu] dans le script appelé » (ce que j'appelle le second
script si j'ai bien compris), c'est un peu tard pour afficher à nouveau
le formulaire non validé, non ? Je précise que, sur la deuxième page
sur laquelle arrive l'utilisateur une fois le (premier) formulaire
validé, se trouve un second formulaire dont les champs dépendent de ce
qui a été saisi sur le premier formulaire.
index1.php :
if (formulaire1 pas bon) {
include('form1.php');
} else {
include('form2.php');
}
form1.php :
<form action='index1.php' method='post'>
form2.php :
<form action='index2.php' method='post'>
index2.php :
if (formulaire2 pas bon) {
include('form2.php');
} else {
include('done.php');
}
done.php :
Terminer !
Pour une solution plus élaborée : framework MVC.
--
David JOURAND - http://www.numabilis.com
Supprimer "site." et ".invalid" de mon adresse mail pour me répondre.
Le Tue, 26 Sep 2006 15:36:56 +0000, Denis Bitouze a écrit :
Mon souci est de faire en sorte que, tant que le formulaire n'est pas validé, l'utilisateur « reste » sur la page qui affiche ce formulaire (avec, en plus, un message indiquant ce qui ne va pas) et que, une fois le formulaire validé, il soit envoyé sur le second script. Or, si « la validation [a lieu] dans le script appelé » (ce que j'appelle le second script si j'ai bien compris), c'est un peu tard pour afficher à nouveau le formulaire non validé, non ? Je précise que, sur la deuxième page sur laquelle arrive l'utilisateur une fois le (premier) formulaire validé, se trouve un second formulaire dont les champs dépendent de ce qui a été saisi sur le premier formulaire.
index1.php :
if (formulaire1 pas bon) { include('form1.php'); } else { include('form2.php'); }
form1.php :
<form action='index1.php' method='post'>
form2.php :
<form action='index2.php' method='post'>
index2.php :
if (formulaire2 pas bon) { include('form2.php'); } else { include('done.php'); }
done.php :
Terminer !
Pour une solution plus élaborée : framework MVC.
-- David JOURAND - http://www.numabilis.com Supprimer "site." et ".invalid" de mon adresse mail pour me répondre.
Denis Bitouze
Le 26 sep 2006 à 20h56
soit rediriger vers une autre page.
J'avais songé à cela mais le seul outil que j'ai trouvé pour rediriger vers une autre page est headers mais, avec ça, je ne parvenais pas à conserver les données qui avaient été saisies dans le premier formulaire. Y a-t-il une autre possibilité pour rediriger vers une autre page ?
En attendant, j'examine la solution que tu proposes.
Merci ! -- Denis
Le 26 sep 2006 à 20h56
soit rediriger vers
une autre page.
J'avais songé à cela mais le seul outil que j'ai trouvé pour rediriger
vers une autre page est headers mais, avec ça, je ne parvenais pas à
conserver les données qui avaient été saisies dans le premier
formulaire. Y a-t-il une autre possibilité pour rediriger vers une
autre page ?
En attendant, j'examine la solution que tu proposes.
J'avais songé à cela mais le seul outil que j'ai trouvé pour rediriger vers une autre page est headers mais, avec ça, je ne parvenais pas à conserver les données qui avaient été saisies dans le premier formulaire. Y a-t-il une autre possibilité pour rediriger vers une autre page ?
En attendant, j'examine la solution que tu proposes.
Merci ! -- Denis
Denis Bitouze
Le 26 sep 2006 à 20h56
[...] Terminer !
OK, j'examine cela...
Pour une solution plus élaborée : framework MVC.
Houla, j'ai jeté un coup d'oeil mais je n'ai plus le temps de me plonger là dedans (dommage, si j'avais eu connaissance de cela au début, j'aurais essayé).
Merci ! -- Denis
Le 26 sep 2006 à 20h56
[...]
Terminer !
OK, j'examine cela...
Pour une solution plus élaborée : framework MVC.
Houla, j'ai jeté un coup d'oeil mais je n'ai plus le temps de me
plonger là dedans (dommage, si j'avais eu connaissance de cela au
début, j'aurais essayé).
Houla, j'ai jeté un coup d'oeil mais je n'ai plus le temps de me plonger là dedans (dommage, si j'avais eu connaissance de cela au début, j'aurais essayé).
Merci ! -- Denis
Bruno Desthuilliers
Denis Bitouze wrote:
Le 26 sep 2006 à 20h56
soit rediriger vers une autre page.
J'avais songé à cela mais le seul outil que j'ai trouvé pour rediriger vers une autre page est headers mais, avec ça, je ne parvenais pas à conserver les données qui avaient été saisies dans le premier formulaire.
Pour ça, il faudrait utiliser les sessions. Mais tu n'en n'a pas besoin ici - il te suffit, dans chaque formulaire "d'étape", de stocker les saisies déjà validées dans des champs cachés.
Y a-t-il une autre possibilité pour rediriger vers une autre page ?
En PHP ? Pas à ma connaissance (je parles bien de redirection HTTP).
En attendant, j'examine la solution que tu proposes.
Merci !
De rien.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Denis Bitouze wrote:
Le 26 sep 2006 à 20h56
soit rediriger vers
une autre page.
J'avais songé à cela mais le seul outil que j'ai trouvé pour rediriger
vers une autre page est headers mais, avec ça, je ne parvenais pas à
conserver les données qui avaient été saisies dans le premier
formulaire.
Pour ça, il faudrait utiliser les sessions. Mais tu n'en n'a pas besoin
ici - il te suffit, dans chaque formulaire "d'étape", de stocker les
saisies déjà validées dans des champs cachés.
Y a-t-il une autre possibilité pour rediriger vers une
autre page ?
En PHP ? Pas à ma connaissance (je parles bien de redirection HTTP).
En attendant, j'examine la solution que tu proposes.
Merci !
De rien.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
J'avais songé à cela mais le seul outil que j'ai trouvé pour rediriger vers une autre page est headers mais, avec ça, je ne parvenais pas à conserver les données qui avaient été saisies dans le premier formulaire.
Pour ça, il faudrait utiliser les sessions. Mais tu n'en n'a pas besoin ici - il te suffit, dans chaque formulaire "d'étape", de stocker les saisies déjà validées dans des champs cachés.
Y a-t-il une autre possibilité pour rediriger vers une autre page ?
En PHP ? Pas à ma connaissance (je parles bien de redirection HTTP).
En attendant, j'examine la solution que tu proposes.
Merci !
De rien.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Denis Bitouze
Le 27 sep 2006 à 11h31
Pour ça, il faudrait utiliser les sessions. Mais tu n'en n'a pas besoin ici - il te suffit, dans chaque formulaire "d'étape", de stocker les saisies déjà validées dans des champs cachés.
Justement, je stocke mes variables dans la variable (globale je crois) $_SESSION ainsi :
mais je ne sais pas si c'est préférable ou pas au stockage dans des champs cachés (il n'y a rien de confidentiel dans ces variables).
Y a-t-il une autre possibilité pour rediriger vers une autre page ?
En PHP ? Pas à ma connaissance (je parles bien de redirection HTTP).
Euh oui, en PHP. Tu pensais à autre chose ? -- Denis
Le 27 sep 2006 à 11h31
Pour ça, il faudrait utiliser les sessions. Mais tu n'en n'a pas
besoin ici - il te suffit, dans chaque formulaire "d'étape", de
stocker les saisies déjà validées dans des champs cachés.
Justement, je stocke mes variables dans la variable (globale je crois)
$_SESSION ainsi :
Pour ça, il faudrait utiliser les sessions. Mais tu n'en n'a pas besoin ici - il te suffit, dans chaque formulaire "d'étape", de stocker les saisies déjà validées dans des champs cachés.
Justement, je stocke mes variables dans la variable (globale je crois) $_SESSION ainsi :
mais je ne sais pas si c'est préférable ou pas au stockage dans des champs cachés (il n'y a rien de confidentiel dans ces variables).
Y a-t-il une autre possibilité pour rediriger vers une autre page ?
En PHP ? Pas à ma connaissance (je parles bien de redirection HTTP).
Euh oui, en PHP. Tu pensais à autre chose ? -- Denis
Bruno Desthuilliers
Denis Bitouze wrote:
Le 26 sep 2006 à 20h56
[...] Terminer !
OK, j'examine cela...
Pour une solution plus élaborée : framework MVC.
Houla, j'ai jeté un coup d'oeil mais je n'ai plus le temps de me plonger là dedans (dommage, si j'avais eu connaissance de cela au début, j'aurais essayé).
Pas besoin de POO ni de gros framework pour mettre en place une archi MVC en PHP. Ca se gère aussi bien avec des scripts et des includes, sur le même principe qu'évoqué dans le post de David ou le mien (voir aussi le thread sur "les limites de PHP").
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Denis Bitouze wrote:
Le 26 sep 2006 à 20h56
[...]
Terminer !
OK, j'examine cela...
Pour une solution plus élaborée : framework MVC.
Houla, j'ai jeté un coup d'oeil mais je n'ai plus le temps de me
plonger là dedans (dommage, si j'avais eu connaissance de cela au
début, j'aurais essayé).
Pas besoin de POO ni de gros framework pour mettre en place une archi
MVC en PHP. Ca se gère aussi bien avec des scripts et des includes, sur
le même principe qu'évoqué dans le post de David ou le mien (voir aussi
le thread sur "les limites de PHP").
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Houla, j'ai jeté un coup d'oeil mais je n'ai plus le temps de me plonger là dedans (dommage, si j'avais eu connaissance de cela au début, j'aurais essayé).
Pas besoin de POO ni de gros framework pour mettre en place une archi MVC en PHP. Ca se gère aussi bien avec des scripts et des includes, sur le même principe qu'évoqué dans le post de David ou le mien (voir aussi le thread sur "les limites de PHP").
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Bruno Desthuilliers
Denis Bitouze wrote:
Le 27 sep 2006 à 11h31
Pour ça, il faudrait utiliser les sessions. Mais tu n'en n'a pas besoin ici - il te suffit, dans chaque formulaire "d'étape", de stocker les saisies déjà validées dans des champs cachés.
Justement, je stocke mes variables dans la variable (globale je crois) $_SESSION ainsi :
mais je ne sais pas si c'est préférable ou pas au stockage dans des champs cachés.
"Préférable", je ne sais pas. Disons que j'ai personnellement tendance à éviter autant que possible les sessions, mais il n'y a pas lieu d'en faire de règle absolue - la seule règle "absolue" AMHA est "faire ce qui convient pour le problème en cours" !-)
<thinking-out-loud> L'intérêt de passer par des champs cachés est que ton code ne dépend pas d'un état 'global' (la session), mais seulement des données qui lui sont directement accessibles (on est en fait exactement dans le même cas qu'une fonction dépendant d'une variable globale vs une fonction ne dépendant que de ses paramètres - et il est bien connu que la seconde option est de loin préférable en termes de modularité / testabilité / maintenabilité).
D'un autre côté, en mettant les données en session au fur et à mesure, tu es sûr que ce sont bien les données validées, alors qu'avec des champs cachés tu ne peux jamais être sûr (rien ne te dit que c'est bien à partir de *ton* formulaire que la requête a été postée)... ce qui pourrait t'amener à revalider toutes les données à chaque étape.
Mouais. En bref, c'est à toi de voire en fonction du contexte. Un seul point AMHA : si tu mets les données en session, mets y aussi l'étape en cours et utilise une seule et même URL pour gérer tout le wizard. </thinking-out-loud>
(il n'y a rien de confidentiel dans ces variables)
S'il s'agit des données POSTées à l'étape précédente, de toutes façons, elles sont déjà passées en clair sur le net, donc pour ce qui est de la confidentialité, hein, c'est un peu rapé !-)
La seule solution fiable ici est HTTPS, et dans ce cas tu peux aussi bien repasser ces données de formulaire en formulaire...
Y a-t-il une autre possibilité pour rediriger vers une autre page ? En PHP ? Pas à ma connaissance (je parles bien de redirection HTTP).
Euh oui, en PHP. Tu pensais à autre chose ?
Non, c'était juste pour faire avancer le schimilimili... le schmililimili... le... <candidat suivant, Simone, s'il vous plait>
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Denis Bitouze wrote:
Le 27 sep 2006 à 11h31
Pour ça, il faudrait utiliser les sessions. Mais tu n'en n'a pas
besoin ici - il te suffit, dans chaque formulaire "d'étape", de
stocker les saisies déjà validées dans des champs cachés.
Justement, je stocke mes variables dans la variable (globale je crois)
$_SESSION ainsi :
mais je ne sais pas si c'est préférable ou pas au stockage dans des
champs cachés.
"Préférable", je ne sais pas. Disons que j'ai personnellement tendance à
éviter autant que possible les sessions, mais il n'y a pas lieu d'en
faire de règle absolue - la seule règle "absolue" AMHA est "faire ce qui
convient pour le problème en cours" !-)
<thinking-out-loud>
L'intérêt de passer par des champs cachés est que ton code ne dépend pas
d'un état 'global' (la session), mais seulement des données qui lui sont
directement accessibles (on est en fait exactement dans le même cas
qu'une fonction dépendant d'une variable globale vs une fonction ne
dépendant que de ses paramètres - et il est bien connu que la seconde
option est de loin préférable en termes de modularité / testabilité /
maintenabilité).
D'un autre côté, en mettant les données en session au fur et à mesure,
tu es sûr que ce sont bien les données validées, alors qu'avec des
champs cachés tu ne peux jamais être sûr (rien ne te dit que c'est bien
à partir de *ton* formulaire que la requête a été postée)... ce qui
pourrait t'amener à revalider toutes les données à chaque étape.
Mouais. En bref, c'est à toi de voire en fonction du contexte. Un seul
point AMHA : si tu mets les données en session, mets y aussi l'étape en
cours et utilise une seule et même URL pour gérer tout le wizard.
</thinking-out-loud>
(il n'y a rien de confidentiel dans ces variables)
S'il s'agit des données POSTées à l'étape précédente, de toutes façons,
elles sont déjà passées en clair sur le net, donc pour ce qui est de la
confidentialité, hein, c'est un peu rapé !-)
La seule solution fiable ici est HTTPS, et dans ce cas tu peux aussi
bien repasser ces données de formulaire en formulaire...
Y a-t-il une autre possibilité pour rediriger vers une
autre page ?
En PHP ? Pas à ma connaissance (je parles bien de redirection HTTP).
Euh oui, en PHP. Tu pensais à autre chose ?
Non, c'était juste pour faire avancer le schimilimili... le
schmililimili... le... <candidat suivant, Simone, s'il vous plait>
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Pour ça, il faudrait utiliser les sessions. Mais tu n'en n'a pas besoin ici - il te suffit, dans chaque formulaire "d'étape", de stocker les saisies déjà validées dans des champs cachés.
Justement, je stocke mes variables dans la variable (globale je crois) $_SESSION ainsi :
mais je ne sais pas si c'est préférable ou pas au stockage dans des champs cachés.
"Préférable", je ne sais pas. Disons que j'ai personnellement tendance à éviter autant que possible les sessions, mais il n'y a pas lieu d'en faire de règle absolue - la seule règle "absolue" AMHA est "faire ce qui convient pour le problème en cours" !-)
<thinking-out-loud> L'intérêt de passer par des champs cachés est que ton code ne dépend pas d'un état 'global' (la session), mais seulement des données qui lui sont directement accessibles (on est en fait exactement dans le même cas qu'une fonction dépendant d'une variable globale vs une fonction ne dépendant que de ses paramètres - et il est bien connu que la seconde option est de loin préférable en termes de modularité / testabilité / maintenabilité).
D'un autre côté, en mettant les données en session au fur et à mesure, tu es sûr que ce sont bien les données validées, alors qu'avec des champs cachés tu ne peux jamais être sûr (rien ne te dit que c'est bien à partir de *ton* formulaire que la requête a été postée)... ce qui pourrait t'amener à revalider toutes les données à chaque étape.
Mouais. En bref, c'est à toi de voire en fonction du contexte. Un seul point AMHA : si tu mets les données en session, mets y aussi l'étape en cours et utilise une seule et même URL pour gérer tout le wizard. </thinking-out-loud>
(il n'y a rien de confidentiel dans ces variables)
S'il s'agit des données POSTées à l'étape précédente, de toutes façons, elles sont déjà passées en clair sur le net, donc pour ce qui est de la confidentialité, hein, c'est un peu rapé !-)
La seule solution fiable ici est HTTPS, et dans ce cas tu peux aussi bien repasser ces données de formulaire en formulaire...
Y a-t-il une autre possibilité pour rediriger vers une autre page ? En PHP ? Pas à ma connaissance (je parles bien de redirection HTTP).
Euh oui, en PHP. Tu pensais à autre chose ?
Non, c'était juste pour faire avancer le schimilimili... le schmililimili... le... <candidat suivant, Simone, s'il vous plait>
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
