Meilleure pratique: scripts autoréférentiels sur un site Web

Question

Sur les conseils d'un développeur plus expérimenté, j'ai toujours codé mes pages Web nécessitant une entrée de l'utilisateur (traitement de formulaire, administration de base de données, etc.) comme des pages auto-référentielles. Pour les pages PHP, je règle l'action du formulaire sur l'élément 'PHP_SELF' de la variable prédéfinie $ _ SERVER , et en fonction des arguments que je transmets à la logique de la page. quel (s) bloc (s) de code à exécuter.

J'aime que tout le code soit contenu dans un seul fichier et non réparti sur plusieurs pages de résultats. Le problème que j'ai constaté est que mes programmes d'analyse de statistiques ne peuvent pas différencier le premier affichage de la page des affichages suivants (par exemple, lorsque le formulaire a été soumis). Il y a longtemps, lorsque j'utilisais CGI ou CF pour créer les pages, je dirigeais l'utilisateur vers une page de résultat différente, qui indiquait très précisément combien de fois le formulaire était réellement utilisé.

Quelle est la meilleure pratique pour ce type de pages dans le développement Web? Existe-t-il d'autres raisons plus convaincantes d'utiliser (ou de ne pas utiliser) des pages auto-référentielles?

Answer 1

Je dirais que les pages auto-référentielles, comme vous le dites, ne suivent pas une séparation appropriée des préoccupations. Vous faites 2 choses différentes avec la même page, où une séparation plus nette de la logique voudrait que vous les fassiez sur 2 pages différentes.

Cette pratique est soulignée par MVC (modèle-vue-contrôleur, http: // en .wikipedia.org / wiki / Model-view-controller ), tels que Ruby on Rails, Django et ASP.NET MVC (je ne connais pas de code PHP par cœur, bien que je Je suis sûr qu'il y en a).

Il s'agit également d'une caractéristique essentielle des pratiques RESTful (REpresentational State Transfer), dans laquelle chaque URL représente une ressource et une action unique à exécuter avec cette ressource. Une page auto-référentielle, par contre, aurait "2". actions par URL / page, telles que " new " (pour obtenir le formulaire à remplir) et "créer" (pour créer réellement l'objet).

Pratiquer MVC et RESTful ( http://fr.wikipedia.org/wiki/RESTful ) les pratiques relatives aux sites Web aboutissent souvent à un code plus propre et à une meilleure séparation des préoccupations. La raison en est que cela facilite les tests (et par test, j'entends les tests unitaires et fonctionnels, et non "l'essai de la page sur le navigateur").

L’encombrement de vos statistiques est un exemple de la façon dont la non séparation de vos préoccupations peut conduire à une complexité non voulue. Certaines personnes pourraient aborder ce problème en essayant de détecter le référent de la demande et voir si c'était la même page ou non. Ce ne sont en réalité que des bandages codés qui traitent le symptôme au lieu de résoudre le problème. Si vous conservez différentes "& actions; actions". Dans différentes pages de votre site Web, vous pouvez concentrer ces pages sur leur travail, et vous assurer qu'elles le font bien, au lieu d'encombrer le code de toutes sortes de conditions et de complexités supplémentaires qui sont complètement évitées si une page ne compte qu'un travail.

Answer 2

L'argument le plus fort derrière l'approche de fichier unique pour la gestion des formulaires est qu'il est tout simplement plus facile à gérer.

Permettez-moi de me faire l'avocat du diable: si votre approche à deux fichiers originale fonctionne et est mesurable, pourquoi la changer - en particulier si cette modification vous oblige à trouver des solutions de contournement pour mesurer la soumission du formulaire?

D'autre part, si vous traitez avec quelque chose de plus complexe que ce que j'imagine comme une simple soumission de formulaire de contact (par exemple), il vous incombera peut-être de apprendre à enregistrer vos actions au lieu de dépendre d'un package de statistiques Web.

Answer 3

Dans le cas où je demande à quelqu'un de remplir un formulaire (généré par le script dans un fichier), j'aime poster sur le même script pour pouvoir placer les contrôles d'erreur en haut, puis -générer le formulaire si des erreurs sont trouvées. Cela me permet d’écrire la génération de formulaire une fois et de la réutiliser jusqu’à ce que la saisie soit acceptable (c.-à-d. "Corrigez les champs en rouge", etc.).

Une fois que toutes les vérifications de sécurité ont été passées, vous pouvez émettre la page de résultats à partir du même script ou faire appel à un autre script, selon la solution la mieux adaptée à votre situation. Mais je ne vois personnellement aucun problème avec les scripts autoréférentiels que vous décrivez.

Cela dit, j’appelle toujours sur le code générique et les bibliothèques pour effectuer la génération du formulaire et la vérification des erreurs, de sorte que même "& partagé; partagé". Le code de génération de formulaires finit par être assez compact et simple.

Answer 4

Une option potentielle serait de configurer des alias mod_rewrite pointant vers la même URL. Par exemple:

RewriteEngine on
RewriteRule ^form$ form.php [QSA]
RewriteRule ^form/submit$ form.php [QSA]

Cela vous permettrait de suivre les demandes tout en conservant le code dans le même fichier.

Answer 5

Vous pouvez utiliser des pages séparées et demander à la page de résultats d'inclure la page de formulaire.