[Conception] Une page pour tous les traitements ?

Bonjour,

J'ai un petit soucis avec mes pages, lorsque un élément est envoyé en post, l'actualisation force a renvoyer les contenus une deuxième fois. Des éléments javascripts peuvent rechercher mes pages, d'ou des renvois possibles assez embêtants.

En parcourant le web, je vois ces pages asp ou php s'appelant "do" suivit d'un type d'action. Est-ce une reecriture ou s'agit-il d'une facon de centraliser les traitements possibles sur une seule page et de rediriger ensuite sur la page actualisee. Si c'est la cas, cette methode est-elle fiable ? Elle resoudrait mon soucis mais a quel prix ?

D'avance merci pour vos suggestions.

j'ai rien compris à la demande. tu voudrais pas faire plus simple ou plus explicite stp

Désolé, j'ai écris un mélange de tout ce que j'ai dans la tête ^^

Est-il intéressant de regrouper tous les traitements de formulaires dans une même page php traitement.php ?

Par exemple la gestion du login serait :
login.php > traitement.php > index.php

La gestion d'un post de forum :
nouveauMessage.php > traitement.php > message.html

Ou traitement.php serait l'intermédiaire servant a faire les requêtes et rediriger ensuite.

Cette méthode est-elle fiable ? Intéressante ? Répandue ?

C'est plus clair ? ;)

A part compliquer la maintenance de ton code je n'y vois que peu d'intérêt, si tu as 25 formulaire dans ton site , le fichier va devenir énorme.

Une page de traitement par formulaire en revanche me semble déjà plus clair. Après c'est selon les gouts de chacun :)

Bonjour,

Cette idée est trés bonne, mais comme le souligne grunk tu risque d'avoir un gros fichier, aussi je te conseil de faire un page traitement.php qui aurais un include qui inclu la bonne page en fonction de l'action passée en parametre.

ça donnerais quelque chose comme ça :

Code:

---

1 2 3 4 5 6 7 8

<?php //Trés important vérifier la variable pour ne pas créer de faille if(!isset($_GET['do'] || !preg_match('/[a-zA-Z\-_]+/', $_GET['do']) ){ die('Action invalide'); } include('actions/'.$_GET['do'].'.php'); ?>

---

Il serais important de rajouter une redirection , par exemple en ajoutant a la fin :

Code:

---

<p>Cliquez <a href="<?php echo $_GET['goto']; ?>">ici</a> pour retourner a l'acceuil.

---

Enfin tu a l'air de savoir ce que tu fait, tu devrais t'en sortir.

Ce traitement évite de nombreux probleme de double post etc, et il est communément utilisé sur tout les forum, blog etc..

Tu devrais jeter un oeuil du coté du modele MVC.

Bonne continuation, en esperant t'avoir été utile.

Citation:

---

A part compliquer la maintenance de ton code je n'y vois que peu d'intérêt, si tu as 25 formulaire dans ton site , le fichier va devenir énorme.

Une page de traitement par formulaire en revanche me semble déjà plus clair. Après c'est selon les gouts de chacun

---

Ça complique le code, oui et non. Ça me rempli une page mais allège l'arborescence d'autant de fichiers que j'aurai pu créer pour des traitements individuels. un bon switch() et hop ;)

Citation:

---

Cette idée est trés bonne, mais comme le souligne grunk tu risque d'avoir un gros fichier, aussi je te conseil de faire un page traitement.php qui aurais un include qui inclu la bonne page en fonction de l'action passée en parametre.

---

Ton idée va plus loin que ce que a quoi je pensais, de part sa gestion des include. Ca recoupe l'idée précédente au niveau du nombre de fichiers mais de cette façon, rangées dans un dossier traitements par exemple, ca me parait être une idée bien judicieuse. Ca virerait en en-tete de mes pages de formulaires les 3 tonnes de lignes de traitements, et ca rendrait le tout un peu plus intelligent.

Pour faire un mix de vos deux suggestions, je vais peut-être bien opter pour cette page de traitement, de la facon dont vous me conseillez de le faire.

Je pense que si c'était terrible et dangereux, quelqu'un l'aurait déjà dit maintenant ^^.

Merci a vous deux !

PS : Pour les motifs de conception, je m'y suis déjà penche au moment du développement de mon système template. Mais c'est l'idée générale effectivement.

