PHP|Débutant :: Forums

Bonjour,

En fait pour répondre à ta question, plusieurs formulaires peuvent exister sur la même page en PHP.
Mettons par exemple que tu veuilles faire cohabiter 3 formulaires sur la même page et que les données utilisées soient croisées.
La première chose à savoir c'est que pour rendre le traitement de ta page possible, tu ne pourras pas et il ne faudra pas les afficher tous en même temps principalement à cause du submit qui doit rester unique. Pour rendre l'algorithme plus concis et simple pour mon exemple, je vais définir une fonction pour chaque formulaire à afficher à savoir display_form1() pour le premier formulaire, display_form2() pour le second et display_form3() pour le 3e. Toujours pour mon exemple je vais appeler $var_1 la variable caractéristique du formulaire 1 obligatoirement présente si le bouton submit à été utilisé sur le formulaire 1 si il a été correctement rempli (code de vérification non présent ici), et de même pour chaque formulaire avec $var_2 et $var_3. Pour l'exemple ces variables sont des entiers. On appellera $var_1_x l'ensemble des variables transmises par le formulaire 1 lors de sa soumission. De même pour $var_2_x et $var_3_x

Pour que le code ci-dessus fonctionne faudra respecter les choses suivantes:
- Les 3 formulaires doivent transmettre les données en POST et Les 3 formulaires doivent pointer sur leur propre fichier pour le traitement :

- Toutes les variables du formulaire précédent passées dans une fonction doivent être rajoutées dynamiquement via un champ hidden de formulaire de manière à être retransmises et ainsi les rendre disponibles lors du traitement final des 3 formulaires.

J'espère que cela t'auras aidé.

Jc

PS: Avec cette structure il est d'ailleurs possible de construire les formulaires 2 et 3 dynamiquement en fonction des paramètres choisis au formulaire(s) précédent(s).

Dernière modification par Jc (27-06-2010 22:14:49)

Bonsoir,

Je t'en prie.
Vu que tu as écris que tu as une certaine connaissance dans la conception d'applications, je vais essayer de t'éclairer sur la structure MVC, notamment quand tu as écris cela un peu plus haut

Une page d'un navigateur, et ce, quelque soit le language de prog utilisé, n'associe pas forcément une sortie d'affichage utilisateur. Une page, associée physiquement à un nom de fichier, peut contenir par exemple une classe PHP de gestion de connexion, une bibliothéque de fonctions PHP (équivalent DLL sur les apli autonomes),etc... . Une Structure MVC dans les technologies web, est une structure qui va dissocier la gestion du modèle, de la vue et du contrôleur dans des pages dédiées, la structure usuelle étant d'associer les 3 sur une même page.

Tes exemples de codes précédents illustrent une structure usuelle, la mienne se rapproche d'une conception MVC. En effet la page exemple.php n'affiche rien en elle-même, elle sert juste à contrôler les paramètres, à commander l'affichage, et à traiter les paramètres finaux. C'est donc une page contrôleur type. Pour que l'architecture MVC soit respectée dans mon exemple, il faut développer les fonctions d'affichage sur une autre page par exemple display_forms.php et les associer à la page exemple.php comme illustré dans le code ci-dessous.

Ensuite pour peu que le traitement final de tes paramètres necessite un traitement base de données, tu places toutes tes fonctions de traitement base de données dans un fichier par ex traitements.php
que tu places aussi en include dans ta page exemple.php. Ainsi tu peux également mettre à jour l'affichage d'un formulaire sans toucher au code de traitement et vice-versa.

C'est comme ça qu'une bonne structure de programmation peut résoudre tes problèmes.;)

Voilà.

Jc

Dernière modification par Jc (27-06-2010 22:54:07)

Bonjour,
Merci pour les exemples et les précisions de vocabulaire.
Je pense avoir compris mais je crois être un peu perdu face à mon exemple.
Si j'ai bien compris l'approche consiste à faire une page qui n'affiche rien et qui seulement teste des conditions de valeurs de variables afin d'appeler les fonctions de traitement correspondante aux résultats des conditions trouvées. Cette page sert comme tu le dis une page contrôleur.
Mais pour revenir à mon exemple très simple il y a comme préambule le fait qu'il faudra:
1) Demander la saisie des données clients au travers d'un formulaire unique,
2) Demander à l'utilisateur ce qu'il veut faire sachant que les traitements ne dépendent pas du résultat de la saisie des données.
En conséquence, quelle que soit l'architecture envisagée, je ne vois pas comment éviter de faire deux étapes:
1) Faire une page de saisie des données clients, avec vue du formulaire, saisie et passage des valeurs des données client,
2) Faire une page de contrôle de formulaires multiples avec récupération des données par $_post et appel des fonctions de traitement correspondant au libre choix de l'utiliateur (non conditionné par des valeurs particulières).

