Pourquoi Django ne transmet-il pas les messages d'erreur avec la vue 404 par défaut ?

(Contexte : je suis encore très nouveau dans Django et dans le développement Web.)

1) Quelqu'un pourrait-il expliquer le raisonnement de la déclaration suivante ? Ce Q/ A a répondu à la question de savoir comment gérer ce problème, mais pas pourquoi cela pourrait être une bonne ou une mauvaise idée.

La documentation indique "La page_not_found view devrait suffire pour 99% des applications Web, mais si vous souhaitez la remplacer, vous pouvez spécifier handler404 dans votre URLconf".

Autrement dit, la vue page_not_found transmet uniquement l'URL demandée et ignore tout message que vous fournissez lors du déclenchement d'une exception. Il me semble qu'avoir l'option permettant de fournir des conseils utiles sur le modèle 404.html par défaut serait bénéfique pour tout le monde.

2) Je crée actuellement une vue personnalisée afin de pouvoir transmettre des messages utiles pour la situation suivante. Y a-t-il une raison pour laquelle je ne devrais pas ?

J'utilise des URL matricielles, donc la ressource de base est une URL hiérarchique normale suivie d'options matricielles au format de base : ;filter_type1=item:value,item:value;filter_type2=item:value...

Il est donc assez facile de fournir des messages utiles en fonction de l'état d'avancement de l'analyse avant d'avoir une erreur. Il me semble utile de faire passer un message tel que le suivant :

  • "Les types de filtres autorisés sont : type1, type2, type3." ou
  • "Les éléments autorisés pour filter_type a sont : item1, item2, item3."

Toutes mes excuses si j'ai raté cette explication ailleurs. J'ai regardé et j'ai demandé sur google django-users mais je n'ai reçu aucune réponse.


django
person KobeJohn    schedule 16.10.2011    source source
comment
On a l’impression que la question n’a reçu qu’une réponse indirecte. Cependant, sur la base des réponses apportées jusqu'à présent, je dois supposer que la réponse est la suivante : si vous avez besoin d'un message d'erreur dans un 404, vous le faites mal.   -  person KobeJohn    schedule 20.10.2011

Réponses (3)


arrow_upward
1
arrow_downward

Je ne sais pas vraiment quelle est la question. La vue page_not_found est basique par défaut car il il n'y a pas beaucoup de situations où vous devez expliquer pourquoi la page n'a pas été trouvée, sauf qu'elle ne l'a pas été.

Je suppose que par « options matricielles », vous entendez des paramètres URL/GET tels que :

http://domain.com/page/?option1=value&option2=value..

Au lieu de lancer un 404 s'ils saisissent une combinaison incorrecte de paramètres, pourquoi ne pas utiliser par défaut l'URL/le modèle de base (http://domain.com/page/) avec un message d'erreur indiquant "L'option 1 ne peut être que x, y, z". ". De cette façon, ils se voient présenter une page familière et peuvent réessayer leur sélection sans avoir à revenir en arrière à partir d'une page 404 (et il n'est pas si déroutant de savoir pourquoi cela n'a pas fonctionné).

Vous pouvez utiliser le cadre de messagerie de Django pour y parvenir facilement (j'ai cela a été fait dans le passé). Transmettez un message d'erreur au modèle lorsque vous vérifiez les paramètres dans la vue.

person Timmy O'Mahony    schedule 16.10.2011
comment
...est basique par défaut car il n'y a pas beaucoup de situations dans lesquelles vous devez expliquer pourquoi la page n'a pas été trouvée... J'ai seulement vu des affirmations telles que la vôtre et celles de la documentation selon lesquelles il n'y a pas beaucoup de situations pour le message. Je peux tout à fait accepter que c’est peut-être vrai, mais je recherche plus qu’une simple affirmation. Votre explication sur la deuxième partie m'aide en disant qu'il n'est peut-être pas faux d'afficher un message d'erreur mais qu'il existe peut-être une meilleure façon de le faire. Merci pour votre réponse! - person KobeJohn; 17.10.2011
comment
Pour quelles raisons pouvez-vous penser qu'une page n'a pas pu être trouvée ? (1) un lien a été rompu, (2) un utilisateur l'a mal saisi (voir #1). S'il y a d'autres raisons, comme la saisie de données non valides, il ne doit pas s'agir d'un 404. Utilisez d'autres codes de réponse HTTP pour indiquer qu'une réponse a échoué. 409 : données contradictoires, 403 : interdites, etc. - person Matthew Schinckel; 17.10.2011
comment
Assez juste. Je me suis moi-même posé cette question. Semblable à mon commentaire à Matthew, disons que les paramètres de filtre/ordre dans l'URL semblent mal formés. Ce n'est pas 404 ? Peut-être que j'aboie sur le mauvais arbre. J'ai parcouru toutes les réponses HTTP et je n'en ai pas trouvé une plus appropriée. - person KobeJohn; 19.10.2011
comment
Je retournerais un 409 : Conflit. (Ou un simple 400 : erreur). Cependant, si vous effectuez simplement un rendu HTML, vous renverrez un 200, mais les données de la page indiquent qu'il y a une erreur. (La plupart de ma programmation d'applications Web est basée sur une API, où les réponses de la série 4xx peuvent avoir et ont effectivement un corps.) - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

Si vos données arrivent comme :

http://example.com/foo;bar;baz

Alors tu le fais mal :)