Bonjour,

Avant de m'y mettre, j'ai découvert prototype ... et je me demande si avec une soumission ajax, ce fichier traitement aurait encore un intérêt ?

Soumettriez vous tous vos formulaires par ajax vous ?

Le Javascript est très utile pour faire toute une série de tests qui peuvent s'effectuer niveau client (genre champs vide, valeurs numériques, etc) à vérifier avant d'envoyer le formulaire au traitement PHP.
En ajoutant de l'AJAX, c'est pratique pour vérifier si une adresse e-mail existe déjà dans la table de la base de données par exemple.

En revanche, ça n'exclut pas de devoir effectuer toutes ces vérifications depuis ta page de traitement PHP, au cas où le visiteur ne supporte pas le Javascript.

En effet, je vais réfléchir a tout ca, merci,

Le truc c'est que la, je ne pense pas aux traitements des chaines, mais plutôt a l'envoi des données. Il est clair qu'au niveau navigation, un site ou on insère un élément en ne rechargeant que les la liste ou le tableau correspondant est un plus. Au niveau de la création, je me demande si l'envoi du formulaire, pour insérer une news par exemple est intéressant en ajax ou si vous passeriez de votre cote par un full php pour l'insertion, et l'ajax pour juste afficher des popup, et des traitements bdd de verfif comme celui dont tu parlais effectivement ?


Pour pallier aux problèmes d'accessibilité, on peut imaginer un évènement

Code:

---

onsumit="traitement();return false;"

---

sur le form. De cette manière, il peut être traite en ajax ET de façon classique.

Pour comparer avec des sites "solides" :
- Gmail est en full ajax mais possede une version a part destinee aux "autres"
- Facebook ne recharge que les elements modifies mais scinde bien ses pages en fonction des sections
- developpez.com (phpbb) a plutot la logique full php, a savoir une insertion = un rechargement, et utilise des petits éléments javascript pour les a cote

J'ai a peu pres tous ces choix en face de moi et je m'y perd ...

Code:

---

onsumit="traitement();return false;"

---

Renverra toujours faux et ne sera donc jamais envoyé au PHP, si tu veux un vrai traitement Javascript, c'est plutôt

Code:

---

onsubmit="return traitement();"

---

avec traitement() renvoyant true ou false suivant la validité des entrées du formulaire.

Là tu cites 3 exemples de sites/scripts (d'ailleurs ce forum c'est du vBulletin, pas phpBB) qui ont des approches différentes de gérer leurs communications avec le serveur, mais aucune n'est meilleure qu'une autre dans l'absolue, c'est justement à toi de déterminer ce qui te semble le plus adapté pour ton site.

L'asynchrone est surtout utilisé pour "l'expérience utilisateur", d'avoir l'impression que le site est comme une application "classique", mais sur un forum ce serait essentiellement gadget et consommateur de ressources.
A l'inverse sur Facebook qui affiche énormément d'informations de différentes sources, n'en actualiser qu'une partie permet sûrement d'économiser pas mal de ressources.

Citation:

---

avec traitement() renvoyant true ou false suivant la validité des entrées du formulaire.

---

J'ai ecris vite fait l'idee, la deuxieme solution est deja dans mon code ;)

Pour ma part, il s'agit de l'admin un CMS, donc composee de plusieurs types de contenus, des liens, des articles, des fichiers uploades, une gestion multi-utilisateurs, etc ... C'est a peu près aussi riche qu'un admin phpbb en fait.

Tu choisirais quoi dans ce genre de cas ?

Ma tête est trop pleine de fonction ptotoype ... je suis incapable de faire un choix ... d'autant plus que j'ai bien conscience qu'ils sont tous envisageables ...

Les contraintes que je me suis fixes, c'est la compatibilité a partir de IE6, Firefox, Safari. Et ne pas negliger le javascript désactivé.

Je suis plutôt flemmard, donc la question c'est en général de savoir si le gain de temps à l'usage vaut le temps passer à développer.

Donc dans le cas d'une admin de CMS, j'utiliserais probablement très peu d'AJAX et de JS en général, d'une part parce que j'estime que dans une certaine mesure l'administrateur sait ce qu'il fait et ne va pas chercher à entrer des conneries dans le formulaire (genre adresse e-mail invalides), donc au pire il soumet le formulaire 2-3 fois avant de se rendre compte de son erreur et ensuite ne fera probablement plus d'erreur, et d'autre part parce qu'a priori on ne fait pas de changements dans une admin tous les jours, donc avoir quelques pages à (re)charger n'a rien de dérangeant.