Je tourne en rond et je ne vois toujours pas comment ne pas avoir deux pages distinctes pour dialoguer avec l'utilisateur. Encore une fois j'aurai voulu avoir tout sur une seule page avec formulaires multiples (saisie des données et choix de traitements) mais la contrainte liée à la récupération des données par $_post impose deux étapes et deux pages distinctes.
La seule chose qu'on puisse imaginer, pour n'avoir qu'une page à gérer et à maintenir, c'est de présenter la page avec des vues différentes en jouant sur les champs cachés suivant que les données clients ont été ou non déjà saisies (c'est je pense ce que vous appelez générer dynamiquement les formulaires). Au départ on ne montre que la saisie des données clients , le reste étant caché (formulaire de saisie), par la suite retour sur la même page mais cette fois avec vue des autres formulaires de traitement (formulaire d'affichage client, de saisie client, de mise à jour client, etc.....). Le tout conditionné par une variable d'affichage (false ou true) suivant le cas. 
Mais dans la réalité pour l'utilisateur cela revient toujours au même, il aura toujours deux étapes à faire car les choix de traitement dépendent de son choix et non pas de conditions.
Ai-je bien compris?
Question: Est-il possible de modifier dynamiquement les attributs des champs (cachés ou visibles)? Ou bien comment faire pour que les champs s'affichent ou pas suivant la variable d'affichage?

Re,

Concernant ta vision de la gestion dynamique ce n'est pas tout à fait ça. Afficher l'ensemble des possibilités sur une page et en cacher tout ou partie selon la valeur de certains paramètres est lourd et charge inutilement la page avec des données non pertinentes. Une vrai gestion dynamique gère l'affichage en fonction de paramètres. Exemple pour mieux comprendre:

Ici le code d'affichage est généré à la volée en fonction d'un paramètre. Le code affiché correspondra uniquement à ce que l'on a besoin de voir.

Dernière modification par Jc (28-06-2010 10:46:13)

RE,
Oui en fait s'agissant de la gestion dynamique des pages tu conditionnes l'appel de l'une ou l'autre suivant des variables qui peuvent être dynamiquement calculées ou modifiées. C'et clair.
Pour aller plus loin j'avais dans l'idée de générer des pages dynamiquement, de toute pièce et de les faire exécuter; mais ceci est encore d'un autre niveau ça fait appel à une technique de générateur (ceci me rajeunirait car c'est une technique que j'ai souvent utilisée, très tôt.... en 1970 pour mon premier générateur de programmes Cobol pour le squelette du programme gérant toute la partie logique de la logique du programme à partir d'un paramétrage issu d'une méthode d'analyse appelée MINOS).
Ceci est un autre sujet mais qui me tient à cœur de vérifier également en PHP, faire en quelque sorte un générateur d'application.

Dernière modification par pitou (28-06-2010 11:14:12)

Bonsoir JC,
Je ne disais pas cela pour isset mais pour $_post, isset vérifiant seulement que la variable a bien été affectée ou pas dans le cas qui nous intéresse. Par contre la variable n'est testée que par rapport à $_post ce qui implique que le formulaire ait bien été rempli par l'utilisateur sans quoi $_post n'est pas activé et ne peut pas être utilisé, voilà pourquoi je posais la question.
Est-ce que je me trompe?

Bonsoir,

Pour répondre à Pitou, tu te trompes en effet car ce n'est pas comme ça que $_POST fonctionne. Comme l'a justement dit Maljuna et pour compléter ses propos $_POST est une variable serveur de type array() qui contient les champs de formulaires pour method="post" transmis par http au serveur Apache. Or cette variable est disponible en permanence tant que le serveur PHP est disponible. Si aucun formulaire est passé au serveur via la méthode post $_POST[] = array() et isset($_POST['n'importe quel nom de variable'])==false. Toutefois il existe un autre cas pour lequel isset() peut retourner la valeur false c'est lorsque la variable testée existe et à pour valeur null. A prendre donc en considération dans son code.