Vous devez ensuite utiliser des expressions régulières pour analyser les données à traiter.

Certaines personnes, confrontées à un problème, pensent « Je sais, je vais utiliser des expressions régulières ». Maintenant, ils ont deux problèmes.

(Zawinski, 1997)

Au lieu de cela, comme le suggère pastylegs, utilisez les paramètres GET.

Mieux encore, utilisez la gestion des formulaires Django et :

  • créer un formulaire comportant des règles de validation
  • rendre la page de saisie à partir de ce formulaire
  • analyser l'entrée de l'utilisateur à l'aide du formulaire
  • afficher les données si le formulaire était valide, sinon afficher les erreurs de validation à côté de la saisie de l'utilisateur

Vous pouvez le faire avec des requêtes GET ou des requêtes POST. POST a l'avantage d'avoir des URL « propres » et un corps de données plus long. GET signifie que les URL peuvent être mises en signet.

Tout cela revient à utiliser les bonnes parties du framework pour les bonnes tâches. Le routage d'URL utilise des expressions régulières pour déterminer quelle URL atteint quelle vue. Plus vous simplifiez les modèles d’URL, plus ils seront faciles à maintenir. La saisie de l'utilisateur doit être gérée par des formulaires.

person Matthew Schinckel    schedule 17.10.2011
comment
Point pris pour avoir mal fait les choses. Juste pour expliquer... après avoir lu le développement Web RESTful et les Matrix URIs (1996) par Tim Berners-Lee J'ai eu l'idée d'écrire un système de gestion des URI matriciels au format point-virgule. C'est un système plus flexible que la requête, mais il n'est tout simplement pas implémenté dans les frameworks donc oui, il doit être analysé :) - person KobeJohn; 19.10.2011
comment
Quant au contenu des paramètres, ils ne sont pas saisis par l’utilisateur en soi. Ce sont des filtres et des instructions de classement pour les listes de données qui apparaîtront sur la page. Ils peuvent être modifiés par l'utilisateur si certains contrôles sont prévus. Donc, dans cette situation, disons que je convertis en utilisant une chaîne de requête et des paramètres GET, quelle est la bonne façon de procéder, par exemple. paramètres de filtre/ordre mal formés dans la chaîne de requête ? - person KobeJohn; 19.10.2011
comment
Ma position est que si l'utilisateur sélectionne des éléments et que cela affecte les données entrantes, il s'agit alors d'une entrée de l'utilisateur. Il est probablement quelque peu validé par le côté client de votre application, mais doit toujours être validé par le serveur. Quant à la commande : si vous utilisez des mappages (et que vous utilisez un formulaire, vous le ferez), cela disparaît. Données incorrectes : -› restituer le formulaire en montrant les conflits de données. - person Matthew Schinckel; 19.10.2011
comment
Pour que ce soit plus clair : ne vous focalisez pas sur le fait qu'un formulaire est généralement constitué de champs HTML. Si vous le pouvez, faites en sorte que vos contrôles de page mettent à jour les champs cachés dans un élément « formulaire », qui est ensuite publié. - person Matthew Schinckel; 19.10.2011

arrow_upward
1
arrow_downward

Je pense que la raison pour laquelle vous avez du mal à comprendre cela est que vous essayez de mélanger 2 problèmes différents.

Premièrement, il s'agit de savoir si la page réelle a été trouvée ou non.
Deuxièmement, il s'agit de savoir si les paramètres fournis étaient valides ou non.

Donc, si l'url (partielle) est :

    .../whatever/?param1=value1&param2=value2

Si la page /whatever/default est introuvable, un message d'erreur de type "404 Page not found" s'affichera (devrait) s'afficher. Dans ce cas, vous ne pouvez pas savoir si les paramètres ou les valeurs fournis étaient corrects. La page demandée n'existe pas, vous ne savez donc pas à quelle page les paramètres sont destinés. Vous ne pouvez même pas supposer que le bon domain name a été spécifié. Il peut y avoir de nombreux domaines, URL et pages arbitraires dans lesquels les paramètres sont valides, et bien d'autres dans lesquels les paramètres ne sont pas valides.

Si la page /whatever/default est trouvée, alors :
Si la spécification de mauvais paramètres peut amener cette page à charger/rediriger une page inexistante, alors cela devrait être empêché par cette page. Si nécessaire, il appartient à cette page de valider les paramètres fournis, de prendre les actions appropriées et d'afficher les messages appropriés.

person Kevin Fegan    schedule 24.02.2013