Projet

Général

Profil

Development #29565

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

Ajouté par Frédéric Péters il y a 2 mois. Mis à jour il y a 2 mois.

Statut:
Solution déployée
Priorité:
Normal
Assigné à:
-
Début:
08 jan. 2019
Echéance:
% réalisé:

0%

Patch proposed:
Oui

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 Voir (3,41 ko) Frédéric Péters, 08 jan. 2019 16:23

0001-misc-expose-request-query-string-in-expression-varia.patch Voir (6,56 ko) Frédéric Péters, 09 jan. 2019 08:10

Révisions associées

Révision 17e4fc2f (diff)
Ajouté par Frédéric Péters il y a 2 mois

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

Historique

#1 Mis à jour par Frédéric Péters il y a 2 mois

#2 Mis à jour par Thomas Noël il y a 2 mois

(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 Mis à jour par Frédéric Péters il y a 2 mois

(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 Mis à jour par Frédéric Péters il y a 2 mois

(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 Mis à jour par Thomas Noël il y a 2 mois

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

#6 Mis à jour par Frédéric Péters il y a 2 mois

  • 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)

Formats disponibles : Atom PDF