Bonjour à tous,

je sollicite votre expérience sur un point qui me pose problème.
Récemment, je me suis posé la question de la structuration de mes pages Web. N'utilisant pas beaucoup d'objet (voire pas du tout), voici 2 concepts qui se posent à moi:

1) Des pages du type: www.monsite.com/index.php?page=contact.php
L'intéret est de centraliser la structure. Si je veux coder de nouvelles pages, je n'ai qu'à créer de nouveaux fichiers PHP. La structure "encaspulera" d'office les nouvelles pages.

2) Des pages du type: www.monsite.com/contact.php
Une inclusion des header, footer et etc dans chaque page. Intéret: chaque page est indépendante et sa structure peut être modifiée si besoin est. (la 1ere solution n'empeche pas cela, mais il faut alors dynamiser la structure, ce qui la rend...euh... moins robuste  )
Un autre atout (selon moi) est de pouvoir traiter le formulaire sur la même page (avant tout affichage HTML), en vérifiant les données POST. Ce qui centralise formulaire et traitement. On aura donc 1 seul fichier pour chaque "module".

Personnellement j'utilise la 1ere méthode, car c'est celle qui est la plus simple à mettre en oeuvre. Ce n'est qu'un avis personnel. Probablement qu'elle demande aussi moins de travail.
Par contre, quelque chose pose problème. Le principe du traitement du formulaire à placer dans le même fichier est assez pratique. Et je ne vois pas comment le mettre en place tout en évitant la possibilité du reload des données POST.
Avec la 2nde méthode, c'est simple: le formulaire est soumis, la page est reloadée avec les données POST => je traite. Le traitement est fini, je reload la page via une bonne vieille redirection (sur la même page on aura compris). Et voilà, le problème est résolu
Avec la 1ère méthode, ce n'est pas possible, car la redirection foire en raison d'envois préablables de données HTML.

j'aimerais donc éviter ce reload POST, avec le traitement du formulaire dans le même fichier, tout en gardant la 1ère méthode de structuration de mes pages.
Est-ce possible? avez-vous des pistes?

Merci beaucoup.

Salut
 
bon je suis pas très doué en php mais je pense que tu peux envoyer la soumission de ton formulaire à une page qui traite les données de ton formulaire, ensuite tu fais un unset($post); suivie d'un header('location:ta page de validation'); .
Sur cette même page fait un contrôle sur le 'referer' qui vient bien de ton formulaire et qui empêche les données d'être re-envoyées lors d'une actualisation...

bonjour,
merci de ta réponse mais tu ne réponds pas à ma question : "envoyer la soumission de ton formulaire à une page qui traite les données de ton formulaire".
Or, je veux rester sur la même page. Si tu trouves un moyen d'éviter le reload POST dans ce cas et avec la 1ere méthode de structuration des pages, je suis preneur.

Pourquoi es tu obligé de rester sur la même page ? La page de traitement de formulaire ne serait pas visible au visiteur puisque le header renverrais à la même page... cela ne gène en rien ta structure et fais ce que tu demandes.
 
Par contre, tu ne peux pas empêcher l'utilisateur de faire un reload de page. Donc le problème ici est de faire en sorte qu'une ré-actualisation de page ne fasse pas fonctionner le formulaire pour 2 fois la même chose/ 2 fois les mêmes données... est ce qu'un "captcha" ne répondrait pas à ton attente ?
 
Sinon, je n'ai pas essayé mais, en prenant ma première idée, tu valides la page de formulaire qui est redirigée donc vers la même page qui traite tes données suivi du unset puis du header qui redireige toujours sur la même page...  
 
Question : à quoi va servir ton formulaire ? Un envoie d'email, rentrer des données en bdd , ... ?
 
 
 

Tu peux envoyer les données vers une page spéciale, tamporiser la sortie de ta page, et renvoyer avec un header vers la page originale. C'est complètement transparent pour l'utilisateur :

Formulaire :
<form action="traitement.php" ...>

index.php?page=traitement.php
ob_start();
[inclusion des données]
[traitement]
[traitement du formulaire]
ob_end_clean();
header('Location:...');

Le seul moyen est de rediriger sur l'url courante en GET à la fin du traitement POST

Je ne suis pas obligé, c'est un choix personnel pour simplifier la gestion des modules: le formulaire et le traitement du formulaire sont sur la même page, ca m'évite d'avoir 2 fichiers par module. Donc une page traitement.php ne fais pas du tout ce que je demande.

Peu importe la raison, c'est un probleme de structure inhérent aux formulaires quelque soit leurs objectifs.

Si je comprends bien là aussi, il y a une page temporaire de traitement.  Désolé je ne cherche pas cette solution.

Pour rediriger, je ne sais faire que des header('location: ...') et des redirections en javascript.

Si on considère une page ainsi:
<html>
<head></head>
<body>

<div id="menu"> menu </div>

<div id="contenu"> include('ma_page.php'); </div>

</body>
</html>

Le traitement POST se faisant au début du fichier ma_page.php, on aura compris donc que ce traitement ne se fait pas au tout début de la page. Donc pas possible de faire de header('location: ...'). Une redirection javascript fonctionnerait, mais elle afficherait la page jusqu'au contenu, pour ensuite tout rafraichir. Ce serait un peu "anormal" comme comportement. Donc déstabilisant pour l'utilisateur.

Comment fait-on des redirection en GET ? (ca se trouve je sais mais l'expression ne me dit rien).

tu rediriges en javascript avec une adresse comme "index.php?p=ma_page&envoie=ok&..."  
Mais je suis pas sur d'avoir compris ta question
Dis moi si c'est ce que tu cherches

N'importe quoi

Tu peux toujours mettre toute la sortie en cache (avant ton <html> jusqu'à après ton </html> ) et faire un flush du cache à la fin. Ainsi, tu peux faire tes header quand tu veux, du moment que le cache n'a pas été balancé.
 
Edité : lire buffer plutôt que cache.

Ah, la gestion des buffers. Tout ce qui est ob_start et compagnie?
Ah oui peut-être, je vais explorer cette piste.
Merci

Après test, ca a l'air de plutot bien marcher. Je teste sur un site en local. Je me pose du coup la question des performances.
Il faut donc que toute la page soit générée pour commencer à balancer les données. Théoriquement, le "temps de chargement" de la page est plus long nan? (le temps que mettra l'internaute à avoir toute sa page).