Project

General

Profile

Development #29565

donner (aux conditions/expressions) un accès aux éléments de la query string

Added by Frédéric Péters 6 months ago. Updated 5 months ago.

Status:
Solution déployée
Priority:
Normal
Assignee:
-
Start date:
08 Jan 2019
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

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.

0001-misc-expose-request-.GET-in-expression-variables-295.patch View (3.41 KB) Frédéric Péters, 08 Jan 2019 04:23 PM

0001-misc-expose-request-query-string-in-expression-varia.patch View (6.56 KB) Frédéric Péters, 09 Jan 2019 08:10 AM

Associated revisions

Revision 17e4fc2f (diff)
Added by Frédéric Péters 6 months ago

misc: expose request (/query string) in expression variables (#29565)

History

#1 Updated by Frédéric Péters 6 months ago

#2 Updated by Thomas Noël 6 months ago

(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).

#3 Updated by Frédéric Péters 6 months ago

(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.).

#4 Updated by Frédéric Péters 6 months ago

(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.

#5 Updated by Thomas Noël 6 months ago

  • Status changed from Solution proposée to Solution validée

Ok avec tout cela. Pour éviter d'inventer quelque chose, retirons le « query_string = GET » ... et pousse ainsi.

#6 Updated by Frédéric Péters 5 months ago

  • Status changed from Solution validée to 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)

Also available in: Atom PDF