Development #29565
donner (aux conditions/expressions) un accès aux éléments de la query string
0%
Description
Les gens abusent des variables de session, ou du fait que quixote tape dans request.form aussi bien les données du POST que du GET, pour genre préselectionner un élément d'une liste.
Faudrait arrêter.
Fichiers
Révisions associées
Historique
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Fichier 0001-misc-expose-request-.GET-in-expression-variables-295.patch 0001-misc-expose-request-.GET-in-expression-variables-295.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Thomas Noël il y a plus de 5 ans
(Je me dis que le nom "request.GET" nous est familier à nous les djangoquixeux, mais qu'à un néophyte on pourrait plutôt proposer request.query_string.foo)
Mais surtout, ça ne marchera que sur la première page d'un formulaire : pas sûr que ça incite les gens à ne plus demander de session_var... (en fait, je suis sûr que non, ça avait été une (la?) raison de la création des fameuses et lamentables session_var).
Mis à jour par Frédéric Péters il y a plus de 5 ans
(Je me dis que le nom "request.GET" nous est familier à nous les djangoquixeux, mais qu'à un néophyte on pourrait plutôt proposer request.query_string.foo)
Oui, sûr.
Mais surtout, ça ne marchera que sur la première page d'un formulaire : pas sûr que ça incite les gens à ne plus demander de session_var... (en fait, je suis sûr que non, ça avait été une (la?) raison de la création des fameuses et lamentables session_var).
L'origine était d'avoir un src="/img/bandeau-[session_var_departement].png", l'utilisation dans les formulaires c'est abusé depuis le début.
Même effectif uniquement sur la première page ça ferait le job pour #29563; ça donnerait aussi une solution officielle aux gens qui aujourd'hui font ?f1=plop pour préremplir.
Qu'ensuite une variable puisse être portée sur la suite du formulaire, ça retombe sur un autre ticket (les "champs cachés" etc.).
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Fichier 0001-misc-expose-request-query-string-in-expression-varia.patch 0001-misc-expose-request-query-string-in-expression-varia.patch ajouté
(Je me dis que le nom "request.GET" nous est familier à nous les djangoquixeux, mais qu'à un néophyte on pourrait plutôt proposer request.query_string.foo)
Oui, sûr.
Cela étant, il y a un intérêt à partager ça avec les autres briques, je pense aux cellules Combo, où on peut faire request.GET.
Autre truc à noter, c'est que "request" de manière globale est déjà dans le contexte d'évaluation Django, à certains moments (en fait quand ça passe par les context processors).
Du coup évolution du patch, qui assure que ça soit tout le temps ce nouvel objet request qui soit mis à disposition des gabarits et expressions, et qui fournit un attribut query_string, si on veut.
Mis à jour par Thomas Noël il y a plus de 5 ans
- Statut changé de Solution proposée à Solution validée
Ok avec tout cela. Pour éviter d'inventer quelque chose, retirons le « query_string = GET » ... et pousse ainsi.
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Solution validée à Solution déployée
commit 17e4fc2f306d1818dca831fd58b65dd2b08af7e5
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Tue Jan 8 16:23:14 2019 +0100
misc: expose request (/query string) in expression variables (#29565)
misc: expose request (/query string) in expression variables (#29565)