Après dans certains aspects, l'AJAX ou même du Java ou du Flash peuvent être intéressants, dans ton cas je vois ça particulièrement pour l'upload de fichiers.

Ok, je vais juste garder l'ajax pour remplacer mes window.open() et ne pas trop chercher pour le rechargement. Peut-etre profiter des requetes http du cote site du CMS ^^.

Merci pour ces éclaircissements.

Bonjour,

Suite aux recommandations concernants la sécurité des formulaires énoncées ici : http://www.developpez.net/forums/d72...e/#post4220980, et sans tomber dans la psychose, j'ai revu l'envoi de mon passage traitement.php. Je vous le soumet dans le doute, n'etant pas franchement un maniaque de la securite, je tiens tout de même a mes contenus et a leur confidentialité.

Je vous fait un topo, j'attends vos réactions.

Donc mon formulaire est écrit en dur dans un template et ses contenus sont gérés par php. J'utilise un flag de sécurité (token) pour éviter les attaques multiples sur de longues durées (ça fait partie des nouveautés proposées dans le post joint).

Voila comment est généré ce token :
Fichier formulaire.php :

Code:

---

1 2 3

// CREATION DU GLAG DE SECURITE ET ENREGISTREMENT DANS UN SESSION APPROPRIEE $_SESSION["flagSecurite"] = $Vigile->creerFlagSecurite();

---

Fichier Vigile.php :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class Vigile {   ...   // CETTE METHODE GENERE UN IDENTIFIANT UNIQUE A INSERER DANS UN FORMULAIRE AFIN D'EN VERIFIER LA FIABILITE function creerFlagSecurite() {   return $GLOBALS["Chaine"]->genererIdentifiant().CLE_SITE.base64_encode(mktime());   }   ...   }

---

Vigile est la classe qui gère la sécurité du magasin ;).

Je vous met pas le form en html, il est tout simple, et ca sert a rien. A noter juste un champ hidden flagSecurite comprenant mon ... flag de securite. Et dans mon action, j'appelle traitement.php?action=ajouterBidule

On post le formulaire a traitement.php :

Code:

---

1 2 3 4 5 6 7 8 9

// VERIFICATION DES PARAMETRES ET SYMBOLES if(!isset($_GET['action']) || !preg_match('/[a-zA-Z\-_]+/', $_GET['action'])) die('Action invalide');   // INCLUSION DE LA PAGE COMPRENANT LES INFOS include(ADMIN_PATH."traitements/{$_GET['action']}.php");   // REDIRECTION (VITE FAIT, C'EST PAS LE SUJET ^^) print "<p>Cliquez <a href=''>ici</a> si vous n'êtes pas rediriges.";

---

Et traitements/bidule.php prend le relai, avec son en-tête protege :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

// VERIFICATION DU REFERER if(!ereg(@ADMIN_PATH_HTTP, @$_SERVER['HTTP_REFERER'])) die("provenance inconnue");   // VERFICATION DE L'ENVOI DU FLAG DE SECURITE if (!isset($_SESSION['flagSecurite']) OR !isset($_POST["flagSecurite"])) die("le code de securite n'a pas pu etre verifie");   // VERIFICATION DE LA CORRESPONDANCE DU FLAG DE SECURITE if ($_SESSION['flagSecurite'] != $_POST["flagSecurite"]) die("code de securite incorrect");   // VERIFICATION D'ACTUALITE DU FLAG DE SECURITE $tempsAlloue = 120; // en secondes $secuTimeTab = split(CLE_SITE,$_SESSION["flagSecurite"]); $tempsEcoule= mktime()-base64_decode($secuTimeTab[1]); if ($tempsEcoule>$tempsAlloue) die("delai expire");   // FELICITATIONS (CA SERT A RIEN MAIS CA FAIT PLAISIR) $tempsRestant = $tempsAlloue-$tempsEcoule; print "felicitations ! Tu a passe les barages. Il te restait : $tempsRestant s";   // TRAITEMENT DES INFOS   extract($_POST); // etc.

---

Merci pour vos suggestions.

J'en conclu que c'est parfait ? ^^