2011-11-16 3 views
0

Quelle est la bonne façon de traiter les formulaires dans http?Bonne façon de traiter les formulaires

sur/somepage:

<form method="POST" action="/someaction.html"> 
    <input type="text" name="name"> 
    <input type="submit"> 
</form> 

Supposons que l'utilisateur n'a pas rempli au "nom". Je devrais donc produire une erreur. Comment dois-je faire:

Première méthode

  1. POST/uneAction et 302 Redirect à/posterror erreur = 1
  2. GET/posterror error = 1 et 200 Ok avec le contenu des erreurs? et former

Deuxième

  1. POST/uneAction et 200 Ok avec le contenu sur les erreurs et forme

Troisième

  1. POST/uneAction, rappelez-vous des erreurs de forme de session et 302 Redirect à/posterror
  2. GET/posterror et 200 Ok avec le contenu sur les erreurs et la forme

Lequel est la bonne façon? Peut-être un quatrième?

Répondre

1

L'approche correcte est appelée post/redirect/get et est décrit par wikipedia comme:

Post/Redirect/Get (PRG) est un modèle de conception commun pour les développeurs Web afin d'éviter certaines soumissions de formulaires en double et permettre aux agents utilisateurs de se comporter de manière plus intuitive avec les signets et l'actualisation bouton.

+0

Merci. Et qu'en est-il de la requête GET appropriée? Paramètre d'erreur dans une requête d'URL ou en session? GET la page avec le formulaire ou avec l'erreur? Quel est ton opinion? – Oroboros102

+0

J'utiliserais normalement flashdata (données de session qui ne durent que pour une actualisation d'une page) pour montrer une erreur en haut du formulaire. Si la page est actualisée, l'erreur disparaît mais si le formulaire est soumis à nouveau, les erreurs réapparaissent si nécessaire ou disparaissent (et l'utilisateur redirigé) si elles sont toutes corrigées. – Matthew

0

Je suggère d'avoir une sorte de validation avant que le soit envoyé en utilisant javascript. Ensuite, vous devez également valider la saisie du formulaire côté serveur. Quant à savoir s'il faut utiliser les redirections, je ne connais pas de standard de facto là-bas. Si vous voulez suivre le protocole HTTP comme vous l'entendiez, vous devriez probablement renvoyer un code d'état 4xx (par exemple 400 mauvaises requêtes) avec un message informatif indiquant ce qui ne va pas dans l'entrée.

+0

"_400 Demande incorrecte - La requête ne peut pas être satisfaite en raison d'une mauvaise syntaxe" - ne pense pas que 400 soit un état approprié. – Oroboros102

0

L'utilisation de la validation côté client est-elle hors de l'équation? En utilisant javascript, vous pouvez éviter de poster le formulaire (et réduire le traitement côté serveur) et laisser le client (fin de l'utilisateur: navigateur) effectuer la validation. Quelles autres validations avez-vous en tête?

Voici un lien vers la validation de base que vous pouvez appliquer à l'aide javascript:

http://www.w3schools.com/js/js_form_validation.asp

+1

La validation côté client peut être pratique pour l'utilisateur, mais elle ne peut absolument pas être approuvée. L'utilisateur peut envoyer n'importe quelle requête HTTP qu'il aime; rien ne les oblige à exécuter le JS que vous fournissez avec la page de formulaire. – N3dst4

1

Le troisième. Il permet à l'utilisateur d'actualiser en toute sécurité ou de mettre en signet la page.Le premier, bien que similaire, vous obligerait à passer le contenu de la forme sur le fil, ce qui est inefficace. Comme de légères améliorations, vous pourriez envisager:

  • Rediriger retour à la forme, et non pas à une page d'erreur séparée, pour donner à l'utilisateur une chance de corriger leur erreur
  • Plutôt que de stocker les données d'erreur dans la session , stockez-le avec un ID unique, puis incluez-le dans l'URL de redirection. De cette façon, l'utilisateur peut ouvrir la page dans deux fenêtres de navigateur et ne pas marcher l'un sur l'autre.
  • Expiration de l'erreur stockée après une durée définie ou lorsque le formulaire est finalement correctement soumis.
+0

Stockez les données en session ou incluez-les dans une requête d'URL - c'est une question importante pour moi. Je pense, que le stockage du code d'erreur dans l'URL peut être une mauvaise idée - les problèmes de sécurité et l'utilisateur peut signet forme avec des messages d'erreur. – Oroboros102

Questions connexes